From report at bugs.python.org  Wed Feb  1 00:17:33 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 31 Jan 2012 23:17:33 +0000
Subject: =?utf-8?q?=5Bissue10580=5D_Minor_grammar_change_in_Python=E2=80=99s_MSI_i?=
	=?utf-8?q?nstaller?=
In-Reply-To: <1291053115.29.0.21132112584.issue10580@psf.upfronthosting.co.za>
Message-ID: <1328051853.21.0.10021061148.issue10580@psf.upfronthosting.co.za>


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

Retro: Indeed I'm ignoring your reports because of your tone. If you want to insult me, go ahead, but please don't use the bug tracker (I can ignore insults pretty well by now). If you want to achieve something, stop insulting people.

----------

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

From report at bugs.python.org  Wed Feb  1 00:22:12 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Jan 2012 23:22:12 +0000
Subject: [issue13706] non-ascii fill characters no longer work in formatting
In-Reply-To: <1325630185.42.0.0487894537415.issue13706@psf.upfronthosting.co.za>
Message-ID: <E1RsN1f-0007N8-B1@dinsdale.python.org>


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

New changeset 056f5cc8885d by Victor Stinner in branch 'default':
Issue #13706: Add assertions to detect bugs earlier
http://hg.python.org/cpython/rev/056f5cc8885d

----------

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

From report at bugs.python.org  Wed Feb  1 00:39:58 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 Jan 2012 23:39:58 +0000
Subject: [issue13915] Update Tutorial 6.1.3 for PEP 3145
Message-ID: <1328053198.63.0.994035147287.issue13915@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

http://docs.python.org/py3k/tutorial/modules.html#compiled-python-files
needs to be updated for 3.2+ to reflect 
http://python.org/dev/peps/pep-3147/

The first sentence is still technically correct, but finding x.pyc in the same directory as x.py is now an anomaly, so that sentence, revised, should be near the bottom. Otherwise, the text should say that the default is to put x.<version>.pyc in __pycache__, where <version> is, for instance, 'cpython-32'. Note that this allows other implementations and other versions of cpython to use the same .py file.

I do not know if there is anywhere else that this info is or should be. Using Python?.

----------
assignee: docs at python
components: Documentation
messages: 152415
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Update Tutorial 6.1.3 for PEP 3145
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Feb  1 00:51:11 2012
From: report at bugs.python.org (Kang-Hao (Kenny) Lu)
Date: Tue, 31 Jan 2012 23:51:11 +0000
Subject: [issue13916] disallow the "surrogatepass" handler for non utf-*
	encodings
Message-ID: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za>


New submission from Kang-Hao (Kenny) Lu <kennyluck at csail.mit.edu>:

Currently the "surrogatepass" handler always encodes the surrogates in UTF-8 and hence the behavior for, say, "\udc80".encode("latin-1", "surrogatepass").decode("latin-1") might be unexpected and I don't even know what would, say, "\udc80\udc80".encode("big5", "surrogatepass").decode("big5"), return. Regardless of the fact that the documentation says "surrogatepass" is specific to utf-8", the currently behavior is arguably not too harmful thanks to PyBytesObject's '\0' ending (so that ((p[0] & 0xf0) == 0xe0 || (p[1] & 0xc0) == 0x80 || (p[2] & 0xc0) == 0x80) in PyCodec_SurrogatePassErrors would not crash).

However, I suggest we have the system either 1) raise early LookupError 2) raise the original Unicode(Decode|Encoding)Exception as soon as PyCodec_SurrogatePassErrors is called. I prefer the former.

Having this could shorten PyCodec_SurrogatePassErrors significantly in the patch I will shortly submit for issue #12892 as all the error conditions for utf-8, utf-16 and utf-32 are predicable* and almost all the conditionals could be removed. (The * statement is arguable if someone initializes interp->codec_search_path before _PyCodecRegistry_Init and the utf-16/32 encoders are overwritten. I don't think we need to worry about this too much though. Or am I wrong here?)

----------
components: Unicode
messages: 152416
nosy: ezio.melotti, kennyluck
priority: normal
severity: normal
status: open
title: disallow the "surrogatepass" handler for non  utf-* encodings
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Feb  1 00:54:17 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Jan 2012 23:54:17 +0000
Subject: [issue13916] disallow the "surrogatepass" handler for non utf-*
	encodings
In-Reply-To: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za>
Message-ID: <1328054057.52.0.747841422792.issue13916@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/issue13916>
_______________________________________

From report at bugs.python.org  Wed Feb  1 01:01:31 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Feb 2012 00:01:31 +0000
Subject: [issue13882] Add format argument for time.time(), time.clock(),
	... to get a timestamp as a Decimal object
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328054491.7.0.0248490784387.issue13882@psf.upfronthosting.co.za>


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

Hum, it looks like _PyTime_AsDecimal() is wrong is ts->divisor is not a power of 10. The exponent must be computed with Context(1), not Context(26). Something simpler can maybe be used, I don't know even the decimal API.

----------

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

From report at bugs.python.org  Wed Feb  1 01:03:31 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Feb 2012 00:03:31 +0000
Subject: [issue13706] non-ascii fill characters no longer work in formatting
In-Reply-To: <1325630185.42.0.0487894537415.issue13706@psf.upfronthosting.co.za>
Message-ID: <1328054611.72.0.995471560037.issue13706@psf.upfronthosting.co.za>


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

With the changeset 056f5cc8885d, format(1234, 'n') fails in a locale using a non-ASCII thousands separator. Patch showing the problem:

diff --git a/Lib/test/test_format.py b/Lib/test/test_format.py
--- a/Lib/test/test_format.py
+++ b/Lib/test/test_format.py
@@ -1,4 +1,5 @@
 from test.support import verbose, TestFailed
+import locale
 import sys
 import test.support as support
 import unittest
@@ -282,6 +283,19 @@ class FormatTest(unittest.TestCase):
         self.assertEqual(format(1+2j, "\u2007^8"), "\u2007(1+2j)\u2007")
         self.assertEqual(format(0j, "\u2007^4"), "\u20070j\u2007")
 
+    def test_locale(self):
+        try:
+            oldloc = locale.setlocale(locale.LC_ALL, '')
+        except locale.Error as err:
+            self.skipTest("Cannot set locale: {}".format(err))
+        try:
+            sep = locale.localeconv()['thousands_sep']
+            self.assertEqual(format(123456789, "n"),
+                             sep.join(('123', '456', '789')))
+        finally:
+            locale.setlocale(locale.LC_ALL, oldloc)
+
+
 
 def test_main():
     support.run_unittest(FormatTest)

----------

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

From report at bugs.python.org  Wed Feb  1 01:09:10 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 01 Feb 2012 00:09:10 +0000
Subject: [issue13903] New shared-keys dictionary implementation
In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za>
Message-ID: <1328054950.94.0.163883938887.issue13903@psf.upfronthosting.co.za>


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

FYI - I strongly support this type of work to reduce memory use of the Python interpreter!  :)

Also, yes, constant changing should be separate from this change but are worth occasionally re-measuring and justifying as common computer architectures have changed since the original decisions were made.

----------

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

From report at bugs.python.org  Wed Feb  1 01:36:11 2012
From: report at bugs.python.org (Kang-Hao (Kenny) Lu)
Date: Wed, 01 Feb 2012 00:36:11 +0000
Subject: [issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates
In-Reply-To: <1315133370.95.0.855318807974.issue12892@psf.upfronthosting.co.za>
Message-ID: <1328056571.43.0.998017593435.issue12892@psf.upfronthosting.co.za>


Kang-Hao (Kenny) Lu <kennyluck at csail.mit.edu> added the comment:

> The followings are on my TODO list, although this patch doesn't depend
> on any of these and can be reviewed and landed separately:
>  * make the surrogatepass error handler work for utf-16 and utf-32. (I
>    should be able to finish this by today)

Unfortunately this took longer than I thought but here comes the patch.

>>  * fix an error in the error handler for utf-16-le. (In, Python3.2 
>> b'\xdc\x80\x00\x41'.decode('utf-16-be', 'ignore') returns "\x00" 
>> instead of "A" for some reason)
>
> This should probably be done on a separate patch that will be applied
> to 3.2/3.3 (assuming that it can go to 3.2).  Rejecting surrogates will
> go in 3.3 only.  (Note that lot of Unicode-related code changed between
> 3.2 and 3.3.)

This turns out to be just two liners so I fixed that on the way. I can create separate patch with separate test for 3.2 (certainly doable) and even for 3.3, but since the test is now part of test_lone_surrogates, I feel less willing to do that for 3.3.

You might notice the codec naming inconsistency (utf-16-be and utf16be for encoding and decoding respectively). I have filed issue #13913 for this.

Also, the strcmps are quite crappy. I am working on issue #13916 (disallow the "surrogatepass" handler for non utf-* encodings). As long as we have that we can examine individual character instead...

In this patch, The "encoding" attribute for UnicodeDecodeException is now changed to return utf16(be|le) for utf-16. This is necessary info for "surrogatepass" to work although admittedly this is rather ugly. Any good idea? A new attribute for Unicode(Decode|Encode)Exception might be helpful but utf-16/32 are fairly uncommon encodings anyway and we should not add more burden for, say, utf-8.

>> Should we really reject lone surrogates for UTF-7?
>
> No, I meant only UTF-8/16/32; UTF-7 is fine as is.

Good to know.

----------
Added file: http://bugs.python.org/file24384/surrogatepass_for_utf-16&32.patch

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

From report at bugs.python.org  Wed Feb  1 01:42:30 2012
From: report at bugs.python.org (Kang-Hao (Kenny) Lu)
Date: Wed, 01 Feb 2012 00:42:30 +0000
Subject: [issue13913] utf-8 or utf8 or utf-8 (codec display name inconsistency)
In-Reply-To: <1328030876.68.0.627537179228.issue13913@psf.upfronthosting.co.za>
Message-ID: <1328056950.37.0.407234077145.issue13913@psf.upfronthosting.co.za>


Kang-Hao (Kenny) Lu <kennyluck at csail.mit.edu> added the comment:

> and the table on the documentation of the codec module suggests *utf_8*
> as the name of the codec, which I believe to be equivalent to "utf_8"
> because '-' is not a valid character of an identifier.

typo: equivalent to "utf_8" ? equivalent to "utf-8".

----------

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

From report at bugs.python.org  Wed Feb  1 02:25:06 2012
From: report at bugs.python.org (Kang-Hao (Kenny) Lu)
Date: Wed, 01 Feb 2012 01:25:06 +0000
Subject: [issue12100] Incremental encoders of CJK codecs reset the codec
	at	each call to encode()
In-Reply-To: <1305673805.66.0.039322983909.issue12100@psf.upfronthosting.co.za>
Message-ID: <1328059506.96.0.640135478968.issue12100@psf.upfronthosting.co.za>


Changes by Kang-Hao (Kenny) Lu <kennyluck at csail.mit.edu>:


----------
nosy: +kennyluck

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

From report at bugs.python.org  Wed Feb  1 03:27:14 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 01 Feb 2012 02:27:14 +0000
Subject: [issue3566] httplib persistent connections violate MUST in RFC2616
	sec 8.1.4.
In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za>
Message-ID: <1328063234.76.0.633781820762.issue3566@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea
versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Feb  1 04:29:16 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 01 Feb 2012 03:29:16 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1327973656.07.0.527772935894.issue13703@psf.upfronthosting.co.za>
Message-ID: <1328066913.2893.18.camel@surprise>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

On Tue, 2012-01-31 at 01:34 +0000, Dave Malcolm wrote:
> Dave Malcolm <dmalcolm at redhat.com> added the comment:
> 
> Am attaching a backport of optin-hash-randomization-for-3.1-dmalcolm-2012-01-30-002.patch to 2.6
> 
> Randomization covers the str, unicode and buffer types; equality of hashes is preserved for these types.

I tried benchmarking the 2.6 version of the patch.

I reran "perf.py" 16 times, setting PYTHONHASHRANDOMIZATION=1, and
--inherit_env=PYTHONHASHRANDOMIZATION so that the patched python uses
the randomization, using a different hash for each run.

Some tests are slightly faster with the patch on some runs; some are
slightly slower, and it appears to vary from run to run.  However, the
amount involved is a few percent.  [compare e.g. with msg151078]

Here's the command I used.
(for i in $(seq 16) ; do echo RUN $i ; (PYTHONHASHRANDOMIZATION=1
python ./perf.py
--inherit_env=PYTHONHASHRANDOMIZATION ../cpython-2.6-clean/python ../cpython-2.6-hash-randomization/python) ; done) | tee results-16.txt

Am attaching the results.

----------
Added file: http://bugs.python.org/file24385/results-16.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________
-------------- next part --------------
RUN 1
Running 2to3...
Running django...
Running nbody...
Running slowpickle...
Running slowspitfire...
Running slowunpickle...
Running spambayes...

Report on Linux surprise 2.6.41.10-3.fc15.x86_64 #1 SMP Mon Jan 23 15:46:37 UTC 2012 x86_64 x86_64
Total CPU cores: 4

### 2to3 ###
10.408417 -> 10.491405: 1.01x slower

### django ###
Min: 0.653477 -> 0.637403: 1.03x faster
Avg: 0.673311 -> 0.639964: 1.05x faster
Significant (t=13.95)
Stddev: 0.01685 -> 0.00129: 13.0141x smaller
Timeline: http://tinyurl.com/6mayt8w

### nbody ###
Min: 0.348541 -> 0.357061: 1.02x slower
Avg: 0.350242 -> 0.358502: 1.02x slower
Significant (t=-29.80)
Stddev: 0.00110 -> 0.00162: 1.4729x larger
Timeline: http://tinyurl.com/829p79g

### slowpickle ###
Min: 0.505686 -> 0.486886: 1.04x faster
Avg: 0.510853 -> 0.488166: 1.05x faster
Significant (t=7.10)
Stddev: 0.02257 -> 0.00107: 21.0597x smaller
Timeline: http://tinyurl.com/7mhb5om

### slowspitfire ###
Min: 0.483929 -> 0.492404: 1.02x slower
Avg: 0.485874 -> 0.496394: 1.02x slower
Significant (t=-7.59)
Stddev: 0.00538 -> 0.00819: 1.5208x larger
Timeline: http://tinyurl.com/7kyz6cc

### spambayes ###
Min: 0.208005 -> 0.210620: 1.01x slower
Avg: 0.209225 -> 0.213575: 1.02x slower
Significant (t=-7.12)
Stddev: 0.00070 -> 0.00426: 6.0828x larger
Timeline: http://tinyurl.com/828z3ar

The following not significant results are hidden, use -v to show them:
slowunpickle.
RUN 2
Running 2to3...
Running django...
Running nbody...
Running slowpickle...
Running slowspitfire...
Running slowunpickle...
Running spambayes...

Report on Linux surprise 2.6.41.10-3.fc15.x86_64 #1 SMP Mon Jan 23 15:46:37 UTC 2012 x86_64 x86_64
Total CPU cores: 4

### 2to3 ###
10.433414 -> 10.366424: 1.01x faster

The following not significant results are hidden, use -v to show them:
django, nbody, slowpickle, slowspitfire, slowunpickle, spambayes.
RUN 3
Running 2to3...
Running django...
Running nbody...
Running slowpickle...
Running slowspitfire...
Running slowunpickle...
Running spambayes...

Report on Linux surprise 2.6.41.10-3.fc15.x86_64 #1 SMP Mon Jan 23 15:46:37 UTC 2012 x86_64 x86_64
Total CPU cores: 4

### 2to3 ###
10.507403 -> 10.443413: 1.01x faster

### nbody ###
Min: 0.347113 -> 0.358297: 1.03x slower
Avg: 0.349639 -> 0.359305: 1.03x slower
Significant (t=-19.18)
Stddev: 0.00344 -> 0.00093: 3.6868x smaller
Timeline: http://tinyurl.com/7um65br

### slowspitfire ###
Min: 0.496533 -> 0.487242: 1.02x faster
Avg: 0.500014 -> 0.489972: 1.02x faster
Significant (t=8.79)
Stddev: 0.00647 -> 0.00484: 1.3374x smaller
Timeline: http://tinyurl.com/7mf6yoy

### slowunpickle ###
Min: 0.225240 -> 0.231670: 1.03x slower
Avg: 0.226403 -> 0.232951: 1.03x slower
Significant (t=-38.00)
Stddev: 0.00073 -> 0.00098: 1.3469x larger
Timeline: http://tinyurl.com/7uo5qrl

The following not significant results are hidden, use -v to show them:
django, slowpickle, spambayes.
RUN 4
Running 2to3...
Running django...
Running nbody...
Running slowpickle...
Running slowspitfire...
Running slowunpickle...
Running spambayes...

Report on Linux surprise 2.6.41.10-3.fc15.x86_64 #1 SMP Mon Jan 23 15:46:37 UTC 2012 x86_64 x86_64
Total CPU cores: 4

### 2to3 ###
10.432414 -> 10.468408: 1.00x slower

### django ###
Min: 0.665273 -> 0.688351: 1.03x slower
Avg: 0.670425 -> 0.691268: 1.03x slower
Significant (t=-36.39)
Stddev: 0.00297 -> 0.00275: 1.0794x smaller
Timeline: http://tinyurl.com/7oerhzy

### slowpickle ###
Min: 0.500789 -> 0.490035: 1.02x faster
Avg: 0.502928 -> 0.491509: 1.02x faster
Significant (t=39.91)
Stddev: 0.00158 -> 0.00127: 1.2460x smaller
Timeline: http://tinyurl.com/6sx42y3

The following not significant results are hidden, use -v to show them:
nbody, slowspitfire, slowunpickle, spambayes.
RUN 5
Running 2to3...
Running django...
Running nbody...
Running slowpickle...
Running slowspitfire...
Running slowunpickle...
Running spambayes...

Report on Linux surprise 2.6.41.10-3.fc15.x86_64 #1 SMP Mon Jan 23 15:46:37 UTC 2012 x86_64 x86_64
Total CPU cores: 4

### 2to3 ###
10.412417 -> 10.389420: 1.00x faster

### nbody ###
Min: 0.348455 -> 0.356011: 1.02x slower
Avg: 0.349509 -> 0.357288: 1.02x slower
Significant (t=-47.66)
Stddev: 0.00066 -> 0.00094: 1.4200x larger
Timeline: http://tinyurl.com/7he9rnb

### slowpickle ###
Min: 0.500636 -> 0.479028: 1.05x faster
Avg: 0.502622 -> 0.480900: 1.05x faster
Significant (t=50.66)
Stddev: 0.00273 -> 0.00132: 2.0594x smaller
Timeline: http://tinyurl.com/73q84uu

### slowspitfire ###
Min: 0.489198 -> 0.498855: 1.02x slower
Avg: 0.491745 -> 0.502117: 1.02x slower
Significant (t=-10.23)
Stddev: 0.00510 -> 0.00504: 1.0110x smaller
Timeline: http://tinyurl.com/7a9ls8p

### spambayes ###
Min: 0.215235 -> 0.209928: 1.03x faster
Avg: 0.216206 -> 0.211392: 1.02x faster
Significant (t=20.47)
Stddev: 0.00115 -> 0.00121: 1.0535x larger
Timeline: http://tinyurl.com/8a73hn8

The following not significant results are hidden, use -v to show them:
django, slowunpickle.
RUN 6
Running 2to3...
Running django...
Running nbody...
Running slowpickle...
Running slowspitfire...
Running slowunpickle...
Running spambayes...

Report on Linux surprise 2.6.41.10-3.fc15.x86_64 #1 SMP Mon Jan 23 15:46:37 UTC 2012 x86_64 x86_64
Total CPU cores: 4

### 2to3 ###
10.420416 -> 10.386421: 1.00x faster

### django ###
Min: 0.657224 -> 0.643548: 1.02x faster
Avg: 0.667904 -> 0.647546: 1.03x faster
Significant (t=3.15)
Stddev: 0.04570 -> 0.00198: 23.1166x smaller
Timeline: http://tinyurl.com/7qxxzg9

### nbody ###
Min: 0.348344 -> 0.358048: 1.03x slower
Avg: 0.349167 -> 0.360305: 1.03x slower
Significant (t=-22.10)
Stddev: 0.00100 -> 0.00342: 3.4194x larger
Timeline: http://tinyurl.com/7vvfjar

### slowspitfire ###
Min: 0.481867 -> 0.494397: 1.03x slower
Avg: 0.483928 -> 0.498087: 1.03x slower
Significant (t=-14.30)
Stddev: 0.00477 -> 0.00513: 1.0750x larger
Timeline: http://tinyurl.com/7vt8l48

### spambayes ###
Min: 0.213640 -> 0.207930: 1.03x faster
Avg: 0.214493 -> 0.209097: 1.03x faster
Significant (t=49.83)
Stddev: 0.00055 -> 0.00054: 1.0177x smaller
Timeline: http://tinyurl.com/7fpl8n9

The following not significant results are hidden, use -v to show them:
slowpickle, slowunpickle.
RUN 7
Running 2to3...
Running django...
Running nbody...
Running slowpickle...
Running slowspitfire...
Running slowunpickle...
Running spambayes...

Report on Linux surprise 2.6.41.10-3.fc15.x86_64 #1 SMP Mon Jan 23 15:46:37 UTC 2012 x86_64 x86_64
Total CPU cores: 4

### 2to3 ###
10.404419 -> 10.018477: 1.04x faster

### slowpickle ###
Min: 0.498261 -> 0.486422: 1.02x faster
Avg: 0.501004 -> 0.488317: 1.03x faster
Significant (t=25.21)
Stddev: 0.00322 -> 0.00151: 2.1327x smaller
Timeline: http://tinyurl.com/7nlujdr

The following not significant results are hidden, use -v to show them:
django, nbody, slowspitfire, slowunpickle, spambayes.
RUN 8
Running 2to3...
Running django...
Running nbody...
Running slowpickle...
Running slowspitfire...
Running slowunpickle...
Running spambayes...

Report on Linux surprise 2.6.41.10-3.fc15.x86_64 #1 SMP Mon Jan 23 15:46:37 UTC 2012 x86_64 x86_64
Total CPU cores: 4

### 2to3 ###
10.417416 -> 10.424415: 1.00x slower

### nbody ###
Min: 0.347815 -> 0.355863: 1.02x slower
Avg: 0.349035 -> 0.356561: 1.02x slower
Significant (t=-51.37)
Stddev: 0.00088 -> 0.00055: 1.6103x smaller
Timeline: http://tinyurl.com/8286jej

### slowpickle ###
Min: 0.501392 -> 0.470983: 1.06x faster
Avg: 0.504655 -> 0.473949: 1.06x faster
Significant (t=61.66)
Stddev: 0.00311 -> 0.00164: 1.8936x smaller
Timeline: http://tinyurl.com/7dtv5ov

### slowunpickle ###
Min: 0.214313 -> 0.222419: 1.04x slower
Avg: 0.215145 -> 0.224399: 1.04x slower
Significant (t=-31.50)
Stddev: 0.00058 -> 0.00199: 3.4188x larger
Timeline: http://tinyurl.com/78wy35k

The following not significant results are hidden, use -v to show them:
django, slowspitfire, spambayes.
RUN 9
Running 2to3...
Running django...
Running nbody...
Running slowpickle...
Running slowspitfire...
Running slowunpickle...
Running spambayes...

Report on Linux surprise 2.6.41.10-3.fc15.x86_64 #1 SMP Mon Jan 23 15:46:37 UTC 2012 x86_64 x86_64
Total CPU cores: 4

### 2to3 ###
10.426415 -> 10.407418: 1.00x faster

### slowspitfire ###
Min: 0.506234 -> 0.485618: 1.04x faster
Avg: 0.508200 -> 0.488075: 1.04x faster
Significant (t=20.47)
Stddev: 0.00465 -> 0.00517: 1.1116x larger
Timeline: http://tinyurl.com/6nznb5m

### slowunpickle ###
Min: 0.215225 -> 0.225862: 1.05x slower
Avg: 0.216848 -> 0.228334: 1.05x slower
Significant (t=-37.23)
Stddev: 0.00139 -> 0.00169: 1.2169x larger
Timeline: http://tinyurl.com/7oab85b

The following not significant results are hidden, use -v to show them:
django, nbody, slowpickle, spambayes.
RUN 10
Running 2to3...
Running django...
Running nbody...
Running slowpickle...
Running slowspitfire...
Running slowunpickle...
Running spambayes...

Report on Linux surprise 2.6.41.10-3.fc15.x86_64 #1 SMP Mon Jan 23 15:46:37 UTC 2012 x86_64 x86_64
Total CPU cores: 4

### 2to3 ###
10.407418 -> 10.406418: 1.00x faster

### nbody ###
Min: 0.348248 -> 0.357746: 1.03x slower
Avg: 0.349253 -> 0.359411: 1.03x slower
Significant (t=-53.25)
Stddev: 0.00085 -> 0.00105: 1.2428x larger
Timeline: http://tinyurl.com/7pc6vo3

### slowpickle ###
Min: 0.509411 -> 0.477617: 1.07x faster
Avg: 0.511183 -> 0.496210: 1.03x faster
Significant (t=20.71)
Stddev: 0.00171 -> 0.00482: 2.8141x larger
Timeline: http://tinyurl.com/847tteh

### spambayes ###
Min: 0.214139 -> 0.208745: 1.03x faster
Avg: 0.215472 -> 0.210040: 1.03x faster
Significant (t=30.78)
Stddev: 0.00111 -> 0.00058: 1.9131x smaller
Timeline: http://tinyurl.com/72m6d8z

The following not significant results are hidden, use -v to show them:
django, slowspitfire, slowunpickle.
RUN 11
Running 2to3...
Running django...
Running nbody...
Running slowpickle...
Running slowspitfire...
Running slowunpickle...
Running spambayes...

Report on Linux surprise 2.6.41.10-3.fc15.x86_64 #1 SMP Mon Jan 23 15:46:37 UTC 2012 x86_64 x86_64
Total CPU cores: 4

### 2to3 ###
10.398419 -> 10.025476: 1.04x faster

### django ###
Min: 0.695595 -> 0.673811: 1.03x faster
Avg: 0.698241 -> 0.677724: 1.03x faster
Significant (t=28.26)
Stddev: 0.00206 -> 0.00470: 2.2827x larger
Timeline: http://tinyurl.com/7m63ddc

### nbody ###
Min: 0.347926 -> 0.357912: 1.03x slower
Avg: 0.348918 -> 0.358878: 1.03x slower
Significant (t=-69.86)
Stddev: 0.00075 -> 0.00068: 1.1060x smaller
Timeline: http://tinyurl.com/7d93ltq

### slowpickle ###
Min: 0.500152 -> 0.486629: 1.03x faster
Avg: 0.503408 -> 0.488044: 1.03x faster
Significant (t=24.62)
Stddev: 0.00430 -> 0.00101: 4.2606x smaller
Timeline: http://tinyurl.com/7jfd688

### slowunpickle ###
Min: 0.216090 -> 0.226599: 1.05x slower
Avg: 0.217636 -> 0.228417: 1.05x slower
Significant (t=-34.63)
Stddev: 0.00146 -> 0.00164: 1.1240x larger
Timeline: http://tinyurl.com/7dafqbq

### spambayes ###
Min: 0.207730 -> 0.215746: 1.04x slower
Avg: 0.211889 -> 0.216693: 1.02x slower
Significant (t=-6.51)
Stddev: 0.00519 -> 0.00061: 8.5400x smaller
Timeline: http://tinyurl.com/79cgkyb

The following not significant results are hidden, use -v to show them:
slowspitfire.
RUN 12
Running 2to3...
Running django...
Running nbody...
Running slowpickle...
Running slowspitfire...
Running slowunpickle...
Running spambayes...

Report on Linux surprise 2.6.41.10-3.fc15.x86_64 #1 SMP Mon Jan 23 15:46:37 UTC 2012 x86_64 x86_64
Total CPU cores: 4

### 2to3 ###
10.126460 -> 10.376423: 1.02x slower

### django ###
Min: 0.693555 -> 0.646351: 1.07x faster
Avg: 0.696282 -> 0.649983: 1.07x faster
Significant (t=91.06)
Stddev: 0.00249 -> 0.00259: 1.0415x larger
Timeline: http://tinyurl.com/7yuuc6m

### slowpickle ###
Min: 0.507876 -> 0.495469: 1.03x faster
Avg: 0.509657 -> 0.498394: 1.02x faster
Significant (t=23.46)
Stddev: 0.00163 -> 0.00298: 1.8203x larger
Timeline: http://tinyurl.com/85zg9d7

### slowspitfire ###
Min: 0.486505 -> 0.501372: 1.03x slower
Avg: 0.488336 -> 0.503203: 1.03x slower
Significant (t=-15.09)
Stddev: 0.00491 -> 0.00494: 1.0046x larger
Timeline: http://tinyurl.com/7jfo4at

### slowunpickle ###
Min: 0.223394 -> 0.220989: 1.01x faster
Avg: 0.227670 -> 0.222345: 1.02x faster
Significant (t=2.32)
Stddev: 0.01614 -> 0.00185: 8.7058x smaller
Timeline: http://tinyurl.com/7r5g8qj

The following not significant results are hidden, use -v to show them:
nbody, spambayes.
RUN 13
Running 2to3...
Running django...
Running nbody...
Running slowpickle...
Running slowspitfire...
Running slowunpickle...
Running spambayes...

Report on Linux surprise 2.6.41.10-3.fc15.x86_64 #1 SMP Mon Jan 23 15:46:37 UTC 2012 x86_64 x86_64
Total CPU cores: 4

### 2to3 ###
10.445412 -> 10.465409: 1.00x slower

### spambayes ###
Min: 0.215538 -> 0.209666: 1.03x faster
Avg: 0.217127 -> 0.211057: 1.03x faster
Significant (t=21.27)
Stddev: 0.00131 -> 0.00154: 1.1780x larger
Timeline: http://tinyurl.com/84jnmu2

The following not significant results are hidden, use -v to show them:
django, nbody, slowpickle, slowspitfire, slowunpickle.
RUN 14
Running 2to3...
Running django...
Running nbody...
Running slowpickle...
Running slowspitfire...
Running slowunpickle...
Running spambayes...

Report on Linux surprise 2.6.41.10-3.fc15.x86_64 #1 SMP Mon Jan 23 15:46:37 UTC 2012 x86_64 x86_64
Total CPU cores: 4

### 2to3 ###
10.437413 -> 10.430414: 1.00x faster

### slowspitfire ###
Min: 0.481473 -> 0.495826: 1.03x slower
Avg: 0.486514 -> 0.498878: 1.03x slower
Significant (t=-4.12)
Stddev: 0.01801 -> 0.01123: 1.6033x smaller
Timeline: http://tinyurl.com/86wusu6

The following not significant results are hidden, use -v to show them:
django, nbody, slowpickle, slowunpickle, spambayes.
RUN 15
Running 2to3...
Running django...
Running nbody...
Running slowpickle...
Running slowspitfire...
Running slowunpickle...
Running spambayes...

Report on Linux surprise 2.6.41.10-3.fc15.x86_64 #1 SMP Mon Jan 23 15:46:37 UTC 2012 x86_64 x86_64
Total CPU cores: 4

### 2to3 ###
10.387421 -> 10.383421: 1.00x faster

### django ###
Min: 0.687798 -> 0.640119: 1.07x faster
Avg: 0.690557 -> 0.645465: 1.07x faster
Significant (t=29.42)
Stddev: 0.00172 -> 0.01070: 6.2054x larger
Timeline: http://tinyurl.com/7hdxeh8

### slowpickle ###
Min: 0.476924 -> 0.465884: 1.02x faster
Avg: 0.479144 -> 0.468487: 1.02x faster
Significant (t=34.84)
Stddev: 0.00151 -> 0.00155: 1.0317x larger
Timeline: http://tinyurl.com/84ekx8m

The following not significant results are hidden, use -v to show them:
nbody, slowspitfire, slowunpickle, spambayes.
RUN 16
Running 2to3...
Running django...
Running nbody...
Running slowpickle...
Running slowspitfire...
Running slowunpickle...
Running spambayes...

Report on Linux surprise 2.6.41.10-3.fc15.x86_64 #1 SMP Mon Jan 23 15:46:37 UTC 2012 x86_64 x86_64
Total CPU cores: 4

### 2to3 ###
10.409417 -> 10.358426: 1.00x faster

### slowpickle ###
Min: 0.499236 -> 0.486159: 1.03x faster
Avg: 0.501061 -> 0.487773: 1.03x faster
Significant (t=41.63)
Stddev: 0.00180 -> 0.00136: 1.3271x smaller
Timeline: http://tinyurl.com/6pglofy

### spambayes ###
Min: 0.214768 -> 0.210226: 1.02x faster
Avg: 0.216006 -> 0.211464: 1.02x faster
Significant (t=28.84)
Stddev: 0.00093 -> 0.00062: 1.4967x smaller
Timeline: http://tinyurl.com/7ur8r54

The following not significant results are hidden, use -v to show them:
django, nbody, slowspitfire, slowunpickle.

From report at bugs.python.org  Wed Feb  1 07:48:40 2012
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 01 Feb 2012 06:48:40 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1328078920.1.0.874881162832.issue6210@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Attached patch now includes doc changes.

----------
Added file: http://bugs.python.org/file24386/raise_from_none_v4.diff

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

From report at bugs.python.org  Wed Feb  1 08:16:09 2012
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 01 Feb 2012 07:16:09 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1328080569.02.0.330597441607.issue6210@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Okay, *all* the documentation updates this time.  Thanks, Nick!

----------
Added file: http://bugs.python.org/file24387/raise_from_none_v5.diff

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

From report at bugs.python.org  Wed Feb  1 09:36:08 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 01 Feb 2012 08:36:08 +0000
Subject: [issue13734] Add a generic directory walker method to avoid symlink
	attacks
In-Reply-To: <1328046829.20847.1.camel@localhost.localdomain>
Message-ID: <CAH_1eM205x6LAvYBY4A5tVPKA15_E-_1E6UCeUDjKAGo=gdUZw@mail.gmail.com>


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

> I think the O(depth) version is fine. The O(1) version is quite more
> complicated, difficult to follow, and it seems less robust (it doesn't
> use try/finally and therefore might leak fds if the generator isn't
> exhausted before being destroyed).

I agree.

> On modern systems you have at least 1024 fds, so the restriction
> shouldn't be a problem.

Actually, I think you're much more likely to run above the max
recursion limit than RLIMIT_NOFILE (OTOH, you don't know how many FDs
are already open at the time of the call).

----------

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

From report at bugs.python.org  Wed Feb  1 11:08:47 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 01 Feb 2012 10:08:47 +0000
Subject: [issue13734] Add a generic directory walker method to avoid symlink
	attacks
In-Reply-To: <1325981643.51.0.923790442233.issue13734@psf.upfronthosting.co.za>
Message-ID: <1328090927.35.0.956227948063.issue13734@psf.upfronthosting.co.za>


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

I'm also a fan of using the simpler approach unless/until we have solid evidence that the file descriptor limit could be a problem in practice.

A comment in the code mentioning the concern, along with the fact that there's an alternate algorithm attached to this tracker issue that avoids it would probably be appropriate though.

----------

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

From report at bugs.python.org  Wed Feb  1 13:55:41 2012
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 01 Feb 2012 12:55:41 +0000
Subject: [issue13719] bdist_msi upload fails
In-Reply-To: <1325855918.9.0.207720990162.issue13719@psf.upfronthosting.co.za>
Message-ID: <1328100941.31.0.539181884715.issue13719@psf.upfronthosting.co.za>


Ralf Schmitt <python-bugs at systemexit.de> added the comment:

It's a bug in bdist_msi not in the upload command. You can check that distribution.dist_files point to valid files after running the command.

----------

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

From report at bugs.python.org  Wed Feb  1 14:03:46 2012
From: report at bugs.python.org (Carlo Di Dato)
Date: Wed, 01 Feb 2012 13:03:46 +0000
Subject: [issue13917] Python 2.7.2 and 3.2.2 execl crash
Message-ID: <1328101426.59.0.731366036036.issue13917@psf.upfronthosting.co.za>


New submission from Carlo Di Dato <shinnai at autistici.org>:

These lines make Python 2.7.2 and 3.2.2 crash

import os
os.execl("cmd.exe", "")

Regards

----------
components: Windows
messages: 152428
nosy: shinnai
priority: normal
severity: normal
status: open
title: Python 2.7.2 and 3.2.2 execl crash
type: crash
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Wed Feb  1 14:04:27 2012
From: report at bugs.python.org (Carlo Di Dato)
Date: Wed, 01 Feb 2012 13:04:27 +0000
Subject: [issue13917] Python 2.7.2 and 3.2.2 execl crash
In-Reply-To: <1328101426.59.0.731366036036.issue13917@psf.upfronthosting.co.za>
Message-ID: <1328101467.73.0.501323365376.issue13917@psf.upfronthosting.co.za>


Changes by Carlo Di Dato <shinnai at autistici.org>:


----------
versions: +Python 3.2 -Python 3.1

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

From report at bugs.python.org  Wed Feb  1 14:16:01 2012
From: report at bugs.python.org (Tim Golden)
Date: Wed, 01 Feb 2012 13:16:01 +0000
Subject: [issue13917] Python 2.7.2 and 3.2.2 execl crash
In-Reply-To: <1328101467.73.0.501323365376.issue13917@psf.upfronthosting.co.za>
Message-ID: <4F293B0E.9080505@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

This is a duplicate of http://bugs.python.org/issue8036

(which I still haven't got around to applying...)

----------
nosy: +tim.golden

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

From report at bugs.python.org  Wed Feb  1 15:04:27 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Feb 2012 14:04:27 +0000
Subject: [issue13917] Python 2.7.2 and 3.2.2 execl crash
In-Reply-To: <1328101426.59.0.731366036036.issue13917@psf.upfronthosting.co.za>
Message-ID: <1328105067.02.0.785343127752.issue13917@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Interpreter crashes on invalid arg to spawnl on Windows

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

From report at bugs.python.org  Wed Feb  1 15:10:22 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Feb 2012 14:10:22 +0000
Subject: [issue7856] cannot decode from or encode to big5 \xf9\xd8
In-Reply-To: <1265346469.79.0.269704961777.issue7856@psf.upfronthosting.co.za>
Message-ID: <1328105422.8.0.928347849923.issue7856@psf.upfronthosting.co.za>


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


----------
nosy: +haypo
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

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

From report at bugs.python.org  Wed Feb  1 15:12:21 2012
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Wed, 01 Feb 2012 14:12:21 +0000
Subject: [issue13918] locale.atof documentation is missing func argument
Message-ID: <1328105541.08.0.458455853203.issue13918@psf.upfronthosting.co.za>


New submission from C?dric Krier <cedric.krier at b2ck.com>:

atof has a func argument used to instantiate the result but it is missing in the documentation.

----------
assignee: docs at python
components: Documentation
messages: 152430
nosy: ced, docs at python
priority: normal
severity: normal
status: open
title: locale.atof documentation is missing func argument
type: enhancement

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

From report at bugs.python.org  Wed Feb  1 15:42:16 2012
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 01 Feb 2012 14:42:16 +0000
Subject: [issue13868] Add hyphen doc fix
In-Reply-To: <1327535890.98.0.936666267948.issue13868@psf.upfronthosting.co.za>
Message-ID: <1328107336.58.0.228642086108.issue13868@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Seriously, how old are you?two?clowns?

----------

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

From report at bugs.python.org  Wed Feb  1 15:45:15 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 01 Feb 2012 14:45:15 +0000
Subject: [issue13868] Add hyphen doc fix
In-Reply-To: <1328107336.58.0.228642086108.issue13868@psf.upfronthosting.co.za>
Message-ID: <CAPdtAj37dLD99HuBUEjZyqr8VRpgYYjtwnpOOKHPC9TuGj8g_g@mail.gmail.com>


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

On Wed, Feb 1, 2012 at 15:42, Bo?tjan Mejak <report at bugs.python.org> wrote:
> Seriously, how old are you?two?clowns?

I think it's enough: FTR I'm +1 on removing Retro tracker account,
effective immediately (if any admin is around).

----------

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

From report at bugs.python.org  Wed Feb  1 15:50:32 2012
From: report at bugs.python.org (sbt)
Date: Wed, 01 Feb 2012 14:50:32 +0000
Subject: [issue12328] multiprocessing's overlapped PipeConnection on Windows
In-Reply-To: <1307991196.59.0.849860111943.issue12328@psf.upfronthosting.co.za>
Message-ID: <1328107832.15.0.722854928738.issue12328@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

I have done an updated patch.  (It does *not* switch to using bytes oriented pipes as I suggested in the previous message.)

The patch also adds a wait() function with signature

    wait(object_list, timeout=None)

for polling multiple objects at once.  On Unix it is just a wrapper for

    select.select(object_list, [], [], timeout)

except that it retries when it gets EINTR.  wait() works with "connected" sockets too, although on Windows it does not work for "listening" sockets.

The patch removes SentinelReady and changes concurrent.futures to use wait() instead.

Polling is now done by issuing zero length overlapped reads.  This means that the pipe is not modified except possibly if a zero length message is removed.

I changed ReadFile(), WriteFile() and GetOverlappedResult() to return pairs, the second entry of which is zero or an "expected" error code.  (Unexpected errors still raise an exception.)  This avoids the need to ever use GetLastError().

----------
Added file: http://bugs.python.org/file24388/pipe_poll_fix.patch

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

From report at bugs.python.org  Wed Feb  1 15:59:57 2012
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 01 Feb 2012 14:59:57 +0000
Subject: [issue13868] Add hyphen doc fix
In-Reply-To: <1327535890.98.0.936666267948.issue13868@psf.upfronthosting.co.za>
Message-ID: <1328108397.84.0.815601933101.issue13868@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Kiss?my?ball?sac!

----------

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

From report at bugs.python.org  Wed Feb  1 16:03:26 2012
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 01 Feb 2012 15:03:26 +0000
Subject: =?utf-8?b?W2lzc3VlMTM5MTldIGtpc3PCoG15wqBiYWxswqBzYWM=?=
Message-ID: <1328108606.22.0.135137838492.issue13919@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: kiss?my?ball?sac
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb  1 16:08:47 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 01 Feb 2012 15:08:47 +0000
Subject: =?utf-8?b?W2lzc3VlMTM5MTldIGtpc3PCoG15wqBiYWxswqBzYWM=?=
Message-ID: <1328108927.74.0.544847513086.issue13919@psf.upfronthosting.co.za>


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


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: enhancement -> 

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

From report at bugs.python.org  Wed Feb  1 16:13:26 2012
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 01 Feb 2012 15:13:26 +0000
Subject: [issue13920] intern() doc wrong spelling
Message-ID: <1328109206.92.0.270712922412.issue13920@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

http://docs.python.org/library/functions.html#intern

Visit the upper link andewsqEz80olp

----------
assignee: docs at python
components: Documentation
hgrepos: 110
messages: 152435
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: intern() doc wrong spelling
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Feb  1 16:14:06 2012
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 01 Feb 2012 15:14:06 +0000
Subject: [issue13920] intern() doc wrong spelling
In-Reply-To: <1328109206.92.0.270712922412.issue13920@psf.upfronthosting.co.za>
Message-ID: <1328109246.87.0.751518881012.issue13920@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


----------
hgrepos:  -110

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

From report at bugs.python.org  Wed Feb  1 16:17:06 2012
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 01 Feb 2012 15:17:06 +0000
Subject: [issue13920] intern() doc wrong spelling
In-Reply-To: <1328109206.92.0.270712922412.issue13920@psf.upfronthosting.co.za>
Message-ID: <1328109426.36.0.470302369132.issue13920@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

http://docs.python.org/library/functions.html#intern

Visit the upper link and fix 2 words that say "compare" to "comparison".

Hint: "blah blah blah pointer compare ... string compare ..."

----------

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

From report at bugs.python.org  Wed Feb  1 16:17:46 2012
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 01 Feb 2012 15:17:46 +0000
Subject: [issue13920] intern() doc wrong spelling
In-Reply-To: <1328109206.92.0.270712922412.issue13920@psf.upfronthosting.co.za>
Message-ID: <1328109466.18.0.955073174446.issue13920@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


----------
type:  -> enhancement

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

From report at bugs.python.org  Wed Feb  1 16:21:58 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Feb 2012 15:21:58 +0000
Subject: [issue13868] Add hyphen doc fix
In-Reply-To: <1327535890.98.0.936666267948.issue13868@psf.upfronthosting.co.za>
Message-ID: <1328109718.99.0.914806032331.issue13868@psf.upfronthosting.co.za>


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

Retro, your contributions are not welcome anymore.

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

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

From report at bugs.python.org  Wed Feb  1 16:43:54 2012
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 01 Feb 2012 15:43:54 +0000
Subject: [issue13920] intern() doc wrong spelling
In-Reply-To: <1328109206.92.0.270712922412.issue13920@psf.upfronthosting.co.za>
Message-ID: <1328111034.65.0.738334512415.issue13920@psf.upfronthosting.co.za>


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

This is fine as is.

----------
nosy: +brian.curtin
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Feb  1 16:44:05 2012
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 01 Feb 2012 15:44:05 +0000
Subject: [issue13920] intern() doc wrong spelling
In-Reply-To: <1328109206.92.0.270712922412.issue13920@psf.upfronthosting.co.za>
Message-ID: <1328111045.31.0.661801389083.issue13920@psf.upfronthosting.co.za>


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


----------
nosy:  -brian.curtin

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

From report at bugs.python.org  Wed Feb  1 18:08:23 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 01 Feb 2012 17:08:23 +0000
Subject: [issue13908] PyType_FromSpec() lacks PyType_Ready() call
In-Reply-To: <1327879029.72.0.4665491693.issue13908@psf.upfronthosting.co.za>
Message-ID: <1328116103.16.0.921333108316.issue13908@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/issue13908>
_______________________________________

From report at bugs.python.org  Wed Feb  1 20:37:28 2012
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 01 Feb 2012 19:37:28 +0000
Subject: [issue13868] Add hyphen doc fix
In-Reply-To: <1327535890.98.0.936666267948.issue13868@psf.upfronthosting.co.za>
Message-ID: <1328125048.83.0.359921817449.issue13868@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Feb  1 21:08:36 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 01 Feb 2012 20:08:36 +0000
Subject: [issue13885] CVE-2011-3389: _ssl module always disables the CBC IV
	attack countermeasure
In-Reply-To: <1327652753.95.0.174471030951.issue13885@psf.upfronthosting.co.za>
Message-ID: <1328126916.97.0.318016736899.issue13885@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/issue13885>
_______________________________________

From report at bugs.python.org  Wed Feb  1 21:30:36 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 01 Feb 2012 20:30:36 +0000
Subject: [issue13872] socket.detach doesn't mark socket._closed
In-Reply-To: <1327582652.34.0.856044764189.issue13872@psf.upfronthosting.co.za>
Message-ID: <1328128236.07.0.319552292072.issue13872@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/issue13872>
_______________________________________

From report at bugs.python.org  Wed Feb  1 21:31:27 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 01 Feb 2012 20:31:27 +0000
Subject: [issue13889] str(float) and round(float) issues with FPU precision
In-Reply-To: <1327676303.66.0.487112802864.issue13889@psf.upfronthosting.co.za>
Message-ID: <1328128287.82.0.995706709583.issue13889@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
assignee: mark.dickinson -> 
nosy: +jcea
type: behavior -> 

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

From report at bugs.python.org  Wed Feb  1 21:33:36 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 01 Feb 2012 20:33:36 +0000
Subject: [issue13889] str(float) and round(float) issues with FPU precision
In-Reply-To: <1327676303.66.0.487112802864.issue13889@psf.upfronthosting.co.za>
Message-ID: <1328128416.6.0.23525238102.issue13889@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Should this bug be marked as "closed+committed"?

----------

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

From report at bugs.python.org  Wed Feb  1 21:45:09 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 01 Feb 2012 20:45:09 +0000
Subject: [issue13676] sqlite3: Zero byte truncates string contents
In-Reply-To: <1325161654.99.0.774888973707.issue13676@psf.upfronthosting.co.za>
Message-ID: <E1Rsh3D-0002tK-6d@dinsdale.python.org>


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

New changeset 2e13011b3719 by Petri Lehtinen in branch '3.2':
sqlite3: Handle strings with embedded zeros correctly
http://hg.python.org/cpython/rev/2e13011b3719

New changeset 93ac4b12a750 by Petri Lehtinen in branch '2.7':
sqlite3: Handle strings with embedded zeros correctly
http://hg.python.org/cpython/rev/93ac4b12a750

New changeset 6f4044afa600 by Petri Lehtinen in branch 'default':
Merge branch 3.2
http://hg.python.org/cpython/rev/6f4044afa600

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

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

From report at bugs.python.org  Wed Feb  1 21:57:38 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 01 Feb 2012 20:57:38 +0000
Subject: [issue13921] sqlite3: OptimizedUnicode doesn't work in Py3k
Message-ID: <1328129858.32.0.164852943165.issue13921@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

Connection.text_factory can be used to control what objects are
returned for the TEXT data type. An excerpt from the docs:

    For efficiency reasons, there?s also a way to return str
    objects only for non-ASCII data, and bytes otherwise. To
    activate it, set this attribute to sqlite3.OptimizedUnicode.

However, it always returns Unicode strings now. There's even a
test for this feature which is obviously wrong:

    def CheckOptimizedUnicode(self):
        self.con.text_factory = sqlite.OptimizedUnicode
        austria = "?sterreich"
        germany = "Deutchland"
        a_row = self.con.execute("select ?", (austria,)).fetchone()
        d_row = self.con.execute("select ?", (germany,)).fetchone()
        self.assertTrue(type(a_row[0]) == str, "type of non-ASCII row must be str")
        self.assertTrue(type(d_row[0]) == str, "type of ASCII-only row must be str")

It checks for str in both cases even though it should test for
bytes in the latter case.

---

The user can get bytes if he wants to by saying so explicitly.
Having the library mix bytes and unicode by itself makes it
harder for the user. Furthermore, I don't really buy
the "efficiency" reason here, so I'd vote for removing the whole
OptimizeUnicode thing. It has never worked for Py3k so it would
be safe.

----------
components: Library (Lib)
messages: 152441
nosy: petri.lehtinen, pitrou
priority: normal
severity: normal
status: open
title: sqlite3: OptimizedUnicode doesn't work in Py3k
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Feb  1 22:02:36 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Feb 2012 21:02:36 +0000
Subject: [issue13921] sqlite3: OptimizedUnicode doesn't work in Py3k
In-Reply-To: <1328129858.32.0.164852943165.issue13921@psf.upfronthosting.co.za>
Message-ID: <1328130156.79.0.758948601079.issue13921@psf.upfronthosting.co.za>


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

+1 for removing, it makes no sense under Python 3.

----------
nosy: +ghaering

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

From report at bugs.python.org  Wed Feb  1 22:42:36 2012
From: report at bugs.python.org (Warren Turkal)
Date: Wed, 01 Feb 2012 21:42:36 +0000
Subject: [issue13922] argparse handling multiple "--" in args improperly
Message-ID: <1328132556.72.0.92385645061.issue13922@psf.upfronthosting.co.za>


New submission from Warren Turkal <wt at penguintechs.org>:

I have a program that runs something like the following:
$ hack run -- :target --arg1 --arg2 arg3 arg4

This basically runs a program identified by :target with the args. However, I cannot pass "--" to the program. For example, if I type:
$ hack run -- :hack run -- :target clean --help

the second "--" is swallowed by the parser, and I get an the help for "hack run" instead of instead of "hack clean". The run subcommand just does the following:

all_args = [target.bin_path] + args.args
os.execv(target.bin_path, all_args)

However, the first hack run has the following list for args:
args = Namespace(args=['run', ':hack', 'clean', '--help'], func=<function do_run at 0x19c3e60>, target=':hack')

Where is the second "--"? I would have expected the args list to be:
args=['run', '--', ':hack', 'clean', '--help']

About the python version, I am using python 2.6. However, I am using the latest release of argparse from [1] and am assuming that it's very similar code.

[1]http://code.google.com/p/argparse/downloads/list

----------
messages: 152443
nosy: Warren.Turkal
priority: normal
severity: normal
status: open
title: argparse handling multiple "--" in args improperly
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Feb  1 22:54:32 2012
From: report at bugs.python.org (Warren Turkal)
Date: Wed, 01 Feb 2012 21:54:32 +0000
Subject: [issue13923] new formatter for argparse
Message-ID: <1328133272.3.0.771637871025.issue13923@psf.upfronthosting.co.za>


New submission from Warren Turkal <wt at penguintechs.org>:

It would be really nice to have a formatter for argparse that would respect explicit new lines while still wrapping lines otherwise.

This would allow the description and epilog to have be a little more structured while still getting the advantage of line wrapping.

----------
messages: 152444
nosy: Warren.Turkal
priority: normal
severity: normal
status: open
title: new formatter for argparse
type: enhancement

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

From report at bugs.python.org  Wed Feb  1 23:12:08 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 01 Feb 2012 22:12:08 +0000
Subject: [issue13817] deadlock in subprocess while running several threads
	using Popen
In-Reply-To: <1326909636.44.0.892345276723.issue13817@psf.upfronthosting.co.za>
Message-ID: <1328134328.54.0.84386058306.issue13817@psf.upfronthosting.co.za>


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

I thought about this a bit more, and I realized that a slight variation
of this bug also affects 2.7, and also older versions (i.e. before
_PyGILState_Reinit() was introduced), because any code that gets called
from PyOS_AfterFork() and uses the TLS API suffers from the same
problem.
I had the new test deadlock once, in theading._after_fork(): when trying
to acquire an (unlocked) lock, it got stuck in Py_END_ALLOW_THREADS,
which calls indirectly PyGILState_GetThisThreadState(), which calls
find_key().
Although less likely, this bug has been present for a *long* time, it's
surprising it had never been noticed before.
So the fix - calling PyThread_ReInitTLS() right at the beginning of PyOS_AfterFork() - should also be applied to 2.7.
I'll commit it tomorrow.

----------
Added file: http://bugs.python.org/file24389/reinit_tls_27.diff

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

From report at bugs.python.org  Wed Feb  1 23:29:56 2012
From: report at bugs.python.org (Ivaylo Popov)
Date: Wed, 01 Feb 2012 22:29:56 +0000
Subject: [issue13924] Mercurial robots.txt should let robots crawl landing
	pages.
Message-ID: <1328135396.1.0.0965106732225.issue13924@psf.upfronthosting.co.za>


New submission from Ivaylo Popov <popov.ivo at gmail.com>:

http://hg.python.org/robots.txt currently disallows all robots from all paths. This means that the site doesn't show up in Google search results seeking, for instance, browsing access to the python source
https://www.google.com/search?ie=UTF-8&q=python+source+browse
https://www.google.com/search?ie=UTF-8&q=python+repo+browse
https://www.google.com/search?ie=UTF-8&q=hg+python+browse
etc...

Instead, robots.txt should allow access to the landing page, http://hg.python.org/, and the landing pages for hosted projects, e.g. http://hg.python.org/cpython/, while prohibiting access to the */rev/*, */shortlog/*, ..., directories.

This change would be very easy, cost virtually nothing, and let users find the mercurial repository viewer from search engines. Note that http://svn.python.org/ does show up in search results, as an illustration of how convenient this is.

----------
components: None
messages: 152446
nosy: Ivaylo.Popov
priority: normal
severity: normal
status: open
title: Mercurial robots.txt should let robots crawl landing pages.
type: enhancement

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

From report at bugs.python.org  Thu Feb  2 01:17:32 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 02 Feb 2012 00:17:32 +0000
Subject: [issue7833] bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1328141852.49.0.933522270907.issue7833@psf.upfronthosting.co.za>


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

Mark:  Possibly a stupid question, but in your commit (see snippet below), why is the processorArchitecture hard coded to "x86"?  Is it appropriate to replace this with "amd64" for 64-bit builds, or should it always be "x86"?

+    <dependentAssembly>
+      <assemblyIdentity type="win32" name="Microsoft.VC90.CRT"
+         version="9.0.21022.8" processorArchitecture="x86"
+         publicKeyToken="XXXX">
+      </assemblyIdentity>
+    </dependentAssembly>

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

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

From report at bugs.python.org  Thu Feb  2 01:18:40 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 02 Feb 2012 00:18:40 +0000
Subject: [issue13889] str(float) and round(float) issues with FPU precision
In-Reply-To: <1327676303.66.0.487112802864.issue13889@psf.upfronthosting.co.za>
Message-ID: <1328141920.1.0.499374096537.issue13889@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
assignee:  -> mark.dickinson
type:  -> behavior

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

From report at bugs.python.org  Thu Feb  2 01:30:56 2012
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 02 Feb 2012 00:30:56 +0000
Subject: [issue7833] bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1328142656.23.0.726250290054.issue7833@psf.upfronthosting.co.za>


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

ack - that is a really good point.  IIRC it can be "*".  I'll try and look at this over the next day or 2.

----------

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

From report at bugs.python.org  Thu Feb  2 01:33:24 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 02 Feb 2012 00:33:24 +0000
Subject: [issue13889] str(float) and round(float) issues with FPU precision
In-Reply-To: <1327676303.66.0.487112802864.issue13889@psf.upfronthosting.co.za>
Message-ID: <1328142804.26.0.0908198802373.issue13889@psf.upfronthosting.co.za>


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

> Should this bug be marked as "closed+committed"?

No, the main issue is still under consideration.

There were two issues here:

(1) a clear bug, namely that the Py_SET_53BIT_PRECISION_* macros weren't being used for the dtoa calls when rounding, and

(2) a proposal to alter the way that the FPU settings are treated on Windows;  this is still open.

I'll change the type from behaviour, though.

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

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

From report at bugs.python.org  Thu Feb  2 01:40:49 2012
From: report at bugs.python.org (Dave E)
Date: Thu, 02 Feb 2012 00:40:49 +0000
Subject: [issue13925] making assignments to an empty two dimensional list
Message-ID: <1328143249.02.0.799282824218.issue13925@psf.upfronthosting.co.za>


New submission from Dave E <david.elzinga at gmail.com>:

I might be missing something, but I am expecting the following code to print out a list of lists with each internal list holding one number[0-4], but instead the internal lists are a copy of the list "count".  

#!/usr/bin/python
count = range(4)
twoDimensionList = [[]] * len(count)
for i in range(len(count)):
   twoDimensionList[i].append(count[i])
print twoDimensionList

Should print: 
[[0], [1], [2], [3]]

but erroneously prints:
[[0, 1, 2, 3], [0, 1, 2, 3], [0, 1, 2, 3], [0, 1, 2, 3]]

----------
files: twoDimensionalList.py
messages: 152450
nosy: drathlian
priority: normal
severity: normal
status: open
title: making assignments to an empty two dimensional list
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file24390/twoDimensionalList.py

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

From report at bugs.python.org  Thu Feb  2 01:47:08 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 02 Feb 2012 00:47:08 +0000
Subject: [issue13925] making assignments to an empty two dimensional list
In-Reply-To: <1328143249.02.0.799282824218.issue13925@psf.upfronthosting.co.za>
Message-ID: <1328143628.91.0.363603793291.issue13925@psf.upfronthosting.co.za>


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

This isn't a bug, but a known gotcha:  see.

http://docs.python.org/faq/programming.html#how-do-i-create-a-multidimensional-list

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Thu Feb  2 01:49:34 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 02 Feb 2012 00:49:34 +0000
Subject: [issue13919] invalid
Message-ID: <1328143774.62.0.409547623994.issue13919@psf.upfronthosting.co.za>


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


----------
title: kiss?my?ball?sac -> invalid

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

From report at bugs.python.org  Thu Feb  2 02:30:44 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Feb 2012 01:30:44 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1328146244.82.0.635057115204.issue13703@psf.upfronthosting.co.za>


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

It looks like it was not yet decided if the CryptoGen API or a weak LCG should be used on Windows. Extract of add-randomization-to-3.1-dmalcolm-2012-02-01-001.patch:

+#ifdef MS_WINDOWS
+#if 1
+        (void)win32_urandom((unsigned char *)secret, secret_size, 0);
+#else
+        /* fast but weak RNG (fast initialization, weak seed) */

Does someone know how to link Python to advapi32.dll (on Windows) to avoid GetModuleHandle("advapi32.dll")?

----------

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

From report at bugs.python.org  Thu Feb  2 06:40:18 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Feb 2012 05:40:18 +0000
Subject: [issue13868] Add hyphen doc fix
In-Reply-To: <1327535890.98.0.936666267948.issue13868@psf.upfronthosting.co.za>
Message-ID: <1328161218.41.0.998830948981.issue13868@psf.upfronthosting.co.za>


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

Bo?tjan, please stop wasting everyone's time.

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

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

From report at bugs.python.org  Thu Feb  2 02:18:28 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 02 Feb 2012 01:18:28 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1327966904.94.0.273785927847.issue13703@psf.upfronthosting.co.za>
Message-ID: <1328145445.18775.14.camel@surprise>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

On Mon, 2012-01-30 at 23:41 +0000, Martin wrote:
> Martin <gzlist at googlemail.com> added the comment:
> 
> > Has anyone had a chance to try this patch on Windows?  Martin?  I'm
> > hoping that it doesn't impose a startup cost in the default
> > no-randomization cost, and that any startup cost in the -R case is
> > acceptable.
> 
> Just tested as requested. Is the patch against 3.1 for a reason? Can't
> really be compared to earlier results, but get enough weird outliers
> that that may not be useful anyway. Also needed the following change:
> 
> -+        chunk = Py_MIN(size, INT_MAX);
> ++        chunk = size > INT_MAX ? INT_MAX : size;
> 
> Summary, looks like extra work in the default case is avoided and
> isn't crippling otherwise, though there were a couple of very odd runs
> not presented probably due to other disk access.

Thanks for testing this!

Oops, yes: Py_MIN is only present in "default" [it was added to
Include/Python.h (as PY_MIN) in 72475:8beaa9a37387 for PEP 393, renamed
to Py_MIN in 72489:dacac31460c0, eventually reaching Include/pymacro.h
in 72512:36fc514de7f0]

"orig_size" in win32_urandom was apparently unused, so I've removed it.

I also found and fixed an occasional failure in my 2.6 backport of the
new test_os.URandomTests.get_urandom_subprocess.

Am attaching 4 patches containing the above changes, plus patches to fix
dict/set ordering assumptions that start breaking if you try to run the
test suite with randomization enabled:
   add-randomization-to-2.6-dmalcolm-2012-02-01-001.patch
   fix-broken-tests-on-2.6-dmalcolm-2012-02-01-001.patch
   add-randomization-to-3.1-dmalcolm-2012-02-01-001.patch
   fix-broken-tests-on-3.1-dmalcolm-2012-02-01-001.patch

2.6 also could use the dict-ordering fix for test_symtable that was
fixed in 2.7 as 74256:789d59773801

FWIW I'm seeing a failure this failure in test_urllib2, but I also see
it with a clean checkout of 2.6:
======================================================================
ERROR: test_invalid_redirect (__main__.HandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_urllib2.py", line 963, in test_invalid_redirect
    MockHeaders({"location": valid_url}))
  File
"/home/david/coding/python-hg/cpython-2.6-hash-randomization/Lib/urllib2.py", line 616, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File
"/home/david/coding/python-hg/cpython-2.6-hash-randomization/Lib/urllib2.py", line 218, in __getattr__
    raise AttributeError, attr
AttributeError: timeout

----------
Added file: http://bugs.python.org/file24391/add-randomization-to-2.6-dmalcolm-2012-02-01-001.patch
Added file: http://bugs.python.org/file24392/fix-broken-tests-on-2.6-dmalcolm-2012-02-01-001.patch
Added file: http://bugs.python.org/file24393/add-randomization-to-3.1-dmalcolm-2012-02-01-001.patch
Added file: http://bugs.python.org/file24394/fix-broken-tests-on-3.1-dmalcolm-2012-02-01-001.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________
-------------- next part --------------
diff -r 9a4131ada792 Doc/library/sys.rst
--- a/Doc/library/sys.rst	Fri Jan 27 09:42:45 2012 +0100
+++ b/Doc/library/sys.rst	Wed Feb 01 20:09:37 2012 -0500
@@ -289,6 +289,8 @@
    +------------------------------+------------------------------------------+
    | :const:`bytes_warning`       | -b                                       |
    +------------------------------+------------------------------------------+
+   | :const:`hash_randomization`  | -R                                       |
+   +------------------------------+------------------------------------------+
 
    .. versionadded:: 2.6
 
diff -r 9a4131ada792 Doc/reference/datamodel.rst
--- a/Doc/reference/datamodel.rst	Fri Jan 27 09:42:45 2012 +0100
+++ b/Doc/reference/datamodel.rst	Wed Feb 01 20:09:37 2012 -0500
@@ -1273,6 +1273,8 @@
       modules are still available at the time when the :meth:`__del__` method is
       called.
 
+   See also the :option:`-R` command-line option.
+
 
 .. method:: object.__repr__(self)
 
diff -r 9a4131ada792 Doc/using/cmdline.rst
--- a/Doc/using/cmdline.rst	Fri Jan 27 09:42:45 2012 +0100
+++ b/Doc/using/cmdline.rst	Wed Feb 01 20:09:37 2012 -0500
@@ -21,7 +21,7 @@
 
 When invoking Python, you may specify any of these options::
 
-    python [-BdEiOQsStuUvVWxX3?] [-c command | -m module-name | script | - ] [args]
+    python [-BdEiOQsRStuUvVWxX3?] [-c command | -m module-name | script | - ] [args]
 
 The most common use case is, of course, a simple invocation of a script::
 
@@ -239,6 +239,30 @@
       :pep:`238` -- Changing the division operator
 
 
+.. cmdoption:: -R
+
+   Turn on "hash randomization, so that the :meth:`__hash__` values of str,
+   bytes and datetime objects are "salted" with an unpredictable random value.
+   Although they remain constant within an individual Python process, they
+   are not predictable between repeated invocations of Python.
+
+   This is intended to provide protection against a denial-of-service
+   caused by carefully-chosen inputs that exploit the worst case performance
+   of a dict lookup, O(n^2) complexity.  See:
+
+       http://www.ocert.org/advisories/ocert-2011-003.html
+
+   for details.
+
+   Changing hash values affects the order in which keys are retrieved from
+   a dict.  Although Python has never made guarantees about this ordering
+   (and it typically varies between 32-bit and 64-bit builds), enough
+   real-world code implicitly relies on this non-guaranteed behavior that
+   the randomization is disabled by default.
+
+   See also :envvar:`PYTHONHASHRANDOMIZATION`.
+
+
 .. cmdoption:: -s
 
    Don't add user site directory to sys.path
@@ -501,6 +525,24 @@
 
    .. versionadded:: 2.6
 
+.. envvar:: PYTHONHASHRANDOMIZATION
+
+   If this is set to a non-empty string it is equivalent to specifying the
+   :option:`-R` option.
+
+
+.. envvar:: PYTHONHASHSEED
+
+   If this is set, it is used as a fixed seed for generating the hash() of
+   the types covered by the :option:`-R` option (or its equivalent,
+   :envvar:`PYTHONHASHRANDOMIZATION`.
+
+   Its purpose is for use in selftests for the interpreter.
+
+   It should be a decimal number in the range [0; 4294967295].  Specifying
+   the value 0 overrides the other setting, disabling the hash random salt.
+
+
 .. envvar:: PYTHONIOENCODING
 
    Overrides the encoding used for stdin/stdout/stderr, in the syntax
diff -r 9a4131ada792 Include/object.h
--- a/Include/object.h	Fri Jan 27 09:42:45 2012 +0100
+++ b/Include/object.h	Wed Feb 01 20:09:37 2012 -0500
@@ -506,6 +506,12 @@
 PyAPI_FUNC(long) _Py_HashDouble(double);
 PyAPI_FUNC(long) _Py_HashPointer(void*);
 
+typedef struct {
+    long prefix;
+    long suffix;
+} _Py_HashSecret_t;
+PyAPI_DATA(_Py_HashSecret_t) _Py_HashSecret;
+
 /* Helper for passing objects to printf and the like */
 #define PyObject_REPR(obj) PyString_AS_STRING(PyObject_Repr(obj))
 
diff -r 9a4131ada792 Include/pydebug.h
--- a/Include/pydebug.h	Fri Jan 27 09:42:45 2012 +0100
+++ b/Include/pydebug.h	Wed Feb 01 20:09:37 2012 -0500
@@ -26,6 +26,7 @@
 PyAPI_DATA(int) _Py_QnewFlag;
 /* Warn about 3.x issues */
 PyAPI_DATA(int) Py_Py3kWarningFlag;
+PyAPI_DATA(int) Py_HashRandomizationFlag;
 
 /* this is a wrapper around getenv() that pays attention to
    Py_IgnoreEnvironmentFlag.  It should be used for getting variables like
diff -r 9a4131ada792 Include/pythonrun.h
--- a/Include/pythonrun.h	Fri Jan 27 09:42:45 2012 +0100
+++ b/Include/pythonrun.h	Wed Feb 01 20:09:37 2012 -0500
@@ -168,6 +168,8 @@
 PyAPI_FUNC(PyOS_sighandler_t) PyOS_getsig(int);
 PyAPI_FUNC(PyOS_sighandler_t) PyOS_setsig(int, PyOS_sighandler_t);
 
+/* Random */
+PyAPI_FUNC(int) _PyOS_URandom (void *buffer, Py_ssize_t size);
 
 #ifdef __cplusplus
 }
diff -r 9a4131ada792 Lib/os.py
--- a/Lib/os.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/os.py	Wed Feb 01 20:09:37 2012 -0500
@@ -742,22 +742,3 @@
                      _make_statvfs_result)
 except NameError: # statvfs_result may not exist
     pass
-
-if not _exists("urandom"):
-    def urandom(n):
-        """urandom(n) -> str
-
-        Return a string of n random bytes suitable for cryptographic use.
-
-        """
-        try:
-            _urandomfd = open("/dev/urandom", O_RDONLY)
-        except (OSError, IOError):
-            raise NotImplementedError("/dev/urandom (or equivalent) not found")
-        try:
-            bs = b""
-            while n - len(bs) >= 1:
-                bs += read(_urandomfd, n - len(bs))
-        finally:
-            close(_urandomfd)
-        return bs
diff -r 9a4131ada792 Lib/test/test_cmd_line.py
--- a/Lib/test/test_cmd_line.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_cmd_line.py	Wed Feb 01 20:09:37 2012 -0500
@@ -103,6 +103,20 @@
             self.exit_code('-c', 'pass'),
             0)
 
+    def test_hash_randomization(self):
+        # Verify that -R enables hash randomization:
+        self.verify_valid_flag('-R')
+        hashes = []
+        for i in range(2):
+            code = 'print(hash("spam"))'
+            data = self.start_python('-R', '-c', code)
+            hashes.append(data)
+        self.assertNotEqual(hashes[0], hashes[1])
+
+        # Verify that sys.flags contains hash_randomization
+        code = 'import sys; print(sys.flags)'
+        data = self.start_python('-R', '-c', code)
+        self.assertTrue('hash_randomization=1' in data)
 
 def test_main():
     test.test_support.run_unittest(CmdLineTest)
diff -r 9a4131ada792 Lib/test/test_hash.py
--- a/Lib/test/test_hash.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_hash.py	Wed Feb 01 20:09:37 2012 -0500
@@ -3,10 +3,14 @@
 #
 # Also test that hash implementations are inherited as expected
 
+import struct
+import subprocess
+import sys
 import unittest
 from test import test_support
 from collections import Hashable
 
+IS_64BIT = (struct.calcsize('l') == 8)
 
 class HashEqualityTestCase(unittest.TestCase):
 
@@ -133,10 +137,84 @@
         for obj in self.hashes_to_check:
             self.assertEqual(hash(obj), _default_hash(obj))
 
+class HashRandomizationTests(unittest.TestCase):
+
+    # Each subclass should define a field "repr_", containing the repr() of
+    # an object to be tested
+
+    def get_hash_command(self, repr_):
+        return 'print(hash(%s))' % repr_
+
+    def get_hash(self, repr_, randomization=None, seed=None):
+        env = {}
+        if randomization is not None:
+            env['PYTHONHASHRANDOMIZATION'] = str(randomization)
+        if seed is not None:
+            env['PYTHONHASHSEED'] = str(seed)
+        cmd_line = [sys.executable,
+                    '-c', self.get_hash_command(repr_)]
+        p = subprocess.Popen(cmd_line, stdin=subprocess.PIPE,
+                             stdout=subprocess.PIPE, stderr=subprocess.STDOUT,
+                             env=env)
+        out, err = p.communicate()
+        return int(out.strip())
+
+    def test_randomized_hash(self):
+        # two runs should return different hashes
+        run1 = self.get_hash(self.repr_, randomization=1)
+        run2 = self.get_hash(self.repr_, randomization=1)
+        self.assertNotEqual(run1, run2)
+
+class StringlikeHashRandomizationTests(HashRandomizationTests):
+    def test_null_hash(self):
+        # PYTHONHASHSEED=0 disables the randomized hash
+        if IS_64BIT:
+            known_hash_of_obj = 1453079729188098211
+        else:
+            known_hash_of_obj = -1600925533
+
+        # Randomization is disabled by default:
+        self.assertEqual(self.get_hash(self.repr_), known_hash_of_obj)
+
+        # If enabled, it can still be disabled by setting the seed to 0:
+        self.assertEqual(self.get_hash(self.repr_, randomization=1, seed=0),
+                         known_hash_of_obj)
+
+    def test_fixed_hash(self):
+        # test a fixed seed for the randomized hash
+        # Note that all types share the same values:
+        if IS_64BIT:
+            h = -4410911502303878509
+        else:
+            h = -206076799
+        self.assertEqual(self.get_hash(self.repr_, randomization=1, seed=42),
+                         h)
+
+class StrHashRandomizationTests(StringlikeHashRandomizationTests):
+    repr_ = repr('abc')
+
+    def test_empty_string(self):
+        self.assertEqual(hash(""), 0)
+
+class UnicodeHashRandomizationTests(StringlikeHashRandomizationTests):
+    repr_ = repr(u'abc')
+
+    def test_empty_string(self):
+        self.assertEqual(hash(u""), 0)
+
+class BufferHashRandomizationTests(StringlikeHashRandomizationTests):
+    repr_ = 'buffer("abc")'
+
+    def test_empty_string(self):
+        self.assertEqual(hash(buffer("")), 0)
+
 def test_main():
     test_support.run_unittest(HashEqualityTestCase,
                               HashInheritanceTestCase,
-                              HashBuiltinsTestCase)
+                              HashBuiltinsTestCase,
+                              StrHashRandomizationTests,
+                              UnicodeHashRandomizationTests,
+                              BufferHashRandomizationTests)
 
 
 if __name__ == "__main__":
diff -r 9a4131ada792 Lib/test/test_os.py
--- a/Lib/test/test_os.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_os.py	Wed Feb 01 20:09:37 2012 -0500
@@ -5,6 +5,7 @@
 import os
 import unittest
 import warnings
+import subprocess
 import sys
 from test import test_support
 
@@ -499,18 +500,45 @@
 
 class URandomTests (unittest.TestCase):
     def test_urandom(self):
-        try:
-            with test_support.check_warnings():
-                self.assertEqual(len(os.urandom(1)), 1)
-                self.assertEqual(len(os.urandom(10)), 10)
-                self.assertEqual(len(os.urandom(100)), 100)
-                self.assertEqual(len(os.urandom(1000)), 1000)
-                # see http://bugs.python.org/issue3708
-                self.assertEqual(len(os.urandom(0.9)), 0)
-                self.assertEqual(len(os.urandom(1.1)), 1)
-                self.assertEqual(len(os.urandom(2.0)), 2)
-        except NotImplementedError:
-            pass
+        with test_support.check_warnings():
+            self.assertEqual(len(os.urandom(1)), 1)
+            self.assertEqual(len(os.urandom(10)), 10)
+            self.assertEqual(len(os.urandom(100)), 100)
+            self.assertEqual(len(os.urandom(1000)), 1000)
+            # see http://bugs.python.org/issue3708
+            self.assertEqual(len(os.urandom(0.9)), 0)
+            self.assertEqual(len(os.urandom(1.1)), 1)
+            self.assertEqual(len(os.urandom(2.0)), 2)
+
+    def test_urandom_length(self):
+        self.assertEqual(len(os.urandom(0)), 0)
+        self.assertEqual(len(os.urandom(1)), 1)
+        self.assertEqual(len(os.urandom(10)), 10)
+        self.assertEqual(len(os.urandom(100)), 100)
+        self.assertEqual(len(os.urandom(1000)), 1000)
+
+    def test_urandom_value(self):
+        data1 = os.urandom(16)
+        data2 = os.urandom(16)
+        self.assertNotEqual(data1, data2)
+
+    def get_urandom_subprocess(self, count):
+        code = '\n'.join((
+            'import os, sys',
+            'data = os.urandom(%s)' % count,
+            'sys.stdout.write(data)'))
+        cmd_line = [sys.executable,
+                    '-c', code]
+        p = subprocess.Popen(cmd_line, stdin=subprocess.PIPE,
+                             stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
+        out, err = p.communicate()
+        self.assertEqual(len(out), count)
+        return out
+
+    def test_urandom_subprocess(self):
+        data1 = self.get_urandom_subprocess(16)
+        data2 = self.get_urandom_subprocess(16)
+        self.assertNotEqual(data1, data2)
 
 class Win32ErrorTests(unittest.TestCase):
     def test_rename(self):
diff -r 9a4131ada792 Lib/test/test_set.py
--- a/Lib/test/test_set.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_set.py	Wed Feb 01 20:09:37 2012 -0500
@@ -688,6 +688,17 @@
         if self.repr is not None:
             self.assertEqual(repr(self.set), self.repr)
 
+    def check_repr_against_values(self):
+        text = repr(self.set)
+        self.assertTrue(text.startswith('{'))
+        self.assertTrue(text.endswith('}'))
+
+        result = text[1:-1].split(', ')
+        result.sort()
+        sorted_repr_values = [repr(value) for value in self.values]
+        sorted_repr_values.sort()
+        self.assertEqual(result, sorted_repr_values)
+
     def test_print(self):
         fo = open(test_support.TESTFN, "wb")
         try:
diff -r 9a4131ada792 Lib/test/test_sys.py
--- a/Lib/test/test_sys.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_sys.py	Wed Feb 01 20:09:37 2012 -0500
@@ -384,7 +384,7 @@
         attrs = ("debug", "py3k_warning", "division_warning", "division_new",
                  "inspect", "interactive", "optimize", "dont_write_bytecode",
                  "no_site", "ignore_environment", "tabcheck", "verbose",
-                 "unicode", "bytes_warning")
+                 "unicode", "bytes_warning", "hash_randomization")
         for attr in attrs:
             self.assert_(hasattr(sys.flags, attr), attr)
             self.assertEqual(type(getattr(sys.flags, attr)), int, attr)
diff -r 9a4131ada792 Makefile.pre.in
--- a/Makefile.pre.in	Fri Jan 27 09:42:45 2012 +0100
+++ b/Makefile.pre.in	Wed Feb 01 20:09:37 2012 -0500
@@ -280,6 +280,7 @@
 		Python/pymath.o \
 		Python/pystate.o \
 		Python/pythonrun.o \
+		Python/random.o \
 		Python/structmember.o \
 		Python/symtable.o \
 		Python/sysmodule.o \
diff -r 9a4131ada792 Misc/NEWS
--- a/Misc/NEWS	Fri Jan 27 09:42:45 2012 +0100
+++ b/Misc/NEWS	Wed Feb 01 20:09:37 2012 -0500
@@ -10,6 +10,12 @@
 Core and Builtins
 -----------------
 
+- Issue #13703: oCERT-2011-003: add -R command-line option and
+  PYTHONHASHRANDOMIZATION (and PYTHONHASHSEED) environment variables, to
+  provide an opt-in way to protect against denial of service attacks due to
+  hash collisions within the dict and set types.  Patch by David Malcolm,
+  based on work by Victor Stinner.
+
 Library
 -------
 
diff -r 9a4131ada792 Misc/python.man
--- a/Misc/python.man	Fri Jan 27 09:42:45 2012 +0100
+++ b/Misc/python.man	Wed Feb 01 20:09:37 2012 -0500
@@ -34,6 +34,9 @@
 .B \-O0
 ]
 [
+.B \-R
+]
+[
 .B -Q
 .I argument
 ]
@@ -151,6 +154,18 @@
 .B \-O0
 Discard docstrings in addition to the \fB-O\fP optimizations.
 .TP
+.B \-R
+Turn on "hash randomization", so that the hash() values of str, bytes and
+datetime objects are "salted" with an unpredictable pseudo-random value.
+Although they remain constant within an individual Python process, they are
+not predictable between repeated invocations of Python.
+.IP
+This is intended to provide protection against a denial of service
+caused by carefully-chosen inputs that exploit the worst case performance
+of a dict lookup, O(n^2) complexity.  See
+http://www.ocert.org/advisories/ocert-2011-003.html
+for details.
+.TP
 .BI "\-Q " argument
 Division control; see PEP 238.  The argument must be one of "old" (the
 default, int/int and long/long return an int or long), "new" (new
@@ -411,6 +426,9 @@
 If this is set to a non-empty string it is equivalent to specifying
 the \fB\-v\fP option. If set to an integer, it is equivalent to
 specifying \fB\-v\fP multiple times. 
+.IP PYTHONHASHRANDOMIZATION
+If this is set to a non-empty string it is equivalent to specifying the
+\fB\-R\fP option.
 .SH AUTHOR
 The Python Software Foundation: http://www.python.org/psf
 .SH INTERNET RESOURCES
diff -r 9a4131ada792 Modules/main.c
--- a/Modules/main.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Modules/main.c	Wed Feb 01 20:09:37 2012 -0500
@@ -40,7 +40,7 @@
 static int  orig_argc;
 
 /* command line options */
-#define BASE_OPTS "3bBc:dEhiJm:OQ:sStuUvVW:xX?"
+#define BASE_OPTS "3bBc:dEhiJm:OQ:RsStuUvVW:xX?"
 
 #ifndef RISCOS
 #define PROGRAM_OPTS BASE_OPTS
@@ -72,6 +72,9 @@
 -O     : optimize generated bytecode slightly; also PYTHONOPTIMIZE=x\n\
 -OO    : remove doc-strings in addition to the -O optimizations\n\
 -Q arg : division options: -Qold (default), -Qwarn, -Qwarnall, -Qnew\n\
+-R     : use a pseudo-random salt to make hash() values of various types be\n\
+         unpredictable between separate invocations of the interpreter, as\n\
+         a defence against denial-of-service attacks\n\
 -s     : don't add user site directory to sys.path; also PYTHONNOUSERSITE\n\
 -S     : don't imply 'import site' on initialization\n\
 -t     : issue warnings about inconsistent tab usage (-tt: issue errors)\n\
@@ -101,6 +104,11 @@
 PYTHONCASEOK : ignore case in 'import' statements (Windows).\n\
 PYTHONIOENCODING: Encoding[:errors] used for stdin/stdout/stderr.\n\
 ";
+static char *usage_6 = "\
+PYTHONHASHRANDOMIZATION : make hash() values of various types be unpredictable\n\
+                          between separate invocations of the interpreter, as\n\
+                          a defence against denial-of-service attacks\n\
+";
 
 
 static int
@@ -117,6 +125,7 @@
         fputs(usage_3, f);
         fprintf(f, usage_4, DELIM);
         fprintf(f, usage_5, DELIM, PYTHONHOMEHELP);
+        fputs(usage_6, f);
     }
 #if defined(__VMS)
     if (exitcode == 0) {
@@ -388,6 +397,10 @@
             PySys_AddWarnOption(_PyOS_optarg);
             break;
 
+        case 'R':
+            Py_HashRandomizationFlag++;
+            break;
+
         /* This space reserved for other options */
 
         default:
diff -r 9a4131ada792 Modules/posixmodule.c
--- a/Modules/posixmodule.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Modules/posixmodule.c	Wed Feb 01 20:09:37 2012 -0500
@@ -8371,117 +8371,35 @@
 }
 #endif
 
-#ifdef MS_WINDOWS
-
-PyDoc_STRVAR(win32_urandom__doc__,
+PyDoc_STRVAR(posix_urandom__doc__,
 "urandom(n) -> str\n\n\
-Return a string of n random bytes suitable for cryptographic use.");
-
-typedef BOOL (WINAPI *CRYPTACQUIRECONTEXTA)(HCRYPTPROV *phProv,\
-              LPCSTR pszContainer, LPCSTR pszProvider, DWORD dwProvType,\
-              DWORD dwFlags );
-typedef BOOL (WINAPI *CRYPTGENRANDOM)(HCRYPTPROV hProv, DWORD dwLen,\
-              BYTE *pbBuffer );
-
-static CRYPTGENRANDOM pCryptGenRandom = NULL;
-/* This handle is never explicitly released. Instead, the operating
-   system will release it when the process terminates. */
-static HCRYPTPROV hCryptProv = 0;
-
-static PyObject*
-win32_urandom(PyObject *self, PyObject *args)
-{
-    int howMany;
-    PyObject* result;
-
-    /* Read arguments */
-    if (! PyArg_ParseTuple(args, "i:urandom", &howMany))
-        return NULL;
-    if (howMany < 0)
-        return PyErr_Format(PyExc_ValueError,
-                            "negative argument not allowed");
-
-    if (hCryptProv == 0) {
-        HINSTANCE hAdvAPI32 = NULL;
-        CRYPTACQUIRECONTEXTA pCryptAcquireContext = NULL;
-
-        /* Obtain handle to the DLL containing CryptoAPI
-           This should not fail         */
-        hAdvAPI32 = GetModuleHandle("advapi32.dll");
-        if(hAdvAPI32 == NULL)
-            return win32_error("GetModuleHandle", NULL);
-
-        /* Obtain pointers to the CryptoAPI functions
-           This will fail on some early versions of Win95 */
-        pCryptAcquireContext = (CRYPTACQUIRECONTEXTA)GetProcAddress(
-                                        hAdvAPI32,
-                                        "CryptAcquireContextA");
-        if (pCryptAcquireContext == NULL)
-            return PyErr_Format(PyExc_NotImplementedError,
-                                "CryptAcquireContextA not found");
-
-        pCryptGenRandom = (CRYPTGENRANDOM)GetProcAddress(
-                                        hAdvAPI32, "CryptGenRandom");
-        if (pCryptGenRandom == NULL)
-            return PyErr_Format(PyExc_NotImplementedError,
-                                "CryptGenRandom not found");
-
-        /* Acquire context */
-        if (! pCryptAcquireContext(&hCryptProv, NULL, NULL,
-                                   PROV_RSA_FULL, CRYPT_VERIFYCONTEXT))
-            return win32_error("CryptAcquireContext", NULL);
-    }
-
-    /* Allocate bytes */
-    result = PyString_FromStringAndSize(NULL, howMany);
-    if (result != NULL) {
-        /* Get random data */
-        memset(PyString_AS_STRING(result), 0, howMany); /* zero seed */
-        if (! pCryptGenRandom(hCryptProv, howMany, (unsigned char*)
-                              PyString_AS_STRING(result))) {
-            Py_DECREF(result);
-            return win32_error("CryptGenRandom", NULL);
-        }
+Return n pseudo-random bytes.");
+
+static PyObject *
+posix_urandom(PyObject *self, PyObject *args)
+{
+    Py_ssize_t size;
+    PyObject *result;
+    int ret;
+ 
+     /* Read arguments */
+    if (!PyArg_ParseTuple(args, "n:urandom", &size))
+        return NULL;
+    if (size < 0)
+         return PyErr_Format(PyExc_ValueError,
+                             "negative argument not allowed");
+    result = PyBytes_FromStringAndSize(NULL, size);
+    if (result == NULL)
+        return NULL;
+
+    ret = _PyOS_URandom(PyBytes_AS_STRING(result),
+                        PyBytes_GET_SIZE(result));
+    if (ret == -1) {
+        Py_DECREF(result);
+        return NULL;
     }
     return result;
 }
-#endif
-
-#ifdef __VMS
-/* Use openssl random routine */
-#include <openssl/rand.h>
-PyDoc_STRVAR(vms_urandom__doc__,
-"urandom(n) -> str\n\n\
-Return a string of n random bytes suitable for cryptographic use.");
-
-static PyObject*
-vms_urandom(PyObject *self, PyObject *args)
-{
-    int howMany;
-    PyObject* result;
-
-    /* Read arguments */
-    if (! PyArg_ParseTuple(args, "i:urandom", &howMany))
-        return NULL;
-    if (howMany < 0)
-        return PyErr_Format(PyExc_ValueError,
-                            "negative argument not allowed");
-
-    /* Allocate bytes */
-    result = PyString_FromStringAndSize(NULL, howMany);
-    if (result != NULL) {
-        /* Get random data */
-        if (RAND_pseudo_bytes((unsigned char*)
-                              PyString_AS_STRING(result),
-                              howMany) < 0) {
-            Py_DECREF(result);
-            return PyErr_Format(PyExc_ValueError,
-                                "RAND_pseudo_bytes");
-        }
-    }
-    return result;
-}
-#endif
 
 static PyMethodDef posix_methods[] = {
     {"access",          posix_access, METH_VARARGS, posix_access__doc__},
@@ -8787,12 +8705,7 @@
 #ifdef HAVE_GETLOADAVG
     {"getloadavg",      posix_getloadavg, METH_NOARGS, posix_getloadavg__doc__},
 #endif
- #ifdef MS_WINDOWS
-    {"urandom", win32_urandom, METH_VARARGS, win32_urandom__doc__},
- #endif
- #ifdef __VMS
-    {"urandom", vms_urandom, METH_VARARGS, vms_urandom__doc__},
- #endif
+    {"urandom",         posix_urandom,   METH_VARARGS, posix_urandom__doc__},
     {NULL,              NULL}            /* Sentinel */
 };
 
diff -r 9a4131ada792 Objects/bufferobject.c
--- a/Objects/bufferobject.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Objects/bufferobject.c	Wed Feb 01 20:09:37 2012 -0500
@@ -334,10 +334,16 @@
         return -1;
     p = (unsigned char *) ptr;
     len = size;
-    x = *p << 7;
+    if (len == 0) {
+        self->b_hash = 0;
+        return 0;
+    }
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= size;
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
     self->b_hash = x;
diff -r 9a4131ada792 Objects/object.c
--- a/Objects/object.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Objects/object.c	Wed Feb 01 20:09:37 2012 -0500
@@ -1101,6 +1101,8 @@
     return -1;
 }
 
+_Py_HashSecret_t _Py_HashSecret;
+
 long
 PyObject_Hash(PyObject *v)
 {
diff -r 9a4131ada792 Objects/stringobject.c
--- a/Objects/stringobject.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Objects/stringobject.c	Wed Feb 01 20:09:37 2012 -0500
@@ -1212,11 +1212,17 @@
     if (a->ob_shash != -1)
         return a->ob_shash;
     len = Py_SIZE(a);
+    if (len == 0) {
+        a->ob_shash = 0;
+        return 0;
+    }
     p = (unsigned char *) a->ob_sval;
-    x = *p << 7;
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= Py_SIZE(a);
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
     a->ob_shash = x;
diff -r 9a4131ada792 Objects/unicodeobject.c
--- a/Objects/unicodeobject.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Objects/unicodeobject.c	Wed Feb 01 20:09:37 2012 -0500
@@ -6695,11 +6695,17 @@
     if (self->hash != -1)
         return self->hash;
     len = PyUnicode_GET_SIZE(self);
+    if (len == 0) {
+        self->hash = 0;
+        return 0;
+    }
     p = PyUnicode_AS_UNICODE(self);
-    x = *p << 7;
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= PyUnicode_GET_SIZE(self);
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
     self->hash = x;
diff -r 9a4131ada792 PCbuild/pythoncore.vcproj
--- a/PCbuild/pythoncore.vcproj	Fri Jan 27 09:42:45 2012 +0100
+++ b/PCbuild/pythoncore.vcproj	Wed Feb 01 20:09:37 2012 -0500
@@ -1779,6 +1779,10 @@
 				>
 			</File>
 			<File
+				RelativePath="..\Python\random.c"
+				>
+			</File>
+			<File
 				RelativePath="..\Python\structmember.c"
 				>
 			</File>
diff -r 9a4131ada792 Python/pythonrun.c
--- a/Python/pythonrun.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Python/pythonrun.c	Wed Feb 01 20:09:37 2012 -0500
@@ -67,6 +67,7 @@
 static void call_ll_exitfuncs(void);
 extern void _PyUnicode_Init(void);
 extern void _PyUnicode_Fini(void);
+extern void _PyRandom_Init(void);
 
 #ifdef WITH_THREAD
 extern void _PyGILState_Init(PyInterpreterState *, PyThreadState *);
@@ -89,6 +90,7 @@
   true divisions (which they will be in 2.3). */
 int _Py_QnewFlag = 0;
 int Py_NoUserSiteDirectory = 0; /* for -s and site.py */
+int Py_HashRandomizationFlag = 0; /* for -R and PYTHONHASHRANDOMIZATION */
 
 /* PyModule_GetWarningsModule is no longer necessary as of 2.6
 since _warnings is builtin.  This API should not be used. */
@@ -166,6 +168,10 @@
         Py_OptimizeFlag = add_flag(Py_OptimizeFlag, p);
     if ((p = Py_GETENV("PYTHONDONTWRITEBYTECODE")) && *p != '\0')
         Py_DontWriteBytecodeFlag = add_flag(Py_DontWriteBytecodeFlag, p);
+    if ((p = Py_GETENV("PYTHONHASHRANDOMIZATION")) && *p != '\0')
+        Py_HashRandomizationFlag = add_flag(Py_HashRandomizationFlag, p);
+    
+    _PyRandom_Init();
 
     interp = PyInterpreterState_New();
     if (interp == NULL)
diff -r 9a4131ada792 Python/random.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Python/random.c	Wed Feb 01 20:09:37 2012 -0500
@@ -0,0 +1,283 @@
+#include "Python.h"
+#ifdef MS_WINDOWS
+#include <windows.h>
+#else
+#include <fcntl.h>
+#endif
+
+static int random_initialized = 0;
+
+#ifdef MS_WINDOWS
+typedef BOOL (WINAPI *CRYPTACQUIRECONTEXTA)(HCRYPTPROV *phProv,\
+              LPCSTR pszContainer, LPCSTR pszProvider, DWORD dwProvType,\
+              DWORD dwFlags );
+typedef BOOL (WINAPI *CRYPTGENRANDOM)(HCRYPTPROV hProv, DWORD dwLen,\
+              BYTE *pbBuffer );
+
+static CRYPTGENRANDOM pCryptGenRandom = NULL;
+/* This handle is never explicitly released. Instead, the operating
+   system will release it when the process terminates. */
+static HCRYPTPROV hCryptProv = 0;
+
+static int
+win32_urandom_init(int raise)
+{
+    HINSTANCE hAdvAPI32 = NULL;
+    CRYPTACQUIRECONTEXTA pCryptAcquireContext = NULL;
+
+    /* Obtain handle to the DLL containing CryptoAPI. This should not fail. */
+    hAdvAPI32 = GetModuleHandle("advapi32.dll");
+    if(hAdvAPI32 == NULL)
+        goto error;
+
+    /* Obtain pointers to the CryptoAPI functions. This will fail on some early
+       versions of Win95. */
+    pCryptAcquireContext = (CRYPTACQUIRECONTEXTA)GetProcAddress(
+                               hAdvAPI32, "CryptAcquireContextA");
+    if (pCryptAcquireContext == NULL)
+        goto error;
+
+    pCryptGenRandom = (CRYPTGENRANDOM)GetProcAddress(hAdvAPI32,
+                                                     "CryptGenRandom");
+    if (pCryptGenRandom == NULL)
+        goto error;
+
+    /* Acquire context */
+    if (! pCryptAcquireContext(&hCryptProv, NULL, NULL,
+                               PROV_RSA_FULL, CRYPT_VERIFYCONTEXT))
+        goto error;
+
+    return 0;
+
+error:
+    if (raise)
+        PyErr_SetFromWindowsErr(0);
+    else
+        Py_FatalError("Fail to initialize Windows random API (CryptoGen)");
+    return -1;
+}
+
+/* Fill buffer with size pseudo-random bytes generated by the Windows CryptoGen
+   API. Return 0 on success, or -1 on error. */
+static int
+win32_urandom(unsigned char *buffer, Py_ssize_t size, int raise)
+{
+    Py_ssize_t chunk;
+
+    if (hCryptProv == 0)
+    {
+        if (win32_urandom_init(raise) == -1)
+            return -1;
+    }
+
+    while (size > 0)
+    {
+        chunk = size > INT_MAX ? INT_MAX : size;
+        if (!pCryptGenRandom(hCryptProv, chunk, buffer))
+        {
+            /* CryptGenRandom() failed */
+            if (raise)
+                PyErr_SetFromWindowsErr(0);
+            else
+                Py_FatalError("Fail to initialized the randomized hash "
+                        "secret using CryptoGen)");
+            return -1;
+        }
+        buffer += chunk;
+        size -= chunk;
+    }
+    return 0;
+}
+
+#else
+
+/* Read size bytes from /dev/urandom into buffer.
+   Call Py_FatalError() on error. */
+static void
+dev_urandom_noraise(char *buffer, Py_ssize_t size)
+{
+    int fd;
+    Py_ssize_t n;
+
+    assert (0 < size);
+
+    fd = open("/dev/urandom", O_RDONLY);
+    if (fd < 0)
+        Py_FatalError("Fail to open /dev/urandom");
+
+    while (0 < size)
+    {
+        do {
+            n = read(fd, buffer, (size_t)size);
+        } while (n < 0 && errno == EINTR);
+        if (n <= 0)
+        {
+            /* stop on error or if read(size) returned 0 */
+            Py_FatalError("Fail to read bytes from /dev/urandom");
+            break;
+        }
+        buffer += n;
+        size -= (Py_ssize_t)n;
+    }
+    close(fd);
+}
+
+/* Read size bytes from /dev/urandom into buffer.
+   Return 0 on success, raise an exception and return -1 on error. */
+static int
+dev_urandom_python(char *buffer, Py_ssize_t size)
+{
+    int fd;
+    Py_ssize_t n;
+
+    if (size <= 0)
+        return 0;
+
+    Py_BEGIN_ALLOW_THREADS
+    fd = open("/dev/urandom", O_RDONLY);
+    Py_END_ALLOW_THREADS
+    if (fd < 0)
+    {
+        PyErr_SetFromErrnoWithFilename(PyExc_OSError, "/dev/urandom");
+        return -1;
+    }
+
+    Py_BEGIN_ALLOW_THREADS
+    do {
+        do {
+            n = read(fd, buffer, (size_t)size);
+        } while (n < 0 && errno == EINTR);
+        if (n <= 0)
+            break;
+        buffer += n;
+        size -= (Py_ssize_t)n;
+    } while (0 < size);
+    Py_END_ALLOW_THREADS
+
+    if (n <= 0)
+    {
+        /* stop on error or if read(size) returned 0 */
+        if (n < 0)
+            PyErr_SetFromErrno(PyExc_OSError);
+        else
+            PyErr_Format(PyExc_RuntimeError,
+                         "Fail to read %zi bytes from /dev/urandom",
+                         size);
+        close(fd);
+        return -1;
+    }
+    close(fd);
+    return 0;
+}
+#endif
+
+/* Fill buffer with pseudo-random bytes generated by a linear congruent
+   generator (LCG):
+
+       x(n+1) = (x(n) * 214013 + 2531011) % 2^32
+
+   Use bits 23..16 of x(n) to generate a byte. */
+static void
+lcg_urandom(unsigned int x0, unsigned char *buffer, size_t size)
+{
+    size_t index;
+    unsigned int x;
+
+    x = x0;
+    for (index=0; index < size; index++) {
+        x *= 214013;
+        x += 2531011;
+        /* modulo 2 ^ (8 * sizeof(int)) */
+        buffer[index] = (x >> 16) & 0xff;
+    }
+}
+
+/* Fill buffer with size pseudo-random bytes, not suitable for cryptographic
+   use, from the operating random number generator (RNG).
+
+   Return 0 on success, raise an exception and return -1 on error. */
+int
+_PyOS_URandom(void *buffer, Py_ssize_t size)
+{
+    if (size < 0) {
+        PyErr_Format(PyExc_ValueError,
+                     "negative argument not allowed");
+        return -1;
+    }
+    if (size == 0)
+        return 0;
+
+#ifdef MS_WINDOWS
+    return win32_urandom((unsigned char *)buffer, size, 1);
+#else
+    return dev_urandom_python((char*)buffer, size);
+#endif
+}
+
+void
+_PyRandom_Init(void)
+{
+    char *env;
+    void *secret = &_Py_HashSecret;
+    Py_ssize_t secret_size = sizeof(_Py_HashSecret);
+
+    if (random_initialized)
+        return;
+    random_initialized = 1;
+
+    /*
+      By default, hash randomization is disabled, and only
+      enabled if PYTHONHASHRANDOMIZATION is set to non-empty
+      or if "-R" is provided at the command line:
+    */
+    if (!Py_HashRandomizationFlag) {
+        /* Disable the randomized hash: */
+        memset(secret, 0, secret_size);
+        return;
+    }
+
+    /*
+      PYTHONHASHRANDOMIZATION was found; generate a per-process secret,
+      using PYTHONHASHSEED if provided.
+    */
+
+    env = Py_GETENV("PYTHONHASHSEED");
+    if (env && *env != '\0') {
+        char *endptr = env;
+        unsigned long seed;
+        seed = strtoul(env, &endptr, 10);
+        if (*endptr != '\0'
+            || seed > 4294967295UL
+            || (errno == ERANGE && seed == ULONG_MAX))
+        {
+            Py_FatalError("PYTHONHASHSEED must be an integer "
+                          "in range [0; 4294967295]");
+        }
+        if (seed == 0) {
+            /* disable the randomized hash */
+            memset(secret, 0, secret_size);
+        }
+        else {
+            lcg_urandom(seed, (unsigned char*)secret, secret_size);
+        }
+    }
+    else {
+#ifdef MS_WINDOWS
+#if 1
+        (void)win32_urandom((unsigned char *)secret, secret_size, 0);
+#else
+        /* fast but weak RNG (fast initialization, weak seed) */
+        _PyTime_timeval t;
+        unsigned int seed;
+        _PyTime_gettimeofday(&t);
+        seed = (unsigned int)t.tv_sec;
+        seed ^= t.tv_usec;
+        seed ^= getpid();
+        lcg_urandom(seed, (unsigned char*)secret, secret_size);
+#endif
+#else /* #ifdef MS_WINDOWS */
+        dev_urandom_noraise((char*)secret, secret_size);
+#endif
+    }
+}
+
diff -r 9a4131ada792 Python/sysmodule.c
--- a/Python/sysmodule.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Python/sysmodule.c	Wed Feb 01 20:09:37 2012 -0500
@@ -1224,6 +1224,7 @@
     {"unicode",                 "-U"},
     /* {"skip_first",                   "-x"}, */
     {"bytes_warning", "-b"},
+    {"hash_randomization", "-R"},
     {0}
 };
 
@@ -1232,9 +1233,9 @@
     flags__doc__,       /* doc */
     flags_fields,       /* fields */
 #ifdef RISCOS
+    17
+#else
     16
-#else
-    15
 #endif
 };
 
@@ -1271,6 +1272,7 @@
     SetFlag(Py_UnicodeFlag);
     /* SetFlag(skipfirstline); */
     SetFlag(Py_BytesWarningFlag);
+    SetFlag(Py_HashRandomizationFlag);
 #undef SetFlag
 
     if (PyErr_Occurred()) {
-------------- next part --------------
diff -r 9a4131ada792 Lib/json/__init__.py
--- a/Lib/json/__init__.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/json/__init__.py	Wed Feb 01 20:10:16 2012 -0500
@@ -29,8 +29,8 @@
 Compact encoding::
 
     >>> import json
-    >>> json.dumps([1,2,3,{'4': 5, '6': 7}], separators=(',',':'))
-    '[1,2,3,{"4":5,"6":7}]'
+    >>> json.dumps([1,2,3,{"4":"5"}], separators=(',',':'))
+    '[1,2,3,{"4":"5"}]'
 
 Pretty printing (using repr() because of extraneous whitespace in the output)::
 
-------------- next part --------------
diff -r e7706bdaaa0d Doc/library/sys.rst
--- a/Doc/library/sys.rst	Fri Jan 27 09:48:47 2012 +0100
+++ b/Doc/library/sys.rst	Wed Feb 01 20:09:56 2012 -0500
@@ -220,6 +220,7 @@
    :const:`ignore_environment`   :option:`-E`
    :const:`verbose`              :option:`-v`
    :const:`bytes_warning`        :option:`-b`
+   :const:`hash_randomization`   :option:`-R`
    ============================= =============================
 
 
diff -r e7706bdaaa0d Doc/reference/datamodel.rst
--- a/Doc/reference/datamodel.rst	Fri Jan 27 09:48:47 2012 +0100
+++ b/Doc/reference/datamodel.rst	Wed Feb 01 20:09:56 2012 -0500
@@ -1265,6 +1265,8 @@
    inheritance of :meth:`__hash__` will be blocked, just as if :attr:`__hash__`
    had been explicitly set to :const:`None`.
 
+   See also the :option:`-R` command-line option.
+
 
 .. method:: object.__bool__(self)
 
diff -r e7706bdaaa0d Doc/using/cmdline.rst
--- a/Doc/using/cmdline.rst	Fri Jan 27 09:48:47 2012 +0100
+++ b/Doc/using/cmdline.rst	Wed Feb 01 20:09:56 2012 -0500
@@ -21,7 +21,7 @@
 
 When invoking Python, you may specify any of these options::
 
-    python [-bBdEhiOsSuvVWx?] [-c command | -m module-name | script | - ] [args]
+    python [-bBdEhiORsSuvVWx?] [-c command | -m module-name | script | - ] [args]
 
 The most common use case is, of course, a simple invocation of a script::
 
@@ -215,6 +215,30 @@
    Discard docstrings in addition to the :option:`-O` optimizations.
 
 
+.. cmdoption:: -R
+
+   Turn on "hash randomization, so that the :meth:`__hash__` values of str,
+   bytes and datetime objects are "salted" with an unpredictable random value.
+   Although they remain constant within an individual Python process, they
+   are not predictable between repeated invocations of Python.
+
+   This is intended to provide protection against a denial-of-service
+   caused by carefully-chosen inputs that exploit the worst case performance
+   of a dict lookup, O(n^2) complexity.  See:
+
+       http://www.ocert.org/advisories/ocert-2011-003.html
+
+   for details.
+
+   Changing hash values affects the order in which keys are retrieved from
+   a dict.  Although Python has never made guarantees about this ordering
+   (and it typically varies between 32-bit and 64-bit builds), enough
+   real-world code implicitly relies on this non-guaranteed behavior that
+   the randomization is disabled by default.
+
+   See also :envvar:`PYTHONHASHRANDOMIZATION`.
+
+
 .. cmdoption:: -s
 
    Don't add user site directory to sys.path
@@ -435,6 +459,24 @@
    import of source modules.
 
 
+.. envvar:: PYTHONHASHRANDOMIZATION
+
+   If this is set to a non-empty string it is equivalent to specifying the
+   :option:`-R` option.
+
+
+.. envvar:: PYTHONHASHSEED
+
+   If this is set, it is used as a fixed seed for generating the hash() of
+   the types covered by the :option:`-R` option (or its equivalent,
+   :envvar:`PYTHONHASHRANDOMIZATION`.
+
+   Its purpose is for use in selftests for the interpreter.
+
+   It should be a decimal number in the range [0; 4294967295].  Specifying
+   the value 0 overrides the other setting, disabling the hash random salt.
+
+
 .. envvar:: PYTHONIOENCODING
 
    Overrides the encoding used for stdin/stdout/stderr, in the syntax
diff -r e7706bdaaa0d Include/object.h
--- a/Include/object.h	Fri Jan 27 09:48:47 2012 +0100
+++ b/Include/object.h	Wed Feb 01 20:09:56 2012 -0500
@@ -473,6 +473,12 @@
 PyAPI_FUNC(long) _Py_HashDouble(double);
 PyAPI_FUNC(long) _Py_HashPointer(void*);
 
+typedef struct {
+    long prefix;
+    long suffix;
+} _Py_HashSecret_t;
+PyAPI_DATA(_Py_HashSecret_t) _Py_HashSecret;
+
 /* Helper for passing objects to printf and the like */
 #define PyObject_REPR(obj) _PyUnicode_AsString(PyObject_Repr(obj))
 
diff -r e7706bdaaa0d Include/pydebug.h
--- a/Include/pydebug.h	Fri Jan 27 09:48:47 2012 +0100
+++ b/Include/pydebug.h	Wed Feb 01 20:09:56 2012 -0500
@@ -19,6 +19,7 @@
 PyAPI_DATA(int) Py_DontWriteBytecodeFlag;
 PyAPI_DATA(int) Py_NoUserSiteDirectory;
 PyAPI_DATA(int) Py_UnbufferedStdioFlag;
+PyAPI_DATA(int) Py_HashRandomizationFlag;
 
 /* this is a wrapper around getenv() that pays attention to
    Py_IgnoreEnvironmentFlag.  It should be used for getting variables like
diff -r e7706bdaaa0d Include/pythonrun.h
--- a/Include/pythonrun.h	Fri Jan 27 09:48:47 2012 +0100
+++ b/Include/pythonrun.h	Wed Feb 01 20:09:56 2012 -0500
@@ -174,6 +174,8 @@
 PyAPI_FUNC(PyOS_sighandler_t) PyOS_getsig(int);
 PyAPI_FUNC(PyOS_sighandler_t) PyOS_setsig(int, PyOS_sighandler_t);
 
+/* Random */
+PyAPI_FUNC(int) _PyOS_URandom (void *buffer, Py_ssize_t size);
 
 #ifdef __cplusplus
 }
diff -r e7706bdaaa0d Lib/os.py
--- a/Lib/os.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/os.py	Wed Feb 01 20:09:56 2012 -0500
@@ -611,23 +611,6 @@
 except NameError: # statvfs_result may not exist
     pass
 
-if not _exists("urandom"):
-    def urandom(n):
-        """urandom(n) -> str
-
-        Return a string of n random bytes suitable for cryptographic use.
-
-        """
-        try:
-            _urandomfd = open("/dev/urandom", O_RDONLY)
-        except (OSError, IOError):
-            raise NotImplementedError("/dev/urandom (or equivalent) not found")
-        bs = b""
-        while len(bs) < n:
-            bs += read(_urandomfd, n - len(bs))
-        close(_urandomfd)
-        return bs
-
 # Supply os.popen()
 def popen(cmd, mode="r", buffering=-1):
     if not isinstance(cmd, str):
diff -r e7706bdaaa0d Lib/test/regrtest.py
--- a/Lib/test/regrtest.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/regrtest.py	Wed Feb 01 20:09:56 2012 -0500
@@ -428,6 +428,11 @@
         except ValueError:
             print("Couldn't find starting test (%s), using all tests" % start)
     if randomize:
+        hashseed = os.getenv('PYTHONHASHSEED')
+        if not hashseed:
+            os.environ['PYTHONHASHSEED'] = str(random_seed)
+            os.execv(sys.executable, [sys.executable] + sys.argv)
+            return
         random.seed(random_seed)
         print("Using random seed", random_seed)
         random.shuffle(tests)
diff -r e7706bdaaa0d Lib/test/test_cmd_line.py
--- a/Lib/test/test_cmd_line.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_cmd_line.py	Wed Feb 01 20:09:56 2012 -0500
@@ -190,6 +190,22 @@
             self.assertTrue(path1.encode('ascii') in stdout)
             self.assertTrue(path2.encode('ascii') in stdout)
 
+    def test_hash_randomization(self):
+        # Verify that -R enables hash randomization:
+        self.verify_valid_flag('-R')
+        hashes = []
+        for i in range(2):
+            code = 'print(hash("spam"))'
+            data, rc = self.start_python_and_exit_code('-R', '-c', code)
+            self.assertEqual(rc, 0)
+            hashes.append(data)
+        self.assertNotEqual(hashes[0], hashes[1])
+
+        # Verify that sys.flags contains hash_randomization
+        code = 'import sys; print(sys.flags)'
+        data, rc = self.start_python_and_exit_code('-R', '-c', code)
+        self.assertEqual(rc,0)
+        self.assertIn(b'hash_randomization=1', data)
 
 def test_main():
     test.support.run_unittest(CmdLineTest)
diff -r e7706bdaaa0d Lib/test/test_hash.py
--- a/Lib/test/test_hash.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_hash.py	Wed Feb 01 20:09:56 2012 -0500
@@ -3,10 +3,15 @@
 #
 # Also test that hash implementations are inherited as expected
 
+import datetime
+import struct
 import unittest
 from test import support
+from test.script_helper import assert_python_ok
 from collections import Hashable
 
+IS_64BIT = (struct.calcsize('l') == 8)
+
 
 class HashEqualityTestCase(unittest.TestCase):
 
@@ -118,10 +123,92 @@
         for obj in self.hashes_to_check:
             self.assertEqual(hash(obj), _default_hash(obj))
 
+class HashRandomizationTests(unittest.TestCase):
+
+    # Each subclass should define a field "repr_", containing the repr() of
+    # an object to be tested
+
+    def get_hash_command(self, repr_):
+        return 'print(hash(%s))' % repr_
+
+    def get_hash(self, repr_, randomization=None, seed=None):
+        env = {}
+        if randomization is not None:
+            env['PYTHONHASHRANDOMIZATION'] = str(randomization)
+        if seed is not None:
+            env['PYTHONHASHSEED'] = str(seed)
+        out = assert_python_ok(
+            '-c', self.get_hash_command(repr_),
+            **env)
+        stdout = out[1].strip()
+        return int(stdout)
+
+    def test_randomized_hash(self):
+        # two runs should return different hashes
+        run1 = self.get_hash(self.repr_, randomization=1)
+        run2 = self.get_hash(self.repr_, randomization=1)
+        self.assertNotEqual(run1, run2)
+
+class StringlikeHashRandomizationTests(HashRandomizationTests):
+    def test_null_hash(self):
+        # PYTHONHASHSEED=0 disables the randomized hash
+        if IS_64BIT:
+            known_hash_of_obj = 1453079729188098211
+        else:
+            known_hash_of_obj = -1600925533
+
+        # Randomization is disabled by default:
+        self.assertEqual(self.get_hash(self.repr_), known_hash_of_obj)
+
+        # If enabled, it can still be disabled by setting the seed to 0:
+        self.assertEqual(self.get_hash(self.repr_, randomization=1, seed=0),
+                         known_hash_of_obj)
+
+    def test_fixed_hash(self):
+        # test a fixed seed for the randomized hash
+        # Note that all types share the same values:
+        if IS_64BIT:
+            h = -4410911502303878509
+        else:
+            h = -206076799
+        self.assertEqual(self.get_hash(self.repr_, randomization=1, seed=42),
+                         h)
+
+class StrHashRandomizationTests(StringlikeHashRandomizationTests):
+    repr_ = repr('abc')
+
+    def test_empty_string(self):
+        self.assertEqual(hash(""), 0)
+
+class BytesHashRandomizationTests(StringlikeHashRandomizationTests):
+    repr_ = repr(b'abc')
+
+    def test_empty_string(self):
+        self.assertEqual(hash(b""), 0)
+
+class DatetimeTests(HashRandomizationTests):
+    def get_hash_command(self, repr_):
+        return 'import datetime; print(hash(%s))' % repr_
+
+class DatetimeDateTests(DatetimeTests):
+    repr_ = repr(datetime.date(1066, 10, 14))
+
+class DatetimeDatetimeTests(DatetimeTests):
+    repr_ = repr(datetime.datetime(1, 2, 3, 4, 5, 6, 7))
+
+class DatetimeTimeTests(DatetimeTests):
+    repr_ = repr(datetime.time(0))
+
 def test_main():
     support.run_unittest(HashEqualityTestCase,
                               HashInheritanceTestCase,
-                              HashBuiltinsTestCase)
+                              HashBuiltinsTestCase,
+                         StrHashRandomizationTests,
+                         BytesHashRandomizationTests,
+                         DatetimeDateTests,
+                         DatetimeDatetimeTests,
+                         DatetimeTimeTests)
+
 
 
 if __name__ == "__main__":
diff -r e7706bdaaa0d Lib/test/test_os.py
--- a/Lib/test/test_os.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_os.py	Wed Feb 01 20:09:56 2012 -0500
@@ -9,6 +9,7 @@
 import sys
 import shutil
 from test import support
+from test.script_helper import assert_python_ok
 
 # Detect whether we're on a Linux system that uses the (now outdated
 # and unmaintained) linuxthreads threading library.  There's an issue
@@ -574,14 +575,33 @@
         f.close()
 
 class URandomTests(unittest.TestCase):
-    def test_urandom(self):
-        try:
-            self.assertEqual(len(os.urandom(1)), 1)
-            self.assertEqual(len(os.urandom(10)), 10)
-            self.assertEqual(len(os.urandom(100)), 100)
-            self.assertEqual(len(os.urandom(1000)), 1000)
-        except NotImplementedError:
-            pass
+    def test_urandom_length(self):
+        self.assertEqual(len(os.urandom(0)), 0)
+        self.assertEqual(len(os.urandom(1)), 1)
+        self.assertEqual(len(os.urandom(10)), 10)
+        self.assertEqual(len(os.urandom(100)), 100)
+        self.assertEqual(len(os.urandom(1000)), 1000)
+
+    def test_urandom_value(self):
+        data1 = os.urandom(16)
+        data2 = os.urandom(16)
+        self.assertNotEqual(data1, data2)
+
+    def get_urandom_subprocess(self, count):
+        code = '\n'.join((
+            'import os, sys',
+            'data = os.urandom(%s)' % count,
+            'sys.stdout.buffer.write(data)',
+            'sys.stdout.buffer.flush()'))
+        out = assert_python_ok('-c', code)
+        stdout = out[1]
+        self.assertEqual(len(stdout), 16)
+        return stdout
+
+    def test_urandom_subprocess(self):
+        data1 = self.get_urandom_subprocess(16)
+        data2 = self.get_urandom_subprocess(16)
+        self.assertNotEqual(data1, data2)
 
 class ExecTests(unittest.TestCase):
     @unittest.skipIf(USING_LINUXTHREADS,
diff -r e7706bdaaa0d Lib/test/test_sys.py
--- a/Lib/test/test_sys.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_sys.py	Wed Feb 01 20:09:56 2012 -0500
@@ -446,7 +446,7 @@
         attrs = ("debug", "division_warning",
                  "inspect", "interactive", "optimize", "dont_write_bytecode",
                  "no_user_site", "no_site", "ignore_environment", "verbose",
-                 "bytes_warning")
+                 "bytes_warning", "hash_randomization")
         for attr in attrs:
             self.assertTrue(hasattr(sys.flags, attr), attr)
             self.assertEqual(type(getattr(sys.flags, attr)), int, attr)
diff -r e7706bdaaa0d Makefile.pre.in
--- a/Makefile.pre.in	Fri Jan 27 09:48:47 2012 +0100
+++ b/Makefile.pre.in	Wed Feb 01 20:09:56 2012 -0500
@@ -305,6 +305,7 @@
 		Python/pymath.o \
 		Python/pystate.o \
 		Python/pythonrun.o \
+		Python/random.o \
 		Python/structmember.o \
 		Python/symtable.o \
 		Python/sysmodule.o \
diff -r e7706bdaaa0d Misc/NEWS
--- a/Misc/NEWS	Fri Jan 27 09:48:47 2012 +0100
+++ b/Misc/NEWS	Wed Feb 01 20:09:56 2012 -0500
@@ -10,6 +10,12 @@
 Core and Builtins
 -----------------
 
+- Issue #13703: oCERT-2011-003: add -R command-line option and
+  PYTHONHASHRANDOMIZATION (and PYTHONHASHSEED) environment variables, to
+  provide an opt-in way to protect against denial of service attacks due to
+  hash collisions within the dict and set types.  Patch by David Malcolm,
+  based on work by Victor Stinner.
+
 Library
 -------
 
diff -r e7706bdaaa0d Misc/python.man
--- a/Misc/python.man	Fri Jan 27 09:48:47 2012 +0100
+++ b/Misc/python.man	Wed Feb 01 20:09:56 2012 -0500
@@ -34,6 +34,9 @@
 .B \-OO
 ]
 [
+.B \-R
+]
+[
 .B -Q
 .I argument
 ]
@@ -145,6 +148,18 @@
 .B \-OO
 Discard docstrings in addition to the \fB-O\fP optimizations.
 .TP
+.B \-R
+Turn on "hash randomization", so that the hash() values of str, bytes and
+datetime objects are "salted" with an unpredictable pseudo-random value.
+Although they remain constant within an individual Python process, they are
+not predictable between repeated invocations of Python.
+.IP
+This is intended to provide protection against a denial of service
+caused by carefully-chosen inputs that exploit the worst case performance
+of a dict lookup, O(n^2) complexity.  See
+http://www.ocert.org/advisories/ocert-2011-003.html
+for details.
+.TP
 .BI "\-Q " argument
 Division control; see PEP 238.  The argument must be one of "old" (the
 default, int/int and long/long return an int or long), "new" (new
@@ -403,6 +418,9 @@
 If this is set to a non-empty string it is equivalent to specifying
 the \fB\-v\fP option. If set to an integer, it is equivalent to
 specifying \fB\-v\fP multiple times. 
+.IP PYTHONHASHRANDOMIZATION
+If this is set to a non-empty string it is equivalent to specifying the
+\fB\-R\fP option.
 .SH AUTHOR
 The Python Software Foundation: http://www.python.org/psf
 .SH INTERNET RESOURCES
diff -r e7706bdaaa0d Modules/datetimemodule.c
--- a/Modules/datetimemodule.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Modules/datetimemodule.c	Wed Feb 01 20:09:56 2012 -0500
@@ -2566,10 +2566,12 @@
     register long x;
 
     p = (unsigned char *) data;
-    x = *p << 7;
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= len;
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
 
diff -r e7706bdaaa0d Modules/main.c
--- a/Modules/main.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Modules/main.c	Wed Feb 01 20:09:56 2012 -0500
@@ -47,7 +47,7 @@
 static int  orig_argc;
 
 /* command line options */
-#define BASE_OPTS L"bBc:dEhiJm:OsStuvVW:xX?"
+#define BASE_OPTS L"bBc:dEhiJm:ORsStuvVW:xX?"
 
 #define PROGRAM_OPTS BASE_OPTS
 
@@ -72,6 +72,9 @@
 -m mod : run library module as a script (terminates option list)\n\
 -O     : optimize generated bytecode slightly; also PYTHONOPTIMIZE=x\n\
 -OO    : remove doc-strings in addition to the -O optimizations\n\
+-R     : use a pseudo-random salt to make hash() values of various types be\n\
+         unpredictable between separate invocations of the interpreter, as\n\
+         a defence against denial-of-service attacks\n\
 -s     : don't add user site directory to sys.path; also PYTHONNOUSERSITE\n\
 -S     : don't imply 'import site' on initialization\n\
 ";
@@ -99,6 +102,11 @@
 PYTHONCASEOK : ignore case in 'import' statements (Windows).\n\
 PYTHONIOENCODING: Encoding[:errors] used for stdin/stdout/stderr.\n\
 ";
+static char *usage_6 = "\
+PYTHONHASHRANDOMIZATION : make hash() values of various types be unpredictable\n\
+                          between separate invocations of the interpreter, as\n\
+                          a defence against denial-of-service attacks\n\
+";
 
 #ifndef MS_WINDOWS
 static FILE*
@@ -136,6 +144,7 @@
         fputs(usage_3, f);
         fprintf(f, usage_4, DELIM);
         fprintf(f, usage_5, DELIM, PYTHONHOMEHELP);
+        fputs(usage_6, f);
     }
 #if defined(__VMS)
     if (exitcode == 0) {
@@ -373,6 +382,10 @@
             PySys_AddWarnOption(_PyOS_optarg);
             break;
 
+        case 'R':
+            Py_HashRandomizationFlag++;
+            break;
+
         /* This space reserved for other options */
 
         default:
diff -r e7706bdaaa0d Modules/posixmodule.c
--- a/Modules/posixmodule.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Modules/posixmodule.c	Wed Feb 01 20:09:56 2012 -0500
@@ -6942,82 +6942,6 @@
 }
 #endif
 
-#ifdef MS_WINDOWS
-
-PyDoc_STRVAR(win32_urandom__doc__,
-"urandom(n) -> str\n\n\
-Return n random bytes suitable for cryptographic use.");
-
-typedef BOOL (WINAPI *CRYPTACQUIRECONTEXTA)(HCRYPTPROV *phProv,\
-              LPCSTR pszContainer, LPCSTR pszProvider, DWORD dwProvType,\
-              DWORD dwFlags );
-typedef BOOL (WINAPI *CRYPTGENRANDOM)(HCRYPTPROV hProv, DWORD dwLen,\
-              BYTE *pbBuffer );
-
-static CRYPTGENRANDOM pCryptGenRandom = NULL;
-/* This handle is never explicitly released. Instead, the operating
-   system will release it when the process terminates. */
-static HCRYPTPROV hCryptProv = 0;
-
-static PyObject*
-win32_urandom(PyObject *self, PyObject *args)
-{
-    int howMany;
-    PyObject* result;
-
-    /* Read arguments */
-    if (! PyArg_ParseTuple(args, "i:urandom", &howMany))
-        return NULL;
-    if (howMany < 0)
-        return PyErr_Format(PyExc_ValueError,
-                            "negative argument not allowed");
-
-    if (hCryptProv == 0) {
-        HINSTANCE hAdvAPI32 = NULL;
-        CRYPTACQUIRECONTEXTA pCryptAcquireContext = NULL;
-
-        /* Obtain handle to the DLL containing CryptoAPI
-           This should not fail         */
-        hAdvAPI32 = GetModuleHandle("advapi32.dll");
-        if(hAdvAPI32 == NULL)
-            return win32_error("GetModuleHandle", NULL);
-
-        /* Obtain pointers to the CryptoAPI functions
-           This will fail on some early versions of Win95 */
-        pCryptAcquireContext = (CRYPTACQUIRECONTEXTA)GetProcAddress(
-                                        hAdvAPI32,
-                                        "CryptAcquireContextA");
-        if (pCryptAcquireContext == NULL)
-            return PyErr_Format(PyExc_NotImplementedError,
-                                "CryptAcquireContextA not found");
-
-        pCryptGenRandom = (CRYPTGENRANDOM)GetProcAddress(
-                                        hAdvAPI32, "CryptGenRandom");
-        if (pCryptGenRandom == NULL)
-            return PyErr_Format(PyExc_NotImplementedError,
-                                "CryptGenRandom not found");
-
-        /* Acquire context */
-        if (! pCryptAcquireContext(&hCryptProv, NULL, NULL,
-                                   PROV_RSA_FULL, CRYPT_VERIFYCONTEXT))
-            return win32_error("CryptAcquireContext", NULL);
-    }
-
-    /* Allocate bytes */
-    result = PyBytes_FromStringAndSize(NULL, howMany);
-    if (result != NULL) {
-        /* Get random data */
-        memset(PyBytes_AS_STRING(result), 0, howMany); /* zero seed */
-        if (! pCryptGenRandom(hCryptProv, howMany, (unsigned char*)
-                              PyBytes_AS_STRING(result))) {
-            Py_DECREF(result);
-            return win32_error("CryptGenRandom", NULL);
-        }
-    }
-    return result;
-}
-#endif
-
 PyDoc_STRVAR(device_encoding__doc__,
 "device_encoding(fd) -> str\n\n\
 Return a string describing the encoding of the device\n\
@@ -7055,41 +6979,35 @@
     return Py_None;
 }
 
-#ifdef __VMS
-/* Use openssl random routine */
-#include <openssl/rand.h>
-PyDoc_STRVAR(vms_urandom__doc__,
+PyDoc_STRVAR(posix_urandom__doc__,
 "urandom(n) -> str\n\n\
-Return n random bytes suitable for cryptographic use.");
-
-static PyObject*
-vms_urandom(PyObject *self, PyObject *args)
-{
-    int howMany;
-    PyObject* result;
-
-    /* Read arguments */
-    if (! PyArg_ParseTuple(args, "i:urandom", &howMany))
-        return NULL;
-    if (howMany < 0)
+Return n pseudo-random bytes.");
+
+static PyObject *
+posix_urandom(PyObject *self, PyObject *args)
+{
+    Py_ssize_t size;
+    PyObject *result;
+    int ret;
+ 
+     /* Read arguments */
+    if (!PyArg_ParseTuple(args, "n:urandom", &size))
+        return NULL;
+    if (size < 0)
         return PyErr_Format(PyExc_ValueError,
                             "negative argument not allowed");
-
-    /* Allocate bytes */
-    result = PyBytes_FromStringAndSize(NULL, howMany);
-    if (result != NULL) {
-        /* Get random data */
-        if (RAND_pseudo_bytes((unsigned char*)
-                              PyBytes_AS_STRING(result),
-                              howMany) < 0) {
-            Py_DECREF(result);
-            return PyErr_Format(PyExc_ValueError,
-                                "RAND_pseudo_bytes");
-        }
+    result = PyBytes_FromStringAndSize(NULL, size);
+    if (result == NULL)
+        return NULL;
+
+    ret = _PyOS_URandom(PyBytes_AS_STRING(result),
+                        PyBytes_GET_SIZE(result));
+    if (ret == -1) {
+        Py_DECREF(result);
+        return NULL;
     }
     return result;
 }
-#endif
 
 static PyMethodDef posix_methods[] = {
     {"access",          posix_access, METH_VARARGS, posix_access__doc__},
@@ -7374,12 +7292,7 @@
 #ifdef HAVE_GETLOADAVG
     {"getloadavg",      posix_getloadavg, METH_NOARGS, posix_getloadavg__doc__},
 #endif
- #ifdef MS_WINDOWS
-    {"urandom", win32_urandom, METH_VARARGS, win32_urandom__doc__},
- #endif
- #ifdef __VMS
-    {"urandom", vms_urandom, METH_VARARGS, vms_urandom__doc__},
- #endif
+    {"urandom",         posix_urandom,   METH_VARARGS, posix_urandom__doc__},
     {NULL,              NULL}            /* Sentinel */
 };
 
diff -r e7706bdaaa0d Objects/bytesobject.c
--- a/Objects/bytesobject.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Objects/bytesobject.c	Wed Feb 01 20:09:56 2012 -0500
@@ -899,11 +899,17 @@
     if (a->ob_shash != -1)
         return a->ob_shash;
     len = Py_SIZE(a);
+    if (len == 0) {
+        a->ob_shash = 0;
+        return 0;
+    }
     p = (unsigned char *) a->ob_sval;
-    x = *p << 7;
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= Py_SIZE(a);
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
     a->ob_shash = x;
diff -r e7706bdaaa0d Objects/object.c
--- a/Objects/object.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Objects/object.c	Wed Feb 01 20:09:56 2012 -0500
@@ -712,6 +712,8 @@
     return -1;
 }
 
+_Py_HashSecret_t _Py_HashSecret;
+
 long
 PyObject_Hash(PyObject *v)
 {
diff -r e7706bdaaa0d Objects/unicodeobject.c
--- a/Objects/unicodeobject.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Objects/unicodeobject.c	Wed Feb 01 20:09:56 2012 -0500
@@ -7344,11 +7344,17 @@
     if (self->hash != -1)
         return self->hash;
     len = Py_SIZE(self);
+    if (len == 0) {
+        self->hash = 0;
+        return 0;
+    }
     p = self->str;
-    x = *p << 7;
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= Py_SIZE(self);
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
     self->hash = x;
diff -r e7706bdaaa0d PCbuild/pythoncore.vcproj
--- a/PCbuild/pythoncore.vcproj	Fri Jan 27 09:48:47 2012 +0100
+++ b/PCbuild/pythoncore.vcproj	Wed Feb 01 20:09:56 2012 -0500
@@ -1778,6 +1778,10 @@
 				RelativePath="..\Python\pythonrun.c"
 				>
 			</File>
+ 			<File
+				RelativePath="..\Python\random.c"
+				>
+			</File>
 			<File
 				RelativePath="..\Python\structmember.c"
 				>
diff -r e7706bdaaa0d Python/pythonrun.c
--- a/Python/pythonrun.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Python/pythonrun.c	Wed Feb 01 20:09:56 2012 -0500
@@ -73,6 +73,7 @@
 extern void _PyUnicode_Fini(void);
 extern int _PyLong_Init(void);
 extern void PyLong_Fini(void);
+extern void _PyRandom_Init(void);
 
 #ifdef WITH_THREAD
 extern void _PyGILState_Init(PyInterpreterState *, PyThreadState *);
@@ -91,6 +92,7 @@
 int Py_IgnoreEnvironmentFlag; /* e.g. PYTHONPATH, PYTHONHOME */
 int Py_NoUserSiteDirectory = 0; /* for -s and site.py */
 int Py_UnbufferedStdioFlag = 0; /* Unbuffered binary std{in,out,err} */
+int Py_HashRandomizationFlag = 0; /* for -R and PYTHONHASHRANDOMIZATION */
 
 /* PyModule_GetWarningsModule is no longer necessary as of 2.6
 since _warnings is builtin.  This API should not be used. */
@@ -195,6 +197,10 @@
         Py_OptimizeFlag = add_flag(Py_OptimizeFlag, p);
     if ((p = Py_GETENV("PYTHONDONTWRITEBYTECODE")) && *p != '\0')
         Py_DontWriteBytecodeFlag = add_flag(Py_DontWriteBytecodeFlag, p);
+    if ((p = Py_GETENV("PYTHONHASHRANDOMIZATION")) && *p != '\0')
+        Py_HashRandomizationFlag = add_flag(Py_HashRandomizationFlag, p);
+    
+    _PyRandom_Init();
 
     interp = PyInterpreterState_New();
     if (interp == NULL)
diff -r e7706bdaaa0d Python/random.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Python/random.c	Wed Feb 01 20:09:56 2012 -0500
@@ -0,0 +1,283 @@
+#include "Python.h"
+#ifdef MS_WINDOWS
+#include <windows.h>
+#else
+#include <fcntl.h>
+#endif
+
+static int random_initialized = 0;
+
+#ifdef MS_WINDOWS
+typedef BOOL (WINAPI *CRYPTACQUIRECONTEXTA)(HCRYPTPROV *phProv,\
+              LPCSTR pszContainer, LPCSTR pszProvider, DWORD dwProvType,\
+              DWORD dwFlags );
+typedef BOOL (WINAPI *CRYPTGENRANDOM)(HCRYPTPROV hProv, DWORD dwLen,\
+              BYTE *pbBuffer );
+
+static CRYPTGENRANDOM pCryptGenRandom = NULL;
+/* This handle is never explicitly released. Instead, the operating
+   system will release it when the process terminates. */
+static HCRYPTPROV hCryptProv = 0;
+
+static int
+win32_urandom_init(int raise)
+{
+    HINSTANCE hAdvAPI32 = NULL;
+    CRYPTACQUIRECONTEXTA pCryptAcquireContext = NULL;
+
+    /* Obtain handle to the DLL containing CryptoAPI. This should not fail. */
+    hAdvAPI32 = GetModuleHandle("advapi32.dll");
+    if(hAdvAPI32 == NULL)
+        goto error;
+
+    /* Obtain pointers to the CryptoAPI functions. This will fail on some early
+       versions of Win95. */
+    pCryptAcquireContext = (CRYPTACQUIRECONTEXTA)GetProcAddress(
+                               hAdvAPI32, "CryptAcquireContextA");
+    if (pCryptAcquireContext == NULL)
+        goto error;
+
+    pCryptGenRandom = (CRYPTGENRANDOM)GetProcAddress(hAdvAPI32,
+                                                     "CryptGenRandom");
+    if (pCryptGenRandom == NULL)
+        goto error;
+
+    /* Acquire context */
+    if (! pCryptAcquireContext(&hCryptProv, NULL, NULL,
+                               PROV_RSA_FULL, CRYPT_VERIFYCONTEXT))
+        goto error;
+
+    return 0;
+
+error:
+    if (raise)
+        PyErr_SetFromWindowsErr(0);
+    else
+        Py_FatalError("Failed to initialize Windows random API (CryptoGen)");
+    return -1;
+}
+
+/* Fill buffer with size pseudo-random bytes generated by the Windows CryptoGen
+   API. Return 0 on success, or -1 on error. */
+static int
+win32_urandom(unsigned char *buffer, Py_ssize_t size, int raise)
+{
+    Py_ssize_t chunk;
+
+    if (hCryptProv == 0)
+    {
+        if (win32_urandom_init(raise) == -1)
+            return -1;
+    }
+
+    while (size > 0)
+    {
+        chunk = size > INT_MAX ? INT_MAX : size;
+        if (!pCryptGenRandom(hCryptProv, chunk, buffer))
+        {
+            /* CryptGenRandom() failed */
+            if (raise)
+                PyErr_SetFromWindowsErr(0);
+            else
+                Py_FatalError("Failed to initialized the randomized hash "
+                        "secret using CryptoGen)");
+            return -1;
+        }
+        buffer += chunk;
+        size -= chunk;
+    }
+    return 0;
+}
+
+#else
+
+/* Read size bytes from /dev/urandom into buffer.
+   Call Py_FatalError() on error. */
+static void
+dev_urandom_noraise(char *buffer, Py_ssize_t size)
+{
+    int fd;
+    Py_ssize_t n;
+
+    assert (0 < size);
+
+    fd = open("/dev/urandom", O_RDONLY);
+    if (fd < 0)
+        Py_FatalError("Failed to open /dev/urandom");
+
+    while (0 < size)
+    {
+        do {
+            n = read(fd, buffer, (size_t)size);
+        } while (n < 0 && errno == EINTR);
+        if (n <= 0)
+        {
+            /* stop on error or if read(size) returned 0 */
+            Py_FatalError("Failed to read bytes from /dev/urandom");
+            break;
+        }
+        buffer += n;
+        size -= (Py_ssize_t)n;
+    }
+    close(fd);
+}
+
+/* Read size bytes from /dev/urandom into buffer.
+   Return 0 on success, raise an exception and return -1 on error. */
+static int
+dev_urandom_python(char *buffer, Py_ssize_t size)
+{
+    int fd;
+    Py_ssize_t n;
+
+    if (size <= 0)
+        return 0;
+
+    Py_BEGIN_ALLOW_THREADS
+    fd = open("/dev/urandom", O_RDONLY);
+    Py_END_ALLOW_THREADS
+    if (fd < 0)
+    {
+        PyErr_SetFromErrnoWithFilename(PyExc_OSError, "/dev/urandom");
+        return -1;
+    }
+
+    Py_BEGIN_ALLOW_THREADS
+    do {
+        do {
+            n = read(fd, buffer, (size_t)size);
+        } while (n < 0 && errno == EINTR);
+        if (n <= 0)
+            break;
+        buffer += n;
+        size -= (Py_ssize_t)n;
+    } while (0 < size);
+    Py_END_ALLOW_THREADS
+
+    if (n <= 0)
+    {
+        /* stop on error or if read(size) returned 0 */
+        if (n < 0)
+            PyErr_SetFromErrno(PyExc_OSError);
+        else
+            PyErr_Format(PyExc_RuntimeError,
+                         "Failed to read %zi bytes from /dev/urandom",
+                         size);
+        close(fd);
+        return -1;
+    }
+    close(fd);
+    return 0;
+}
+#endif
+
+/* Fill buffer with pseudo-random bytes generated by a linear congruent
+   generator (LCG):
+
+       x(n+1) = (x(n) * 214013 + 2531011) % 2^32
+
+   Use bits 23..16 of x(n) to generate a byte. */
+static void
+lcg_urandom(unsigned int x0, unsigned char *buffer, size_t size)
+{
+    size_t index;
+    unsigned int x;
+
+    x = x0;
+    for (index=0; index < size; index++) {
+        x *= 214013;
+        x += 2531011;
+        /* modulo 2 ^ (8 * sizeof(int)) */
+        buffer[index] = (x >> 16) & 0xff;
+    }
+}
+
+/* Fill buffer with size pseudo-random bytes, not suitable for cryptographic
+   use, from the operating random number generator (RNG).
+
+   Return 0 on success, raise an exception and return -1 on error. */
+int
+_PyOS_URandom(void *buffer, Py_ssize_t size)
+{
+    if (size < 0) {
+        PyErr_Format(PyExc_ValueError,
+                     "negative argument not allowed");
+        return -1;
+    }
+    if (size == 0)
+        return 0;
+
+#ifdef MS_WINDOWS
+    return win32_urandom((unsigned char *)buffer, size, 1);
+#else
+    return dev_urandom_python((char*)buffer, size);
+#endif
+}
+
+void
+_PyRandom_Init(void)
+{
+    char *env;
+    void *secret = &_Py_HashSecret;
+    Py_ssize_t secret_size = sizeof(_Py_HashSecret);
+
+    if (random_initialized)
+        return;
+    random_initialized = 1;
+
+    /*
+      By default, hash randomization is disabled, and only
+      enabled if PYTHONHASHRANDOMIZATION is set to non-empty
+      or if "-R" is provided at the command line:
+    */
+    if (!Py_HashRandomizationFlag) {
+        /* Disable the randomized hash: */
+        memset(secret, 0, secret_size);
+        return;
+    }
+
+    /*
+      Hash randomization is enabled.  Generate a per-process secret,
+      using PYTHONHASHSEED if provided.
+    */
+
+    env = Py_GETENV("PYTHONHASHSEED");
+    if (env && *env != '\0') {
+        char *endptr = env;
+        unsigned long seed;
+        seed = strtoul(env, &endptr, 10);
+        if (*endptr != '\0'
+            || seed > 4294967295UL
+            || (errno == ERANGE && seed == ULONG_MAX))
+        {
+            Py_FatalError("PYTHONHASHSEED must be an integer "
+                          "in range [0; 4294967295]");
+        }
+        if (seed == 0) {
+            /* disable the randomized hash */
+            memset(secret, 0, secret_size);
+        }
+        else {
+            lcg_urandom(seed, (unsigned char*)secret, secret_size);
+        }
+    }
+    else {
+#ifdef MS_WINDOWS
+#if 1
+        (void)win32_urandom((unsigned char *)secret, secret_size, 0);
+#else
+        /* fast but weak RNG (fast initialization, weak seed) */
+        _PyTime_timeval t;
+        unsigned int seed;
+        _PyTime_gettimeofday(&t);
+        seed = (unsigned int)t.tv_sec;
+        seed ^= t.tv_usec;
+        seed ^= getpid();
+        lcg_urandom(seed, (unsigned char*)secret, secret_size);
+#endif
+#else /* #ifdef MS_WINDOWS */
+        dev_urandom_noraise((char*)secret, secret_size);
+#endif
+    }
+}
+
diff -r e7706bdaaa0d Python/sysmodule.c
--- a/Python/sysmodule.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Python/sysmodule.c	Wed Feb 01 20:09:56 2012 -0500
@@ -1126,6 +1126,7 @@
     /* {"unbuffered",                   "-u"}, */
     /* {"skip_first",                   "-x"}, */
     {"bytes_warning", "-b"},
+    {"hash_randomization", "-R"},
     {0}
 };
 
@@ -1134,9 +1135,9 @@
     flags__doc__,       /* doc */
     flags_fields,       /* fields */
 #ifdef RISCOS
+    13
+#else
     12
-#else
-    11
 #endif
 };
 
@@ -1169,6 +1170,7 @@
     /* SetFlag(saw_unbuffered_flag); */
     /* SetFlag(skipfirstline); */
     SetFlag(Py_BytesWarningFlag);
+    SetFlag(Py_HashRandomizationFlag);
 #undef SetFlag
 
     if (PyErr_Occurred()) {
-------------- next part --------------
diff -r e7706bdaaa0d Lib/json/__init__.py
--- a/Lib/json/__init__.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/json/__init__.py	Wed Feb 01 20:10:29 2012 -0500
@@ -31,7 +31,9 @@
 Compact encoding::
 
     >>> import json
-    >>> json.dumps([1,2,3,{'4': 5, '6': 7}], separators=(',', ':'))
+    >>> from collections import OrderedDict
+    >>> mydict = OrderedDict([('4', 5), ('6', 7)])
+    >>> json.dumps([1,2,3,mydict], separators=(',', ':'))
     '[1,2,3,{"4":5,"6":7}]'
 
 Pretty printing::
diff -r e7706bdaaa0d Lib/test/mapping_tests.py
--- a/Lib/test/mapping_tests.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/mapping_tests.py	Wed Feb 01 20:10:29 2012 -0500
@@ -14,7 +14,7 @@
     def _reference(self):
         """Return a dictionary of values which are invariant by storage
         in the object under test."""
-        return {1:2, "key1":"value1", "key2":(1,2,3)}
+        return {"1": "2", "key1":"value1", "key2":(1,2,3)}
     def _empty_mapping(self):
         """Return an empty mapping object"""
         return self.type2test()
diff -r e7706bdaaa0d Lib/test/test_descr.py
--- a/Lib/test/test_descr.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_descr.py	Wed Feb 01 20:10:29 2012 -0500
@@ -4300,8 +4300,18 @@
 
     def test_repr(self):
         # Testing dict_proxy.__repr__
+        def sorted_dict_repr(repr_):
+            # Given the repr of a dict, sort the keys
+            assert repr_.startswith('{')
+            assert repr_.endswith('}')
+            kvs = repr_[1:-1].split(', ')
+            return '{' + ', '.join(sorted(kvs)) + '}'
         dict_ = {k: v for k, v in self.C.__dict__.items()}
-        self.assertEqual(repr(self.C.__dict__), 'dict_proxy({!r})'.format(dict_))
+        repr_ = repr(self.C.__dict__)
+        self.assert_(repr_.startswith('dict_proxy('))
+        self.assert_(repr_.endswith(')'))
+        self.assertEqual(sorted_dict_repr(repr_[len('dict_proxy('):-len(')')]),
+                         sorted_dict_repr('{!r}'.format(dict_)))
 
 
 class PTypesLongInitTest(unittest.TestCase):
diff -r e7706bdaaa0d Lib/test/test_set.py
--- a/Lib/test/test_set.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_set.py	Wed Feb 01 20:10:29 2012 -0500
@@ -734,6 +734,17 @@
         if self.repr is not None:
             self.assertEqual(repr(self.set), self.repr)
 
+    def check_repr_against_values(self):
+        text = repr(self.set)
+        self.assertTrue(text.startswith('{'))
+        self.assertTrue(text.endswith('}'))
+
+        result = text[1:-1].split(', ')
+        result.sort()
+        sorted_repr_values = [repr(value) for value in self.values]
+        sorted_repr_values.sort()
+        self.assertEqual(result, sorted_repr_values)
+
     def test_print(self):
         try:
             fo = open(support.TESTFN, "w")
@@ -892,7 +903,9 @@
         self.set    = set(self.values)
         self.dup    = set(self.values)
         self.length = 3
-        self.repr   = "{'a', 'c', 'b'}"
+
+    def test_repr(self):
+        self.check_repr_against_values()
 
 #------------------------------------------------------------------------------
 
@@ -903,7 +916,9 @@
         self.set    = set(self.values)
         self.dup    = set(self.values)
         self.length = 3
-        self.repr   = "{b'a', b'c', b'b'}"
+
+    def test_repr(self):
+        self.check_repr_against_values()
 
 #------------------------------------------------------------------------------
 
@@ -916,11 +931,13 @@
         self.set    = set(self.values)
         self.dup    = set(self.values)
         self.length = 4
-        self.repr   = "{'a', b'a', 'b', b'b'}"
 
     def tearDown(self):
         warnings.filters = self.warning_filters
 
+    def test_repr(self):
+        self.check_repr_against_values()
+
 #==============================================================================
 
 def baditer():
diff -r e7706bdaaa0d Lib/test/test_urllib.py
--- a/Lib/test/test_urllib.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_urllib.py	Wed Feb 01 20:10:29 2012 -0500
@@ -12,6 +12,7 @@
 import sys
 import tempfile
 import warnings
+import collections
 
 def hexescape(char):
     """Escape char as RFC 2396 specifies"""
@@ -840,8 +841,9 @@
         self.assertEqual("a=1&a=2", urllib.parse.urlencode({"a": [1, 2]}, True))
         self.assertEqual("a=None&a=a",
                          urllib.parse.urlencode({"a": [None, "a"]}, True))
+        data = collections.OrderedDict([("a", 1), ("b", 1)])
         self.assertEqual("a=a&a=b",
-                         urllib.parse.urlencode({"a": {"a": 1, "b": 1}}, True))
+                         urllib.parse.urlencode({"a": data}, True))
 
     def test_urlencode_encoding(self):
         # ASCII encoding. Expect %3F with errors="replace'
diff -r e7706bdaaa0d Lib/tkinter/test/test_ttk/test_functions.py
--- a/Lib/tkinter/test/test_ttk/test_functions.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/tkinter/test/test_ttk/test_functions.py	Wed Feb 01 20:10:29 2012 -0500
@@ -143,7 +143,7 @@
             ('a', 'b', 'c')), ("test {a b} c", ()))
         # state spec and options
         self.assertEqual(ttk._format_elemcreate('image', False, 'test',
-            ('a', 'b'), a='x', b='y'), ("test a b", ("-a", "x", "-b", "y")))
+            ('a', 'b'), a='x'), ("test a b", ("-a", "x")))
         # format returned values as a tcl script
         # state spec with multiple states and an option with a multivalue
         self.assertEqual(ttk._format_elemcreate('image', True, 'test',

From report at bugs.python.org  Thu Feb  2 09:32:54 2012
From: report at bugs.python.org (Luis Marsano)
Date: Thu, 02 Feb 2012 08:32:54 +0000
Subject: [issue13756] Python3.2.2 make fail on cygwin
In-Reply-To: <1326199459.04.0.575648132034.issue13756@psf.upfronthosting.co.za>
Message-ID: <1328171574.85.0.914749516082.issue13756@psf.upfronthosting.co.za>


Luis Marsano <luis.marsano at gmail.com> added the comment:

Got it to build. Unpack the Python (3.2.2) source package and apply this patch to get a package that builds on Cygwin (1.7.9), eg:
xz -d patch.xz && tar -xJf Python-3.2.2.tar.xz && patch -p0 -i patch

Changes:
(1) The Makefile, makesetup, and distutils.UnixCCompiler and distutils.command.build_ext modules set values for locating cygwin's python library that didn't agree or make sense during buildtime, so I revised them to agree and use build options that work.
(2) configuration and setup.py couldn't locate cygwin's ncurses headers, so I revised them to do that. I don't think I made that change as portable friendly as possible, so someone please check that and find a better way.

Your input is welcome.

----------
Added file: http://bugs.python.org/file24395/patch.xz

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

From report at bugs.python.org  Thu Feb  2 14:06:41 2012
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 02 Feb 2012 13:06:41 +0000
Subject: [issue13922] argparse handling multiple "--" in args improperly
In-Reply-To: <1328132556.72.0.92385645061.issue13922@psf.upfronthosting.co.za>
Message-ID: <1328188001.62.0.73553348959.issue13922@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +bethard, eric.smith

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

From report at bugs.python.org  Thu Feb  2 14:05:00 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Feb 2012 13:05:00 +0000
Subject: [issue13882] Add format argument for time.time(), time.clock(),
	... to get a timestamp as a Decimal object
In-Reply-To: <1328054491.7.0.0248490784387.issue13882@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZYaJmKk633W=0BHrLHdssnKJrWFmS-zTAsC5BLz4MOgg@mail.gmail.com>


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

Patch version 7:
 - Drop datetime.datetime and datetime.timedelta types
 - Conversion to decimal now uses a context with 1 digit to compute
exponent=1/denominator to avoid issue on t.quantize(exponent)
 - Rename the "format" argument to "timestamp" in the time module
 - Rename _PyTime_AsFormat() to _PyTime_Convert()
 - Update the doc

----------
Added file: http://bugs.python.org/file24396/time_decimal-7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/os.rst b/Doc/library/os.rst
--- a/Doc/library/os.rst
+++ b/Doc/library/os.rst
@@ -808,13 +808,16 @@ as internal buffering of data.
    Availability: Unix.
 
 
-.. function:: fstat(fd)
+.. function:: fstat(fd, timestamp=None)
 
    Return status for file descriptor *fd*, like :func:`~os.stat`.
 
    Availability: Unix, Windows.
 
-.. function:: fstatat(dirfd, path, flags=0)
+   .. versionchanged:: 3.3
+      Added the *timestamp* argument.
+
+.. function:: fstatat(dirfd, path, flags=0, timestamp="float")
 
    Like :func:`stat` but if *path* is relative, it is taken as relative to *dirfd*.
    *flags* is optional and may be 0 or :data:`AT_SYMLINK_NOFOLLOW`.
@@ -1696,7 +1699,7 @@ Files and Directories
    .. versionadded:: 3.3
 
 
-.. function:: lstat(path)
+.. function:: lstat(path, timestamp=None)
 
    Perform the equivalent of an :c:func:`lstat` system call on the given path.
    Similar to :func:`~os.stat`, but does not follow symbolic links.  On
@@ -1706,6 +1709,9 @@ Files and Directories
    .. versionchanged:: 3.2
       Added support for Windows 6.0 (Vista) symbolic links.
 
+   .. versionchanged:: 3.3
+      The *timestamp* argument was added.
+
 
 .. function:: lutimes(path[, times])
 
@@ -1955,7 +1961,7 @@ Files and Directories
    .. versionadded:: 3.3
 
 
-.. function:: stat(path)
+.. function:: stat(path, timestamp=None)
 
    Perform the equivalent of a :c:func:`stat` system call on the given path.
    (This function follows symlinks; to stat a symlink use :func:`lstat`.)
@@ -1975,6 +1981,11 @@ Files and Directories
    * :attr:`st_ctime` - platform dependent; time of most recent metadata change on
      Unix, or the time of creation on Windows)
 
+   :attr:`st_atime`, :attr:`st_mtime` and :attr:`st_ctime` are :class:`float`
+   by default, or :class:`int` if :func:`os.stat_float_times` is ``False``. Set
+   the *timestamp* argument to get another :ref:`timestamp type
+   <timestamp-types>`.
+
    On some Unix systems (such as Linux), the following attributes may also be
    available:
 
@@ -2030,6 +2041,9 @@ Files and Directories
 
    Availability: Unix, Windows.
 
+   .. versionchanged:: 3.3
+      Added the *timestamp* argument.
+
 
 .. function:: stat_float_times([newvalue])
 
@@ -2055,6 +2069,9 @@ Files and Directories
    are processed, this application should turn the feature off until the library
    has been corrected.
 
+   .. deprecated:: 3.3
+      Use *timestamp* argument of stat functions instead.
+
 
 .. function:: statvfs(path)
 
diff --git a/Doc/library/time.rst b/Doc/library/time.rst
--- a/Doc/library/time.rst
+++ b/Doc/library/time.rst
@@ -95,6 +95,14 @@ An explanation of some terminology and c
   | local time              |                         |                         |
   +-------------------------+-------------------------+-------------------------+
 
+.. _timestamp-types:
+
+* Python supports the following timestamp types:
+
+  * :class:`int`
+  * :class:`float`
+  * :class:`decimal.Decimal`
+
 
 The module defines the following functions and data items:
 
@@ -118,7 +126,7 @@ The module defines the following functio
       Unlike the C function of the same name, there is no trailing newline.
 
 
-.. function:: clock()
+.. function:: clock(timestamp=float)
 
    .. index::
       single: CPU time
@@ -135,16 +143,27 @@ The module defines the following functio
    :c:func:`QueryPerformanceCounter`. The resolution is typically better than one
    microsecond.
 
+   Return as a floating point number by default, set the *timestamp* argument
+   to get another :ref:`timestamp type <timestamp-types>`.
 
-.. function:: clock_getres(clk_id)
+   .. versionchanged:: 3.3
+      Added the *timestamp* argument.
+
+
+.. function:: clock_getres(clk_id, timestamp=float)
 
    Return the resolution (precision) of the specified clock *clk_id*.
+   Return a floating point number by default, set the *timestamp* argument to
+   get another :ref:`timestamp type <timestamp-types>`.
+
 
    .. versionadded:: 3.3
 
-.. function:: clock_gettime(clk_id)
+.. function:: clock_gettime(clk_id, timestamp=float)
 
    Return the time of the specified clock *clk_id*.
+   Return a floating point number by default, set the *timestamp* argument to
+   get another :ref:`timestamp type <timestamp-types>`.
 
    .. versionadded:: 3.3
 
@@ -213,12 +232,15 @@ The module defines the following functio
    flag is set to ``1`` when DST applies to the given time.
 
 
-.. function:: mktime(t)
+.. function:: mktime(t, timestamp=float)
 
    This is the inverse function of :func:`localtime`.  Its argument is the
    :class:`struct_time` or full 9-tuple (since the dst flag is needed; use ``-1``
    as the dst flag if it is unknown) which expresses the time in *local* time, not
-   UTC.  It returns a floating point number, for compatibility with :func:`time`.
+   It returns a floating point number by default, for compatibility with
+   :func:`time`, set the *timestamp* argument to get another :ref:`timestamp
+   type <timestamp-types>`.
+
    If the input value cannot be represented as a valid time, either
    :exc:`OverflowError` or :exc:`ValueError` will be raised (which depends on
    whether the invalid value is caught by Python or the underlying C libraries).
@@ -431,15 +453,20 @@ The module defines the following functio
    :exc:`TypeError` is raised.
 
 
-.. function:: time()
+.. function:: time(timestamp=float)
 
-   Return the time as a floating point number expressed in seconds since the epoch,
-   in UTC.  Note that even though the time is always returned as a floating point
+   Return the time expressed in seconds since the epoch in UTC. Return a
+   floating point number by default, set the *timestamp* argument to get
+   another :ref:`timestamp type <timestamp-types>`.
+   Note that even though the time is always returned as a floating point
    number, not all systems provide time with a better precision than 1 second.
    While this function normally returns non-decreasing values, it can return a
    lower value than a previous call if the system clock has been set back between
    the two calls.
 
+   .. versionchanged:: 3.3
+      Added the *timestamp* argument.
+
 
 .. data:: timezone
 
@@ -537,13 +564,16 @@ The module defines the following functio
       ('EET', 'EEST')
 
 
-.. function:: wallclock()
+.. function:: wallclock(timestamp=float)
 
    .. index::
       single: Wallclock
       single: benchmarking
 
    Return the current time in fractions of a second to the system's best ability.
+   Return a floating point number by default, set the *timestamp* argument to
+   get another :ref:`timestamp type <timestamp-types>`.
+
    Use this when the most accurate representation of wall-clock is required, i.e.
    when "processor time" is inappropriate.  The reference point of the returned
    value is undefined so only the difference of consecutive calls is valid.
diff --git a/Doc/whatsnew/3.3.rst b/Doc/whatsnew/3.3.rst
--- a/Doc/whatsnew/3.3.rst
+++ b/Doc/whatsnew/3.3.rst
@@ -270,6 +270,35 @@ new, more precise information::
    '<function C.D.meth at 0x7f46b9fe31e0>'
 
 
+Timestamp types
+===============
+
+The following functions have a new optional *timestamp* argument to get a
+timestamp as a :class:`decimal.Decimal` instead of :class:`int` or
+:class:`float`:
+
+ * :mod:`time` module: :func:`~time.clock`, :func:`~time.clock_gettime`,
+   :func:`~time.clock_getres`, :func:`~time.time` and :func:`~time.wallclock`
+ * :mod:`os` module: :func:`~os.fstat`, :func:`~os.fstatat`, :func:`~os.lstat`
+   and :func:`~os.stat` (``st_atime``, ``st_ctime`` and ``st_mtime`` fields of
+   the stat structure)
+
+:class:`decimal.Decimal` supports a resolution of a nanosecond (10^-9)
+resolution, whereas :class:`float` has only a resolution of a microsecond
+(10^-6) in common cases. See the list of available :ref:`timestamp types
+<timestamp-types>`.
+
+Example::
+
+    >>> import decimal, time
+    >>> time.time()
+    1328006975.681211
+    >>> time.time(timestamp=int)
+    1328006979
+    >>> time.time(timestamp=decimal.Decimal)
+    Decimal('1328006983.761119')
+
+
 Other Language Changes
 ======================
 
diff --git a/Include/pytime.h b/Include/pytime.h
--- a/Include/pytime.h
+++ b/Include/pytime.h
@@ -12,6 +12,8 @@ functions and constants
 extern "C" {
 #endif
 
+#include "object.h"
+
 #ifdef HAVE_GETTIMEOFDAY
 typedef struct timeval _PyTime_timeval;
 #else
@@ -37,6 +39,25 @@ do { \
     ((tv_end.tv_sec - tv_start.tv_sec) + \
      (tv_end.tv_usec - tv_start.tv_usec) * 0.000001)
 
+typedef struct
+{
+    /* timestamp = seconds + numerator / denominator */
+    time_t seconds;
+    size_t numerator;
+    /* denominator cannot be zero */
+    size_t denominator;
+    /* the timestamp resolution is 1/divisor */
+} _PyTime_t;
+
+/* Similar to POSIX gettimeofday.  If system gettimeofday
+   fails or is not available, fall back to lower resolution clocks.  */
+PyAPI_FUNC(void) _PyTime_get(_PyTime_t *tp);
+
+/* Convert a timestamp structure to the specified timestamp type.
+
+   Raise a ValueError if the timestamp type is unknown. */
+PyAPI_FUNC(PyObject*) _PyTime_Convert(_PyTime_t *ts, PyObject *timestamp);
+
 /* Dummy to force linking. */
 PyAPI_FUNC(void) _PyTime_Init(void);
 
diff --git a/Lib/test/test_os.py b/Lib/test/test_os.py
--- a/Lib/test/test_os.py
+++ b/Lib/test/test_os.py
@@ -2,24 +2,25 @@
 # does add tests for a few functions which have been determined to be more
 # portable than they had been thought to be.
 
+import asynchat
+import asyncore
+import contextlib
+import decimal
+import errno
+import mmap
 import os
-import errno
-import unittest
-import warnings
-import sys
-import signal
-import subprocess
-import time
-import shutil
-from test import support
-import contextlib
-import mmap
 import platform
 import re
+import shutil
+import signal
+import socket
+import subprocess
+import sys
+from test import support
+import time
+import unittest
 import uuid
-import asyncore
-import asynchat
-import socket
+import warnings
 try:
     import threading
 except ImportError:
@@ -217,6 +218,27 @@ class StatAttributeTests(unittest.TestCa
             warnings.simplefilter("ignore", DeprecationWarning)
             self.check_stat_attributes(fname)
 
+    def test_stat_timestamp(self):
+        old_value = os.stat_float_times()
+        try:
+            # test invalid timestamp
+            self.assertRaises(ValueError, os.stat, self.fname, timestamp="abc")
+            self.assertRaises(ValueError, os.stat, self.fname, timestamp=decimal.Context)
+
+            for float_times in (False, True):
+                os.stat_float_times(float_times)
+                t = os.stat(self.fname).st_mtime
+                if float_times:
+                    self.assertIsInstance(t, float)
+                else:
+                    self.assertIsInstance(t, int)
+
+                for type in (int, float, decimal.Decimal):
+                    t = os.stat(self.fname, timestamp=type).st_mtime
+                    self.assertIsInstance(t, type)
+        finally:
+            os.stat_float_times(old_value)
+
     def test_statvfs_attributes(self):
         if not hasattr(os, "statvfs"):
             return
diff --git a/Lib/test/test_time.py b/Lib/test/test_time.py
--- a/Lib/test/test_time.py
+++ b/Lib/test/test_time.py
@@ -1,10 +1,10 @@
+import locale
+import platform
+import sys
+import sysconfig
 from test import support
 import time
 import unittest
-import locale
-import sysconfig
-import sys
-import platform
 
 # Max year is only limited by the size of C int.
 SIZEOF_INT = sysconfig.get_config_var('SIZEOF_INT') or 4
@@ -331,6 +331,29 @@ class TimeTestCase(unittest.TestCase):
             pass
         self.assertEqual(time.strftime('%Z', tt), tzname)
 
+    def test_timestamp(self):
+        import decimal
+        calls = [
+            (time.time,),
+            (time.mktime, time.localtime()),
+        ]
+        if hasattr(time, 'wallclock'):
+            calls.append((time.wallclock,))
+        if hasattr(time, 'CLOCK_REALTIME'):
+            if hasattr(time, 'clock_gettime'):
+                calls.append((time.clock_gettime, time.CLOCK_REALTIME))
+            if hasattr(time, 'clock_getres'):
+                calls.append((time.clock_getres, time.CLOCK_REALTIME))
+        for call in calls:
+            func, *args = call
+
+            # test invalid timestamp
+            for invalid in ("int", decimal.Context):
+                self.assertRaises(ValueError, func, *args, timestamp=invalid)
+
+            for type in (int, float, decimal.Decimal):
+                self.assertIsInstance(func(*args, timestamp=type), type)
+
     def test_wallclock(self):
         t1 = time.wallclock()
         t2 = time.wallclock()
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -1708,9 +1708,12 @@ stat_float_times(PyObject* self, PyObjec
 }
 
 static void
-fill_time(PyObject *v, int index, time_t sec, unsigned long nsec)
+fill_time(PyObject *v, int index, time_t sec, unsigned long nsec,
+          PyObject *timestamp)
 {
     PyObject *fval,*ival;
+    _PyTime_t ts;
+
 #if SIZEOF_TIME_T > SIZEOF_LONG
     ival = PyLong_FromLongLong((PY_LONG_LONG)sec);
 #else
@@ -1718,9 +1721,15 @@ fill_time(PyObject *v, int index, time_t
 #endif
     if (!ival)
         return;
-    if (_stat_float_times) {
-        fval = PyFloat_FromDouble(sec + 1e-9*nsec);
-    } else {
+    if (timestamp == NULL && _stat_float_times)
+        timestamp = (PyObject*)&PyFloat_Type;
+    if (timestamp != NULL) {
+        ts.seconds = sec;
+        ts.numerator = nsec;
+        ts.denominator = 1000000000;
+        fval = _PyTime_Convert(&ts, timestamp);
+    }
+    else {
         fval = ival;
         Py_INCREF(fval);
     }
@@ -1731,7 +1740,7 @@ fill_time(PyObject *v, int index, time_t
 /* pack a system stat C structure into the Python stat tuple
    (used by posix_stat() and posix_fstat()) */
 static PyObject*
-_pystat_fromstructstat(STRUCT_STAT *st)
+_pystat_fromstructstat(STRUCT_STAT *st, PyObject *timestamp)
 {
     unsigned long ansec, mnsec, cnsec;
     PyObject *v = PyStructSequence_New(&StatResultType);
@@ -1776,9 +1785,9 @@ _pystat_fromstructstat(STRUCT_STAT *st)
 #else
     ansec = mnsec = cnsec = 0;
 #endif
-    fill_time(v, 7, st->st_atime, ansec);
-    fill_time(v, 8, st->st_mtime, mnsec);
-    fill_time(v, 9, st->st_ctime, cnsec);
+    fill_time(v, 7, st->st_atime, ansec, timestamp);
+    fill_time(v, 8, st->st_mtime, mnsec, timestamp);
+    fill_time(v, 9, st->st_ctime, cnsec, timestamp);
 
 #ifdef HAVE_STRUCT_STAT_ST_BLKSIZE
     PyStructSequence_SET_ITEM(v, ST_BLKSIZE_IDX,
@@ -1829,7 +1838,7 @@ _pystat_fromstructstat(STRUCT_STAT *st)
 }
 
 static PyObject *
-posix_do_stat(PyObject *self, PyObject *args,
+posix_do_stat(PyObject *self, PyObject *args, PyObject *kw,
               char *format,
 #ifdef __VMS
               int (*statfunc)(const char *, STRUCT_STAT *, ...),
@@ -1839,15 +1848,18 @@ posix_do_stat(PyObject *self, PyObject *
               char *wformat,
               int (*wstatfunc)(const wchar_t *, STRUCT_STAT *))
 {
+    static char *kwlist[] = {"path", "timestamp", NULL};
     STRUCT_STAT st;
     PyObject *opath;
     char *path;
     int res;
     PyObject *result;
+    PyObject *timestamp = NULL;
 
 #ifdef MS_WINDOWS
     PyObject *po;
-    if (PyArg_ParseTuple(args, wformat, &po)) {
+    if (PyArg_ParseTupleAndKeywords(args, kw, wformat, kwlist,
+                                    &po, &timestamp)) {
         wchar_t *wpath = PyUnicode_AsUnicode(po);
         if (wpath == NULL)
             return NULL;
@@ -1858,15 +1870,17 @@ posix_do_stat(PyObject *self, PyObject *
 
         if (res != 0)
             return win32_error_object("stat", po);
-        return _pystat_fromstructstat(&st);
+        return _pystat_fromstructstat(&st, timestamp);
     }
     /* Drop the argument parsing error as narrow strings
        are also valid. */
     PyErr_Clear();
-#endif
-
-    if (!PyArg_ParseTuple(args, format,
-                          PyUnicode_FSConverter, &opath))
+    timestamp = NULL;
+#endif
+
+    if (!PyArg_ParseTupleAndKeywords(args, kw, format, kwlist,
+                                     PyUnicode_FSConverter, &opath,
+                                     &timestamp))
         return NULL;
 #ifdef MS_WINDOWS
     if (win32_warn_bytes_api()) {
@@ -1887,7 +1901,7 @@ posix_do_stat(PyObject *self, PyObject *
 #endif
     }
     else
-        result = _pystat_fromstructstat(&st);
+        result = _pystat_fromstructstat(&st, timestamp);
 
     Py_DECREF(opath);
     return result;
@@ -3362,12 +3376,12 @@ PyDoc_STRVAR(posix_stat__doc__,
 Perform a stat system call on the given path.");
 
 static PyObject *
-posix_stat(PyObject *self, PyObject *args)
+posix_stat(PyObject *self, PyObject *args, PyObject *kw)
 {
 #ifdef MS_WINDOWS
-    return posix_do_stat(self, args, "O&:stat", STAT, "U:stat", win32_stat_w);
+    return posix_do_stat(self, args, kw, "O&|O:stat", STAT, "U:stat", win32_stat_w);
 #else
-    return posix_do_stat(self, args, "O&:stat", STAT, NULL, NULL);
+    return posix_do_stat(self, args, kw, "O&|O:stat", STAT, NULL, NULL);
 #endif
 }
 
@@ -6367,16 +6381,16 @@ PyDoc_STRVAR(posix_lstat__doc__,
 Like stat(path), but do not follow symbolic links.");
 
 static PyObject *
-posix_lstat(PyObject *self, PyObject *args)
+posix_lstat(PyObject *self, PyObject *args, PyObject *kw)
 {
 #ifdef HAVE_LSTAT
-    return posix_do_stat(self, args, "O&:lstat", lstat, NULL, NULL);
+    return posix_do_stat(self, args, kw, "O&|O:lstat", lstat, NULL, NULL);
 #else /* !HAVE_LSTAT */
 #ifdef MS_WINDOWS
-    return posix_do_stat(self, args, "O&:lstat", win32_lstat, "U:lstat",
+    return posix_do_stat(self, args, kw, "O&|O:lstat", win32_lstat, "U|O:lstat",
                          win32_lstat_w);
 #else
-    return posix_do_stat(self, args, "O&:lstat", STAT, NULL, NULL);
+    return posix_do_stat(self, args, "kw, O&|O:lstat", STAT, NULL, NULL);
 #endif
 #endif /* !HAVE_LSTAT */
 }
@@ -7339,12 +7353,15 @@ PyDoc_STRVAR(posix_fstat__doc__,
 Like stat(), but for an open file descriptor.");
 
 static PyObject *
-posix_fstat(PyObject *self, PyObject *args)
-{
+posix_fstat(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+    static char *kwlist[] = {"fd", "timestamp", NULL};
     int fd;
     STRUCT_STAT st;
     int res;
-    if (!PyArg_ParseTuple(args, "i:fstat", &fd))
+    PyObject *timestamp = NULL;
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "i|O:fstat", kwlist,
+                                     &fd, &timestamp))
         return NULL;
 #ifdef __VMS
     /* on OpenVMS we must ensure that all bytes are written to the file */
@@ -7363,7 +7380,7 @@ posix_fstat(PyObject *self, PyObject *ar
 #endif
     }
 
-    return _pystat_fromstructstat(&st);
+    return _pystat_fromstructstat(&st, timestamp);
 }
 
 PyDoc_STRVAR(posix_isatty__doc__,
@@ -9654,15 +9671,18 @@ If path is relative and dirfd is the spe
 is interpreted relative to the current working directory.");
 
 static PyObject *
-posix_fstatat(PyObject *self, PyObject *args)
-{
+posix_fstatat(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+    static char *kwlist[] = {"dirfd", "path", "flags", "timestamp", NULL};
     PyObject *opath;
     char *path;
     STRUCT_STAT st;
     int dirfd, res, flags = 0;
-
-    if (!PyArg_ParseTuple(args, "iO&|i:fstatat",
-            &dirfd, PyUnicode_FSConverter, &opath, &flags))
+    PyObject *timestamp = NULL;
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "iO&|iO:fstatat", kwlist,
+                                     &dirfd, PyUnicode_FSConverter, &opath,
+                                     &flags, &timestamp))
         return NULL;
     path = PyBytes_AsString(opath);
 
@@ -9673,7 +9693,7 @@ posix_fstatat(PyObject *self, PyObject *
     if (res != 0)
         return posix_error();
 
-    return _pystat_fromstructstat(&st);
+    return _pystat_fromstructstat(&st, timestamp);
 }
 #endif
 
@@ -10537,7 +10557,7 @@ static PyMethodDef posix_methods[] = {
 #ifdef HAVE_FDOPENDIR
     {"fdlistdir",       posix_fdlistdir, METH_VARARGS, posix_fdlistdir__doc__},
 #endif
-    {"lstat",           posix_lstat, METH_VARARGS, posix_lstat__doc__},
+    {"lstat",           (PyCFunction)posix_lstat, METH_VARARGS | METH_KEYWORDS, posix_lstat__doc__},
     {"mkdir",           posix_mkdir, METH_VARARGS, posix_mkdir__doc__},
 #ifdef HAVE_NICE
     {"nice",            posix_nice, METH_VARARGS, posix_nice__doc__},
@@ -10556,7 +10576,7 @@ static PyMethodDef posix_methods[] = {
 #endif /* !defined(HAVE_READLINK) && defined(MS_WINDOWS) */
     {"rename",          posix_rename, METH_VARARGS, posix_rename__doc__},
     {"rmdir",           posix_rmdir, METH_VARARGS, posix_rmdir__doc__},
-    {"stat",            posix_stat, METH_VARARGS, posix_stat__doc__},
+    {"stat",            (PyCFunction)posix_stat, METH_VARARGS | METH_KEYWORDS, posix_stat__doc__},
     {"stat_float_times", stat_float_times, METH_VARARGS, stat_float_times__doc__},
 #if defined(HAVE_SYMLINK) && !defined(MS_WINDOWS)
     {"symlink",         posix_symlink, METH_VARARGS, posix_symlink__doc__},
@@ -10771,7 +10791,8 @@ static PyMethodDef posix_methods[] = {
     {"sendfile",        (PyCFunction)posix_sendfile, METH_VARARGS | METH_KEYWORDS,
                             posix_sendfile__doc__},
 #endif
-    {"fstat",           posix_fstat, METH_VARARGS, posix_fstat__doc__},
+    {"fstat",           (PyCFunction)posix_fstat, METH_VARARGS | METH_KEYWORDS,
+                            posix_fstat__doc__},
     {"isatty",          posix_isatty, METH_VARARGS, posix_isatty__doc__},
 #ifdef HAVE_PIPE
     {"pipe",            posix_pipe, METH_NOARGS, posix_pipe__doc__},
@@ -10906,7 +10927,8 @@ static PyMethodDef posix_methods[] = {
     {"fchownat",        posix_fchownat, METH_VARARGS, posix_fchownat__doc__},
 #endif /* HAVE_FCHOWNAT */
 #ifdef HAVE_FSTATAT
-    {"fstatat",         posix_fstatat, METH_VARARGS, posix_fstatat__doc__},
+    {"fstatat",         (PyCFunction)posix_fstatat, METH_VARARGS | METH_KEYWORDS,
+                            posix_fstatat__doc__},
 #endif
 #ifdef HAVE_FUTIMESAT
     {"futimesat",       posix_futimesat, METH_VARARGS, posix_futimesat__doc__},
diff --git a/Modules/timemodule.c b/Modules/timemodule.c
--- a/Modules/timemodule.c
+++ b/Modules/timemodule.c
@@ -40,24 +40,30 @@
 #include <sys/time.h>
 #endif
 
+#if (defined(MS_WINDOWS) && !defined(__BORLANDC__)) || defined(HAVE_CLOCK)
+#  define HAVE_PYCLOCK
+#endif
+
 /* Forward declarations */
 static int floatsleep(double);
-static double floattime(void);
 
 static PyObject *
-time_time(PyObject *self, PyObject *unused)
+time_time(PyObject *self, PyObject *args, PyObject *kwargs)
 {
-    double secs;
-    secs = floattime();
-    if (secs == 0.0) {
-        PyErr_SetFromErrno(PyExc_IOError);
+    static char *kwlist[] = {"timestamp", NULL};
+    PyObject *timestamp = NULL;
+    _PyTime_t ts;
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "|O:time", kwlist,
+                                     &timestamp))
         return NULL;
-    }
-    return PyFloat_FromDouble(secs);
+
+    _PyTime_get(&ts);
+    return _PyTime_Convert(&ts, timestamp);
 }
 
 PyDoc_STRVAR(time_doc,
-"time() -> floating point number\n\
+"time(timestamp=float) -> floating point number\n\
 \n\
 Return the current time in seconds since the Epoch.\n\
 Fractions of a second may be present if the system clock provides them.");
@@ -72,60 +78,85 @@ Fractions of a second may be present if 
 #endif
 #endif
 
-static PyObject *
-pyclock(void)
+static int
+pyclock(_PyTime_t *ts)
 {
-    clock_t value;
-    value = clock();
-    if (value == (clock_t)-1) {
+    clock_t processor_time;
+    processor_time = clock();
+    if (processor_time == (clock_t)-1) {
         PyErr_SetString(PyExc_RuntimeError,
                 "the processor time used is not available "
                 "or its value cannot be represented");
-        return NULL;
+        return -1;
     }
-    return PyFloat_FromDouble((double)value / CLOCKS_PER_SEC);
+    ts->seconds = 0;
+    assert(sizeof(clock_t) <= sizeof(size_t));
+    ts->numerator = Py_SAFE_DOWNCAST(processor_time, clock_t, size_t);
+    ts->denominator = CLOCKS_PER_SEC;
+    return 0;
 }
 #endif /* HAVE_CLOCK */
 
 #if defined(MS_WINDOWS) && !defined(__BORLANDC__)
 /* Win32 has better clock replacement; we have our own version, due to Mark
    Hammond and Tim Peters */
-static PyObject *
-time_clock(PyObject *self, PyObject *unused)
+static int
+win32_pyclock(_PyTime_t *ts)
 {
     static LARGE_INTEGER ctrStart;
-    static double divisor = 0.0;
+    static LONGLONG cpu_frequency = 0;
     LARGE_INTEGER now;
-    double diff;
+    LONGLONG dt;
 
-    if (divisor == 0.0) {
+    if (cpu_frequency == 0) {
         LARGE_INTEGER freq;
         QueryPerformanceCounter(&ctrStart);
-        if (!QueryPerformanceFrequency(&freq) || freq.QuadPart == 0) {
+        if (!QueryPerformanceFrequency(&freq) || freq.QuadPart == 0)
+        {
             /* Unlikely to happen - this works on all intel
                machines at least!  Revert to clock() */
-            return pyclock();
+            return pyclock(ts);
         }
-        divisor = (double)freq.QuadPart;
+        cpu_frequency = freq.QuadPart;
     }
     QueryPerformanceCounter(&now);
-    diff = (double)(now.QuadPart - ctrStart.QuadPart);
-    return PyFloat_FromDouble(diff / divisor);
+    dt = now.QuadPart - ctrStart.QuadPart;
+
+    ts->seconds = 0;
+    assert(sizeof(LONGLONG) <= sizeof(size_t));
+    ts->numerator = Py_SAFE_DOWNCAST(dt, LONGLONG, size_t);
+    ts->denominator = Py_SAFE_DOWNCAST(cpu_frequency, LONGLONG, size_t);
+    return 0;
 }
+#endif
 
-#elif defined(HAVE_CLOCK)
+#ifdef HAVE_PYCLOCK
+static PyObject *
+time_clock(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+    static char *kwlist[] = {"timestamp", NULL};
+    _PyTime_t ts;
+    PyObject *timestamp = NULL;
 
-static PyObject *
-time_clock(PyObject *self, PyObject *unused)
-{
-    return pyclock();
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "|O:clock", kwlist,
+                                     &timestamp))
+        return NULL;
+
+#if defined(MS_WINDOWS) && !defined(__BORLANDC__)
+    if (win32_pyclock(&ts))
+        return NULL;
+#else
+    if (pyclock(&ts))
+        return NULL;
+#endif
+    return _PyTime_Convert(&ts, timestamp);
 }
-#endif /* HAVE_CLOCK */
+#endif
 
 
 #ifdef HAVE_CLOCK
 PyDoc_STRVAR(clock_doc,
-"clock() -> floating point number\n\
+"clock(timestamp=float) -> floating point number\n\
 \n\
 Return the CPU time or real time since the start of the process or since\n\
 the first call to clock().  This has as much precision as the system\n\
@@ -134,13 +165,17 @@ records.");
 
 #ifdef HAVE_CLOCK_GETTIME
 static PyObject *
-time_clock_gettime(PyObject *self, PyObject *args)
+time_clock_gettime(PyObject *self, PyObject *args, PyObject *kwargs)
 {
+    static char *kwlist[] = {"clk_id", "timestamp", NULL};
+    PyObject *timestamp = NULL;
     int ret;
     clockid_t clk_id;
     struct timespec tp;
+    _PyTime_t ts;
 
-    if (!PyArg_ParseTuple(args, "i:clock_gettime", &clk_id))
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "i|O:clock_gettime", kwlist,
+                                     &clk_id, &timestamp))
         return NULL;
 
     ret = clock_gettime((clockid_t)clk_id, &tp);
@@ -148,25 +183,31 @@ time_clock_gettime(PyObject *self, PyObj
         PyErr_SetFromErrno(PyExc_IOError);
         return NULL;
     }
-
-    return PyFloat_FromDouble(tp.tv_sec + tp.tv_nsec * 1e-9);
+    ts.seconds = tp.tv_sec;
+    ts.numerator = tp.tv_nsec;
+    ts.denominator = 1000000000;
+    return _PyTime_Convert(&ts, timestamp);
 }
 
 PyDoc_STRVAR(clock_gettime_doc,
-"clock_gettime(clk_id) -> floating point number\n\
+"clock_gettime(clk_id, timestamp=float) -> floating point number\n\
 \n\
 Return the time of the specified clock clk_id.");
 #endif
 
 #ifdef HAVE_CLOCK_GETRES
 static PyObject *
-time_clock_getres(PyObject *self, PyObject *args)
+time_clock_getres(PyObject *self, PyObject *args, PyObject *kwargs)
 {
+    static char *kwlist[] = {"clk_id", "timestamp", NULL};
+    PyObject *timestamp = NULL;
     int ret;
     clockid_t clk_id;
     struct timespec tp;
+    _PyTime_t ts;
 
-    if (!PyArg_ParseTuple(args, "i:clock_getres", &clk_id))
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "i|O:clock_getres", kwlist,
+                                     &clk_id, &timestamp))
         return NULL;
 
     ret = clock_getres((clockid_t)clk_id, &tp);
@@ -174,12 +215,14 @@ time_clock_getres(PyObject *self, PyObje
         PyErr_SetFromErrno(PyExc_IOError);
         return NULL;
     }
-
-    return PyFloat_FromDouble(tp.tv_sec + tp.tv_nsec * 1e-9);
+    ts.seconds = tp.tv_sec;
+    ts.numerator = tp.tv_nsec;
+    ts.denominator = 1000000000;
+    return _PyTime_Convert(&ts, timestamp);
 }
 
 PyDoc_STRVAR(clock_getres_doc,
-"clock_getres(clk_id) -> floating point number\n\
+"clock_getres(clk_id, timestamp=float) -> floating point number\n\
 \n\
 Return the resolution (precision) of the specified clock clk_id.");
 #endif
@@ -702,10 +745,19 @@ not present, current time as returned by
 
 #ifdef HAVE_MKTIME
 static PyObject *
-time_mktime(PyObject *self, PyObject *tup)
+time_mktime(PyObject *self, PyObject *args, PyObject *kwargs)
 {
+    static char *kwlist[] = {"t", "timestamp", NULL};
+    PyObject *tup;
+    PyObject *timestamp = NULL;
     struct tm buf;
     time_t tt;
+    _PyTime_t ts;
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O|O:mktime", kwlist,
+                                     &tup, &timestamp))
+        return NULL;
+
     if (!gettmarg(tup, &buf))
         return NULL;
     buf.tm_wday = -1;  /* sentinel; original value ignored */
@@ -717,7 +769,10 @@ time_mktime(PyObject *self, PyObject *tu
                         "mktime argument out of range");
         return NULL;
     }
-    return PyFloat_FromDouble((double)tt);
+    ts.seconds = tt;
+    ts.numerator = 0;
+    ts.denominator = 1;
+    return _PyTime_Convert(&ts, timestamp);
 }
 
 PyDoc_STRVAR(mktime_doc,
@@ -763,12 +818,14 @@ the local timezone used by methods such 
 should not be relied on.");
 #endif /* HAVE_WORKING_TZSET */
 
-static PyObject *
-time_wallclock(PyObject *self, PyObject *unused)
+static int
+pywallclock(_PyTime_t *ts)
 {
 #if defined(MS_WINDOWS) && !defined(__BORLANDC__)
-    return time_clock(self, NULL);
-#elif defined(HAVE_CLOCK_GETTIME) && defined(CLOCK_MONOTONIC)
+    return win32_pyclock(ts);
+#else
+
+#if defined(HAVE_CLOCK_GETTIME) && defined(CLOCK_MONOTONIC)
     static int clk_index = 0;
     clockid_t clk_ids[] = {
 #ifdef CLOCK_MONOTONIC_RAW
@@ -788,20 +845,40 @@ time_wallclock(PyObject *self, PyObject 
         clockid_t clk_id = clk_ids[clk_index];
         ret = clock_gettime(clk_id, &tp);
         if (ret == 0)
-            return PyFloat_FromDouble(tp.tv_sec + tp.tv_nsec * 1e-9);
+        {
+            ts->seconds = tp.tv_sec;
+            ts->numerator = tp.tv_nsec;
+            ts->denominator = 1000000000;
+            return 0;
+        }
 
         clk_index++;
         if (Py_ARRAY_LENGTH(clk_ids) <= clk_index)
             clk_index = -1;
     }
-    return time_time(self, NULL);
-#else
-    return time_time(self, NULL);
+#endif /* defined(HAVE_CLOCK_GETTIME) && defined(CLOCK_MONOTONIC) */
+    _PyTime_get(ts);
+    return 0;
 #endif
 }
 
+static PyObject *
+time_wallclock(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+    static char *kwlist[] = {"timestamp", NULL};
+    PyObject *timestamp = NULL;
+    _PyTime_t ts;
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "|O:wallclock", kwlist,
+                                     &timestamp))
+        return NULL;
+    if (pywallclock(&ts))
+        return NULL;
+    return _PyTime_Convert(&ts, timestamp);
+}
+
 PyDoc_STRVAR(wallclock_doc,
-"wallclock() -> float\n\
+"wallclock(timestamp=float)\n\
 \n\
 Return the current time in fractions of a second to the system's best\n\
 ability. Use this when the most accurate representation of wall-clock is\n\
@@ -919,15 +996,19 @@ PyInit_timezone(PyObject *m) {
 
 
 static PyMethodDef time_methods[] = {
-    {"time",            time_time, METH_NOARGS, time_doc},
-#if (defined(MS_WINDOWS) && !defined(__BORLANDC__)) || defined(HAVE_CLOCK)
-    {"clock",           time_clock, METH_NOARGS, clock_doc},
+    {"time",            (PyCFunction)time_time,
+                        METH_VARARGS | METH_KEYWORDS, time_doc},
+#ifdef HAVE_PYCLOCK
+    {"clock",           (PyCFunction)time_clock,
+                        METH_VARARGS | METH_KEYWORDS, clock_doc},
 #endif
 #ifdef HAVE_CLOCK_GETTIME
-    {"clock_gettime",   time_clock_gettime, METH_VARARGS, clock_gettime_doc},
+    {"clock_gettime",   (PyCFunction)time_clock_gettime,
+                        METH_VARARGS | METH_KEYWORDS, clock_gettime_doc},
 #endif
 #ifdef HAVE_CLOCK_GETRES
-    {"clock_getres",    time_clock_getres, METH_VARARGS, clock_getres_doc},
+    {"clock_getres",    (PyCFunction)time_clock_getres,
+                        METH_VARARGS | METH_KEYWORDS, clock_getres_doc},
 #endif
     {"sleep",           time_sleep, METH_VARARGS, sleep_doc},
     {"gmtime",          time_gmtime, METH_VARARGS, gmtime_doc},
@@ -935,7 +1016,8 @@ static PyMethodDef time_methods[] = {
     {"asctime",         time_asctime, METH_VARARGS, asctime_doc},
     {"ctime",           time_ctime, METH_VARARGS, ctime_doc},
 #ifdef HAVE_MKTIME
-    {"mktime",          time_mktime, METH_O, mktime_doc},
+    {"mktime",          (PyCFunction)time_mktime,
+                        METH_VARARGS | METH_KEYWORDS, mktime_doc},
 #endif
 #ifdef HAVE_STRFTIME
     {"strftime",        time_strftime, METH_VARARGS, strftime_doc},
@@ -944,7 +1026,8 @@ static PyMethodDef time_methods[] = {
 #ifdef HAVE_WORKING_TZSET
     {"tzset",           time_tzset, METH_NOARGS, tzset_doc},
 #endif
-    {"wallclock",       time_wallclock, METH_NOARGS, wallclock_doc},
+    {"wallclock",       (PyCFunction)time_wallclock,
+                        METH_VARARGS | METH_KEYWORDS, wallclock_doc},
     {NULL,              NULL}           /* sentinel */
 };
 
@@ -1029,15 +1112,6 @@ PyInit_time(void)
     return m;
 }
 
-static double
-floattime(void)
-{
-    _PyTime_timeval t;
-    _PyTime_gettimeofday(&t);
-    return (double)t.tv_sec + t.tv_usec*0.000001;
-}
-
-
 /* Implement floatsleep() for various platforms.
    When interrupted (or when another error occurs), return -1 and
    set an exception; else return 0. */
diff --git a/Python/pytime.c b/Python/pytime.c
--- a/Python/pytime.c
+++ b/Python/pytime.c
@@ -19,8 +19,10 @@ extern int ftime(struct timeb *);
 #endif /* MS_WINDOWS */
 #endif /* HAVE_FTIME */
 
+#define MICROSECONDS    1000000
+
 void
-_PyTime_gettimeofday(_PyTime_timeval *tp)
+_PyTime_get(_PyTime_t *ts)
 {
     /* There are three ways to get the time:
       (1) gettimeofday() -- resolution in microseconds
@@ -30,27 +32,320 @@ _PyTime_gettimeofday(_PyTime_timeval *tp
       Since on some systems (e.g. SCO ODT 3.0) gettimeofday() may
       fail, so we fall back on ftime() or time().
       Note: clock resolution does not imply clock accuracy! */
+
+#ifdef HAVE_GETTIMEOFDAY
+    struct timeval tv;
+    int err;
+#endif
+#if defined(HAVE_FTIME)
+    struct timeb t;
+#endif
+
 #ifdef HAVE_GETTIMEOFDAY
 #ifdef GETTIMEOFDAY_NO_TZ
-    if (gettimeofday(tp) == 0)
+    err = gettimeofday(&tv);
+#else /* !GETTIMEOFDAY_NO_TZ */
+    err = gettimeofday(&tv, (struct timezone *)NULL);
+#endif /* !GETTIMEOFDAY_NO_TZ */
+    if (err == 0)
+    {
+        ts->seconds = tv.tv_sec;
+        ts->numerator = tv.tv_usec;
+        ts->denominator = MICROSECONDS;
         return;
-#else /* !GETTIMEOFDAY_NO_TZ */
-    if (gettimeofday(tp, (struct timezone *)NULL) == 0)
-        return;
-#endif /* !GETTIMEOFDAY_NO_TZ */
+    }
 #endif /* !HAVE_GETTIMEOFDAY */
+
 #if defined(HAVE_FTIME)
+    ftime(&t);
+    ts->seconds = t.time;
+    ts->numerator = t.millitm;
+    ts->denominator = 1000;
+#else /* !HAVE_FTIME */
+    ts->seconds = time(NULL);
+    ts->numerator = 0;
+    ts->denominator = 1;
+#endif /* !HAVE_FTIME */
+}
+
+void
+_PyTime_gettimeofday(_PyTime_timeval *tv)
+{
+    _PyTime_t ts;
+    size_t k;
+
+    _PyTime_get(&ts);
+    tv->tv_sec = ts.seconds;
+    if (ts.numerator) {
+        if (ts.numerator > ts.denominator) {
+            /* no check for integer overflow */
+            tv->tv_sec += ts.numerator / ts.denominator;
+            ts.numerator = ts.numerator % ts.denominator;
+        }
+        if (MICROSECONDS >= ts.denominator) {
+            k = MICROSECONDS / ts.denominator;
+            tv->tv_usec = ts.numerator * k;
+        }
+        else {
+            k = ts.denominator / MICROSECONDS;
+            tv->tv_usec = ts.numerator / k;
+        }
+    }
+    else {
+        tv->tv_usec = 0;
+    }
+}
+
+static PyObject*
+PyLong_FromTime_t(time_t value)
+{
+#if SIZEOF_TIME_T <= SIZEOF_LONG
+    return PyLong_FromLong(value);
+#else
+    assert(sizeof(time_t) <= sizeof(PY_LONG_LONG));
+    return PyLong_FromLongLong(value);
+#endif
+}
+
+/* Convert a timestamp to a PyFloat object */
+static PyObject*
+_PyTime_AsFloat(_PyTime_t *ts)
+{
+    double d;
+    d = (double)ts->seconds;
+    d += (double)ts->numerator / (double)ts->denominator;
+    return PyFloat_FromDouble(d);
+}
+
+/* Convert a timestamp to a PyLong object */
+static PyObject*
+_PyTime_AsLong(_PyTime_t *ts)
+{
+    PyObject *a, *b, *c;
+
+    a = PyLong_FromTime_t(ts->seconds);
+    if (a == NULL)
+        return NULL;
+    b = PyLong_FromSize_t(ts->numerator / ts->denominator);
+    if (b == NULL)
     {
-        struct timeb t;
-        ftime(&t);
-        tp->tv_sec = t.time;
-        tp->tv_usec = t.millitm * 1000;
+        Py_DECREF(a);
+        return NULL;
     }
-#else /* !HAVE_FTIME */
-    tp->tv_sec = time(NULL);
-    tp->tv_usec = 0;
-#endif /* !HAVE_FTIME */
-    return;
+    c = PyNumber_Add(a, b);
+    Py_DECREF(a);
+    Py_DECREF(b);
+    return c;
+}
+
+/* Convert a timestamp to a decimal.Decimal object */
+static PyObject*
+_PyTime_AsDecimal(_PyTime_t *ts)
+{
+    static PyObject* module = NULL;
+    static PyObject* decimal = NULL;
+    static PyObject* exponent_context = NULL;
+    static PyObject* context = NULL;
+    /* resolution cache (1/denominator), dictionary of int (denominator)=>Decimal */
+    static PyObject* exponents = NULL;
+    PyObject *t = NULL;
+    PyObject *key, *exponent, *quantized;
+    _Py_IDENTIFIER(quantize);
+    _Py_IDENTIFIER(__truediv__);
+
+    if (!module) {
+        module = PyImport_ImportModuleNoBlock("decimal");
+        if (module == NULL)
+            return NULL;
+    }
+
+    if (!decimal) {
+        decimal = PyObject_GetAttrString(module, "Decimal");
+        if (decimal == NULL)
+            return NULL;
+    }
+
+    if (context == NULL)
+    {
+        /* Use 12 decimal digits to store 10,000 years in seconds + 9
+           decimal digits for the floating part in nanoseconds + 1 decimal
+           digit to round correctly.
+
+           context = decimal.Context(22, rounding=decimal.ROUND_HALF_EVEN)
+           exponent_context = decimal.Context(1, rounding=decimal.ROUND_HALF_EVEN)
+        */
+        PyObject *context_class, *rounding;
+        context_class = PyObject_GetAttrString(module, "Context");
+        if (context_class == NULL)
+            return NULL;
+        rounding = PyObject_GetAttrString(module, "ROUND_HALF_EVEN");
+        if (rounding == NULL)
+        {
+            Py_DECREF(context_class);
+            return NULL;
+        }
+        context = PyObject_CallFunction(context_class, "iO", 22, rounding);
+        if (context == NULL)
+        {
+            Py_DECREF(context_class);
+            Py_DECREF(rounding);
+            return NULL;
+        }
+
+        exponent_context = PyObject_CallFunction(context_class, "iO", 1, rounding);
+        Py_DECREF(context_class);
+        Py_DECREF(rounding);
+        if (exponent_context == NULL)
+        {
+            Py_CLEAR(context);
+            return NULL;
+        }
+    }
+
+    /* t = decimal.Decimal(value, context) */
+    if (ts->seconds) {
+        PyObject *f = PyLong_FromTime_t(ts->seconds);
+        t = PyObject_CallFunction(decimal, "OO", f, context);
+        Py_CLEAR(f);
+    }
+    else {
+        t = PyObject_CallFunction(decimal, "iO", 0, context);
+    }
+    if (t == NULL)
+        return NULL;
+
+    if (ts->numerator)
+    {
+        /* t += decimal.Decimal(numerator, ctx) / decimal.Decimal(denominator, ctx) */
+        PyObject *a, *b, *c, *d, *x;
+
+        x = PyLong_FromSize_t(ts->numerator);
+        if (x == NULL)
+            goto error;
+        a = PyObject_CallFunction(decimal, "OO", x, context);
+        Py_CLEAR(x);
+        if (a == NULL)
+            goto error;
+
+        x = PyLong_FromSize_t(ts->denominator);
+        if (x == NULL)
+        {
+            Py_DECREF(a);
+            goto error;
+        }
+        b = PyObject_CallFunction(decimal, "OO", x, context);
+        Py_CLEAR(x);
+        if (b == NULL)
+        {
+            Py_DECREF(a);
+            goto error;
+        }
+
+        c = _PyObject_CallMethodId(a, &PyId___truediv__, "OO",
+                                   b, context);
+        Py_DECREF(a);
+        Py_DECREF(b);
+        if (c == NULL)
+            goto error;
+
+        d = PyNumber_Add(t, c);
+        Py_DECREF(c);
+        if (d == NULL)
+            goto error;
+        Py_DECREF(t);
+        t = d;
+    }
+
+    if (exponents == NULL) {
+        exponents = PyDict_New();
+        if (exponents == NULL)
+            goto error;
+    }
+
+    key = PyLong_FromSize_t(ts->denominator);
+    if (key == NULL)
+        goto error;
+    exponent = PyDict_GetItem(exponents, key);
+    if (exponent == NULL) {
+        /* exponent = decimal.Decimal(1) / decimal.Decimal(resolution) */
+        PyObject *one, *denominator;
+
+        one = PyObject_CallFunction(decimal, "i", 1);
+        if (one == NULL) {
+            Py_DECREF(key);
+            goto error;
+        }
+
+        denominator = PyObject_CallFunction(decimal, "O", key);
+        if (denominator == NULL) {
+            Py_DECREF(key);
+            Py_DECREF(one);
+            goto error;
+        }
+
+        exponent = _PyObject_CallMethodId(one, &PyId___truediv__, "OO",
+                                          denominator, exponent_context);
+        Py_DECREF(one);
+        Py_DECREF(denominator);
+        if (exponent == NULL) {
+            Py_DECREF(key);
+            goto error;
+        }
+
+        if (PyDict_SetItem(exponents, key, exponent) < 0) {
+            Py_DECREF(key);
+            Py_DECREF(exponent);
+            goto error;
+        }
+        Py_DECREF(key);
+    }
+
+    /* t = t.quantize(exponent, None, context) */
+    quantized = _PyObject_CallMethodId(t, &PyId_quantize, "OOO",
+                                       exponent, Py_None, context);
+    if (quantized == NULL)
+        goto error;
+    Py_DECREF(t);
+    t = quantized;
+
+    return t;
+
+error:
+    Py_XDECREF(t);
+    return NULL;
+}
+
+PyObject*
+_PyTime_Convert(_PyTime_t *ts, PyObject *format)
+{
+    assert(ts->denominator != 0);
+
+    if (format == NULL || (PyTypeObject *)format == &PyFloat_Type)
+        return _PyTime_AsFloat(ts);
+    if ((PyTypeObject *)format == &PyLong_Type)
+        return _PyTime_AsLong(ts);
+
+    if (PyType_Check(format))
+    {
+        PyObject *module, *name;
+        _Py_IDENTIFIER(__name__);
+        _Py_IDENTIFIER(__module__);
+
+        module = _PyObject_GetAttrId(format, &PyId___module__);
+        name = _PyObject_GetAttrId(format, &PyId___name__);
+        if (module != NULL && PyUnicode_Check(module)
+            && name != NULL && PyUnicode_Check(name))
+        {
+            if (PyUnicode_CompareWithASCIIString(module, "decimal") == 0
+                && PyUnicode_CompareWithASCIIString(name, "Decimal") == 0)
+                return _PyTime_AsDecimal(ts);
+        }
+        else
+            PyErr_Clear();
+    }
+
+    PyErr_Format(PyExc_ValueError, "Unknown timestamp format: %R", format);
+    return NULL;
 }
 
 void

From report at bugs.python.org  Thu Feb  2 14:26:24 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 02 Feb 2012 13:26:24 +0000
Subject: [issue13924] Mercurial robots.txt should let robots crawl landing
	pages.
In-Reply-To: <1328135396.1.0.0965106732225.issue13924@psf.upfronthosting.co.za>
Message-ID: <1328189184.72.0.59604153262.issue13924@psf.upfronthosting.co.za>


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

Can you propose a robots.txt file?

----------
nosy: +georg.brandl, pitrou

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

From report at bugs.python.org  Thu Feb  2 15:29:29 2012
From: report at bugs.python.org (Jeroen)
Date: Thu, 02 Feb 2012 14:29:29 +0000
Subject: [issue13926] IDLE closes when requesting a list of available modules
	in the online help utility
Message-ID: <1328192969.57.0.104447705618.issue13926@psf.upfronthosting.co.za>


Changes by Jeroen <dariojee at gmail.com>:


----------
components: IDLE
nosy: Jeroen
priority: normal
severity: normal
status: open
title: IDLE closes when requesting a list of available modules in the online help utility
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb  2 15:40:06 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 02 Feb 2012 14:40:06 +0000
Subject: [issue13889] str(float) and round(float) issues with FPU precision
In-Reply-To: <1327676303.66.0.487112802864.issue13889@psf.upfronthosting.co.za>
Message-ID: <1328193606.51.0.652966566786.issue13889@psf.upfronthosting.co.za>


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

> Hi Marc, the changes to the pythoncore.vcproj Visual-Studio file define > the HAVE_VC_FUNC_FOR_X87 symbol.

Okay, makes sense.  I was distracted by the spurious reordering of in the diff for pythoncore.vcproj.

Just to be clear, the intent of the patch is that the FPU state is *always* switched on Windows prior to calling the dtoa.c functions;  is that right?

Things to think about:

 - can we avoid *writing* to the x87 / SSE control word if no change is necessary (as is currently done with the gcc code)?  We want to avoid unnecessary FPU pipeline flushes.

 - we need to make sure that the patch works on 64-bit.  There's a bit of text at:

    http://msdn.microsoft.com/en-us/library/c9676k6h.aspx

   that suggests that in x64 mode, setting the precision is an error.

 - what happens if the x87 and SSE2 control words have different precisions?  Does the patch restore both those precisions correctly?

 - in the patch, isn't new387controlword unused?

I'm not sure that this part of the patch can go into the maintenance branches (2.7, 3.2);  if this is a new feature (and I think it is, but I'm willing to be persuaded otherwise), it can only target 3.3.

----------

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

From report at bugs.python.org  Thu Feb  2 15:42:52 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 02 Feb 2012 14:42:52 +0000
Subject: [issue13924] Mercurial robots.txt should let robots crawl landing
	pages.
In-Reply-To: <1328135396.1.0.0965106732225.issue13924@psf.upfronthosting.co.za>
Message-ID: <1328193772.85.0.760408006525.issue13924@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/issue13924>
_______________________________________

From report at bugs.python.org  Thu Feb  2 15:45:30 2012
From: report at bugs.python.org (Jeroen)
Date: Thu, 02 Feb 2012 14:45:30 +0000
Subject: [issue13926] IDLE closes when requesting a list of available modules
	in the online help utility
In-Reply-To: <1328192969.61.0.257301956295.issue13926@psf.upfronthosting.co.za>
Message-ID: <CA+0o7Qhzry+gjk3dwLqwtvckxKq=QpDeg-84po9Ve-fHsn-boQ@mail.gmail.com>


New submission from Jeroen <dariojee at gmail.com>:

When using IDLE (2.7.2) in Ubuntu 11.10 the following error occurs:

When the online help utility in IDLE is started (by entering the help()
commando), it should be possible to get a list of all available modules by
typing "modules". When I do so a message is shown that the list will be
created, but after a few seconds the list isn't shown but IDLE is closed
instead.

Python version: Python 2.7.2+ (default, Oct  4 2011, 20:06:09) [GCC 4.6.1]
on linux2
Tk version: 8.5
IDLE version: 2.7.2

2012/2/2 Jeroen <report at bugs.python.org>

>
> Changes by Jeroen <dariojee at gmail.com>:
>
>
> ----------
> components: IDLE
> nosy: Jeroen
> priority: normal
> severity: normal
> status: open
> title: IDLE closes when requesting a list of available modules in the
> online help utility
> type: behavior
> versions: Python 2.7
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13926>
> _______________________________________
>

----------

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

From report at bugs.python.org  Thu Feb  2 16:53:34 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 02 Feb 2012 15:53:34 +0000
Subject: [issue13856] xmlrpc / httplib changes to allow for certificate
	verification
In-Reply-To: <1327446175.17.0.819972733751.issue13856@psf.upfronthosting.co.za>
Message-ID: <1328198014.42.0.179351119391.issue13856@psf.upfronthosting.co.za>


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

I am sorry. I see that with context object in 3.x, verification is being done. The CA certs can be pointed to using load_verify_locations. 

As the author had in this patc tothe pass on addition ca_certs and ca_reqs to wrap_socket in ssl from httplib2. I thought, it was a new requirement. In 2.7, those args are not present. 

For this issue, modifying the xmlrpc.client to support ssl context and making a HTTPConnection with context object is present may be way to go.

----------

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

From report at bugs.python.org  Thu Feb  2 17:00:00 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 02 Feb 2012 16:00:00 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <E1Rsz4o-00042o-EG@dinsdale.python.org>


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

New changeset a55ffb6c1993 by Stefan Krah in branch '3.2':
Issue #1813: Revert workaround for a glibc bug on the Fedora buildbot.
http://hg.python.org/cpython/rev/a55ffb6c1993

New changeset 4244e4348362 by Stefan Krah in branch 'default':
Issue #1813: merge changeset that reverts a glibc workaround for the
http://hg.python.org/cpython/rev/4244e4348362

New changeset 0b8917fc6db5 by Stefan Krah in branch '2.7':
Issue #1813: backport changeset that reverts a glibc workaround for the
http://hg.python.org/cpython/rev/0b8917fc6db5

----------

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

From report at bugs.python.org  Thu Feb  2 17:06:37 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 02 Feb 2012 16:06:37 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1328198797.86.0.289455133552.issue1813@psf.upfronthosting.co.za>


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

I've upgraded the Fedora buildbot to Fedora-16. The specific glibc
workaround should not be necessary any more.


So the test will now fail again on all systems that a) have the bug
and b) the tr_Tr locale.

----------

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

From report at bugs.python.org  Thu Feb  2 17:08:19 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 02 Feb 2012 16:08:19 +0000
Subject: [issue13856] xmlrpc / httplib changes to allow for certificate
	verification
In-Reply-To: <1328198014.42.0.179351119391.issue13856@psf.upfronthosting.co.za>
Message-ID: <1328198748.3418.2.camel@localhost.localdomain>


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

> For this issue, modifying the xmlrpc.client to support ssl context and
> making a HTTPConnection with context object is present may be way to
> go.

xmlrpc is higher level than http.client, so you might also adopt the
urllib approach of passing ca_file and ca_path. As you (or Martin)
prefer :-)

----------

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

From report at bugs.python.org  Thu Feb  2 17:11:57 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 02 Feb 2012 16:11:57 +0000
Subject: [issue13921] sqlite3: OptimizedUnicode doesn't work in Py3k
In-Reply-To: <1328129858.32.0.164852943165.issue13921@psf.upfronthosting.co.za>
Message-ID: <1328199117.02.0.5298614101.issue13921@psf.upfronthosting.co.za>


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

Attached a patch. It changes OptimizedUnicode to be an alias for PyUnicode_Type and adds a note to the documentation for porters from 2.x that it has no effect on py3k.

The patch removes/refactors all OptimizedUnicode and allow_8bit_chars related obsolete code that had been left over from py3k transition. These removals/refactorizations have no operational effect, so the module still works the same way it has always worked in Py3k.

Should OptimizedUnicode be deprecated, too? In this case, it cannot be aliased to str, and _pysqlite_fetch_one_row() needs to raise a DeprecationWarning if OptimizedUnicode is used.

----------

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

From report at bugs.python.org  Thu Feb  2 17:12:16 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 02 Feb 2012 16:12:16 +0000
Subject: [issue13921] sqlite3: OptimizedUnicode doesn't work in Py3k
In-Reply-To: <1328129858.32.0.164852943165.issue13921@psf.upfronthosting.co.za>
Message-ID: <1328199136.35.0.44871812177.issue13921@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file24397/issue13921.patch

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

From report at bugs.python.org  Thu Feb  2 17:12:47 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 02 Feb 2012 16:12:47 +0000
Subject: [issue13921] sqlite3: OptimizedUnicode doesn't work in Py3k
In-Reply-To: <1328129858.32.0.164852943165.issue13921@psf.upfronthosting.co.za>
Message-ID: <1328199167.53.0.199642707473.issue13921@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Feb  2 17:15:40 2012
From: report at bugs.python.org (Stephen White)
Date: Thu, 02 Feb 2012 16:15:40 +0000
Subject: [issue13817] deadlock in subprocess while running several threads
	using Popen
In-Reply-To: <1326909636.44.0.892345276723.issue13817@psf.upfronthosting.co.za>
Message-ID: <1328199340.63.0.049860834752.issue13817@psf.upfronthosting.co.za>


Changes by Stephen White <stephen-python.org at randomstuff.org.uk>:


----------
nosy: +Stephen.White

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

From report at bugs.python.org  Thu Feb  2 17:23:02 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 02 Feb 2012 16:23:02 +0000
Subject: [issue13921] sqlite3: OptimizedUnicode doesn't work in Py3k
In-Reply-To: <1328129858.32.0.164852943165.issue13921@psf.upfronthosting.co.za>
Message-ID: <1328199782.2.0.425714638318.issue13921@psf.upfronthosting.co.za>


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

> Should OptimizedUnicode be deprecated, too?

I'd say just undocument it.

----------

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

From report at bugs.python.org  Thu Feb  2 17:43:39 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 02 Feb 2012 16:43:39 +0000
Subject: [issue13921] sqlite3: OptimizedUnicode doesn't work in Py3k
In-Reply-To: <1328199782.2.0.425714638318.issue13921@psf.upfronthosting.co.za>
Message-ID: <20120202164336.GA1934@ihaa>


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

> > Should OptimizedUnicode be deprecated, too?
> 
> I'd say just undocument it.

Even remove the note from the patch?

----------

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

From report at bugs.python.org  Thu Feb  2 17:47:17 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 02 Feb 2012 16:47:17 +0000
Subject: [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za>
Message-ID: <1328201237.03.0.377627077762.issue13124@psf.upfronthosting.co.za>


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

Here's a terse shell script that IMO even moderately experienced admins
will prefer to the current version.

I'm not sure if the devguide is the right place for this, since
non-devs are very welcome to set up buildbots.

----------
nosy: +pitrou
Added file: http://bugs.python.org/file24398/buildslave_install.sh

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

From report at bugs.python.org  Thu Feb  2 17:51:48 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 02 Feb 2012 16:51:48 +0000
Subject: [issue13921] sqlite3: OptimizedUnicode doesn't work in Py3k
In-Reply-To: <20120202164336.GA1934@ihaa>
Message-ID: <1328201356.3418.4.camel@localhost.localdomain>


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

Le jeudi 02 f?vrier 2012 ? 16:43 +0000, Petri Lehtinen a ?crit :
> Petri Lehtinen <petri at digip.org> added the comment:
> 
> > > Should OptimizedUnicode be deprecated, too?
> > 
> > I'd say just undocument it.
> 
> Even remove the note from the patch?

Well, I guess keeping the note is fine.

----------

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

From report at bugs.python.org  Thu Feb  2 17:59:47 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 02 Feb 2012 16:59:47 +0000
Subject: [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za>
Message-ID: <1328201987.58.0.365841442935.issue13124@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Added file: http://bugs.python.org/file24399/buildslave_install.txt

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

From report at bugs.python.org  Thu Feb  2 18:00:04 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 02 Feb 2012 17:00:04 +0000
Subject: [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za>
Message-ID: <1328202004.77.0.0709967452243.issue13124@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Removed file: http://bugs.python.org/file24398/buildslave_install.txt

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

From report at bugs.python.org  Thu Feb  2 18:08:50 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 02 Feb 2012 17:08:50 +0000
Subject: [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1328201237.03.0.377627077762.issue13124@psf.upfronthosting.co.za>
Message-ID: <1328202378.3418.6.camel@localhost.localdomain>


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

> Here's a terse shell script that IMO even moderately experienced admins
> will prefer to the current version.

I'm sure some admins will prefer using their system's packages (I think
buildbot is packaged for Debian/Ubuntu, I see it in Mageia's packages,
not sure about Fedora).

Anyway, the current instructions are on the wiki:
http://wiki.python.org/moin/BuildBot
You could add your script or link to it there.

----------

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

From report at bugs.python.org  Thu Feb  2 18:43:04 2012
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 02 Feb 2012 17:43:04 +0000
Subject: [issue13926] pydoc - stall when requesting a list of available
	modules in the online help utility
In-Reply-To: <CA+0o7Qhzry+gjk3dwLqwtvckxKq=QpDeg-84po9Ve-fHsn-boQ@mail.gmail.com>
Message-ID: <1328204584.48.0.0303985386466.issue13926@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I tried this and while IDLE didn't crash, it stalled when running with and without a subprocess. I then tried running this from the regular python interpreter and it stalled there as well. This is not a problem with IDLE, but a problem with pydoc itself.

Steps to reproduce:

    >>> help()

    help> modules

    -- stall --

A blank "Tk" window suddenly appeared, which suggested that something loaded Tkinter. Digging deeper, the "help" utility in Lib/pydoc.py loads every single module found on in sys.path in order to get its __doc__ string. This is doing too much work as the purpose of "modules" is to give a list of available modules.

I modified "ModuleScanner" in pydoc.py so that loader.load_module doesn't get called. I set "desc" and "path" do hard-coded strings and now "modules" returns a list very quickly. A blank tkinter window still pops up, however.

----------
components: +Library (Lib) -IDLE
nosy: +pje, serwy, terry.reedy
title: IDLE closes when requesting a list of available modules in the online help utility -> pydoc - stall when requesting a list of available modules in the online help utility

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

From report at bugs.python.org  Thu Feb  2 20:08:46 2012
From: report at bugs.python.org (Stan Cox)
Date: Thu, 02 Feb 2012 19:08:46 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1328209726.63.0.0395182540806.issue13405@psf.upfronthosting.co.za>


Stan Cox <scox at redhat.com> added the comment:

This is a subset of the dtrace patch and consists of the minimal functionality
needed by systemtap.  The only files that are changed from upstream sources are
as follows.

* configure/configure.in
* Makefile.pre.in
* pyconfig.h.in
  Same changes as the dtrace patch except there is no phelper.

* pydtrace.d
  Same change as the dtrace patch except added PyFrameObject to probes.
  Instead of passing in fields like filename and function name, the systemtap
  scripts (not shown) use PyFrameObject and access the python data structures.
  The overhead for a systemtap probe is a single nop and PyFrameObject is
  possibly live at the probe point so the overhead will be minimal.  pydtrace.h
  is always generated since this file is different for dtrace and stap.

* ceval.c
  The only changes to ceval.c from the upstream version are the addition of the
  PYTHON_FUNCTION_ENTRY and PYTHON_FUNCTION_RETURN probes.
  PYTHON_FUNCTION_ENTRY is invoked directly since the overhead of the probe is
  less than the overhead of a conditional check.  The probe passes the
  PyFrameObject, as mentioned above, but nothing else.  Likewise for
  PYTHON_FUNCTION_RETURN.

systemtap tapset, not included in patch, will provide backtrace results such as:
 #0 main  at /.../python/celsius.py:19
 #1 <module>  at /.../python/celsius.py:3
 #2 celsius_to_farenheit (celsius:int ) at /.../python/celsius.py:7
and variable trace results such as:
 tuple atuple in celsius_to_farenheit at /.../python/celsius.py =  "a", "b", "c",
 list alist in celsius_to_farenheit at /.../python/celsius.py = [ 1, 2, 3,]
 set aset in celsius_to_farenheit at /.../python/celsius.py = { 1, 2, 3,}
...

----------
Added file: http://bugs.python.org/file24400/python-stap.patch

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

From report at bugs.python.org  Thu Feb  2 20:18:17 2012
From: report at bugs.python.org (Phillip J. Eby)
Date: Thu, 02 Feb 2012 19:18:17 +0000
Subject: [issue13926] pydoc - stall when requesting a list of available
	modules in the online help utility
In-Reply-To: <1328204584.48.0.0303985386466.issue13926@psf.upfronthosting.co.za>
Message-ID: <CALeMXf7-W1io0sDJzsMwmLZa_ZBn3bE+Yqfutz0meH-MFFE1BQ@mail.gmail.com>


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

The problem might be that you're iterating over more than just the top
level; if you look for submodules then the parent package has to be
imported... and that might make that window load, if there's module-level
code in the package __init__ that does that.

----------

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

From report at bugs.python.org  Thu Feb  2 20:30:25 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 02 Feb 2012 19:30:25 +0000
Subject: [issue13402] Document absoluteness of sys.executable
In-Reply-To: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za>
Message-ID: <E1Rt2MO-00029J-TO@dinsdale.python.org>


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

New changeset fdcda5b74317 by Petri Lehtinen in branch '3.2':
Document absoluteness of sys.executable
http://hg.python.org/cpython/rev/fdcda5b74317

New changeset 8b591a86fc91 by Petri Lehtinen in branch 'default':
Merge branch 3.2
http://hg.python.org/cpython/rev/8b591a86fc91

New changeset c351536e804a by Petri Lehtinen in branch '2.7':
Document absoluteness of sys.executable
http://hg.python.org/cpython/rev/c351536e804a

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

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

From report at bugs.python.org  Thu Feb  2 20:39:18 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 02 Feb 2012 19:39:18 +0000
Subject: [issue13817] deadlock in subprocess while running several threads
	using Popen
In-Reply-To: <1326909636.44.0.892345276723.issue13817@psf.upfronthosting.co.za>
Message-ID: <E1Rt2V3-00031P-B9@dinsdale.python.org>


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

New changeset c3649173d093 by Charles-Fran?ois Natali in branch '2.7':
Issue #13817: After fork(), reinit the ad-hoc TLS implementation earlier to fix
http://hg.python.org/cpython/rev/c3649173d093

New changeset 7b24dd587a7b by Charles-Fran?ois Natali in branch '3.2':
Issue #13817: After fork(), reinit the ad-hoc TLS implementation earlier to fix
http://hg.python.org/cpython/rev/7b24dd587a7b

New changeset a0100852b6fe by Charles-Fran?ois Natali in branch 'default':
Issue #13817: After fork(), reinit the ad-hoc TLS implementation earlier to fix
http://hg.python.org/cpython/rev/a0100852b6fe

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

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

From report at bugs.python.org  Thu Feb  2 21:49:36 2012
From: report at bugs.python.org (Roger Caldwell)
Date: Thu, 02 Feb 2012 20:49:36 +0000
Subject: [issue13927] Extra spaces in the output of time.ctime
Message-ID: <1328215776.48.0.974828105123.issue13927@psf.upfronthosting.co.za>


New submission from Roger Caldwell <roger at monkey.net>:

Hi.  I found this today and thought I would report.  I could not find anywhere that it was expected behavior.  When using time.ctime() to convert a date which only has 1 digit in the day position it returs a string with 2 spaces after the month vs one.

example
In [2]: import os,time

In [3]: time.ctime(os.path.getmtime('file.cfg'))
Out[3]: 'Tue Dec 13 18:52:58 2011'

In [4]: time.ctime(os.path.getmtime('14d-1.log'))
Out[4]: 'Tue Feb  1 19:53:11 2011'

Is this expected behavior?

----------
components: None
messages: 152475
nosy: Roger.Caldwell
priority: normal
severity: normal
status: open
title: Extra spaces in the output of time.ctime
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb  2 22:06:05 2012
From: report at bugs.python.org (toggtc)
Date: Thu, 02 Feb 2012 21:06:05 +0000
Subject: [issue13901] test_get_outputs (test_distutils) failure with
	--enable-shared on Mac OS X
In-Reply-To: <1327826805.0.0.304314009246.issue13901@psf.upfronthosting.co.za>
Message-ID: <1328216765.92.0.28526747474.issue13901@psf.upfronthosting.co.za>


toggtc <toggtc at gmail.com> added the comment:

Thank you for analysis and explanations, Ned. 
In addition, the -L(whitespace) is not allowed in Apple's GCC. GNU's GCC is OK. (I checked it using both GCC 4.2)
So, your solution is right.

----------

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

From report at bugs.python.org  Thu Feb  2 22:25:20 2012
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 02 Feb 2012 21:25:20 +0000
Subject: [issue13857] Add textwrap.indent() as counterpart to textwrap.dedent()
In-Reply-To: <1327462635.84.0.618726818638.issue13857@psf.upfronthosting.co.za>
Message-ID: <1328217920.57.0.139160581979.issue13857@psf.upfronthosting.co.za>


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

IMO removing trailing newlines is not acceptable. You could use splitlines(keepends=True) to keep final newlines (but then the default function that determines lines to indent needs to ignore these newlines).

----------

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

From report at bugs.python.org  Thu Feb  2 22:29:15 2012
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 02 Feb 2012 21:29:15 +0000
Subject: [issue13918] locale.atof documentation is missing func argument
In-Reply-To: <1328105541.08.0.458455853203.issue13918@psf.upfronthosting.co.za>
Message-ID: <1328218155.24.0.521535404776.issue13918@psf.upfronthosting.co.za>


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

I don't think that argument needs to be documented.  It's just there because somebody thought that copying 3 lines from atof into atoi was a bad idea.

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

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

From report at bugs.python.org  Thu Feb  2 22:36:30 2012
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Thu, 02 Feb 2012 21:36:30 +0000
Subject: [issue13918] locale.atof documentation is missing func argument
In-Reply-To: <1328105541.08.0.458455853203.issue13918@psf.upfronthosting.co.za>
Message-ID: <1328218590.83.0.968634001708.issue13918@psf.upfronthosting.co.za>


C?dric Krier <cedric.krier at b2ck.com> added the comment:

Indeed I find it useful to use to get a Decimal instead of a float.
So I was wondering if I can rely on it or not in my application?

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

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

From report at bugs.python.org  Thu Feb  2 22:56:44 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 02 Feb 2012 21:56:44 +0000
Subject: [issue13817] deadlock in subprocess while running several threads
	using Popen
In-Reply-To: <1326909636.44.0.892345276723.issue13817@psf.upfronthosting.co.za>
Message-ID: <1328219804.31.0.548340514096.issue13817@psf.upfronthosting.co.za>


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

Committed.

Christoph, thanks for the report.

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

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

From report at bugs.python.org  Thu Feb  2 23:03:16 2012
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 02 Feb 2012 22:03:16 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1328220196.14.0.80473853822.issue6210@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Latest version of PEP is on python-dev; here is the latest patch.

Summary:

For __cause__ we are replacing the old special value of None with Ellipsis:  Ellipsis means check __context__ for an exception to display; None means ignore __context__ and stop following exception chain; an exception means display this exception and stop following the exception chain.

----------
Added file: http://bugs.python.org/file24401/raise_from_none_v6.diff

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

From report at bugs.python.org  Thu Feb  2 23:07:20 2012
From: report at bugs.python.org (Ezra Berch)
Date: Thu, 02 Feb 2012 22:07:20 +0000
Subject: [issue13857] Add textwrap.indent() as counterpart to textwrap.dedent()
In-Reply-To: <1327462635.84.0.618726818638.issue13857@psf.upfronthosting.co.za>
Message-ID: <1328220440.61.0.258216671848.issue13857@psf.upfronthosting.co.za>


Ezra Berch <ezraberch at mac.com> added the comment:

Sorry, I guess I wasn't clear. The trailing-newlines issue was an issue with the conditional expression ncoghlan suggested. It's fixed in the patch I submitted (and covered by the tests).

----------

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

From report at bugs.python.org  Thu Feb  2 23:29:28 2012
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 02 Feb 2012 22:29:28 +0000
Subject: [issue13927] Extra spaces in the output of time.ctime
In-Reply-To: <1328215776.48.0.974828105123.issue13927@psf.upfronthosting.co.za>
Message-ID: <1328221768.76.0.642439616195.issue13927@psf.upfronthosting.co.za>


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

That's definitely the expected behavior. It's the same as the C library version of ctime().

But I couldn't find it documented in the Python docs, so I'm changing this to a documentation issue.

Thanks for the report.

----------
assignee:  -> docs at python
components: +Documentation -None
nosy: +docs at python, eric.smith
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Feb  2 23:54:23 2012
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 02 Feb 2012 22:54:23 +0000
Subject: [issue13926] pydoc - stall when requesting a list of available
	modules in the online help utility
In-Reply-To: <CA+0o7Qhzry+gjk3dwLqwtvckxKq=QpDeg-84po9Ve-fHsn-boQ@mail.gmail.com>
Message-ID: <1328223263.5.0.899407449776.issue13926@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Should calling "modules" automatically iterate over all submodules or should it return just a list of top level modules?

----------

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

From report at bugs.python.org  Fri Feb  3 00:17:35 2012
From: report at bugs.python.org (Phillip J. Eby)
Date: Thu, 02 Feb 2012 23:17:35 +0000
Subject: [issue13926] pydoc - stall when requesting a list of available
	modules in the online help utility
In-Reply-To: <1328223263.5.0.899407449776.issue13926@psf.upfronthosting.co.za>
Message-ID: <CALeMXf64tKownN2Ww=8-2scPbyp7fzbCL9c+kMJYkqBj+4YyZg@mail.gmail.com>


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

I don't have the code you're talking about in front of me; just wanted to
give you a lead on the likely cause.

----------

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

From report at bugs.python.org  Fri Feb  3 00:28:46 2012
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 02 Feb 2012 23:28:46 +0000
Subject: [issue13926] pydoc - stall when requesting a list of available
	modules in the online help utility
In-Reply-To: <CA+0o7Qhzry+gjk3dwLqwtvckxKq=QpDeg-84po9Ve-fHsn-boQ@mail.gmail.com>
Message-ID: <1328225326.27.0.797546131815.issue13926@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

You're right. The pkgutil.walk_packages method called from ModuleScanner seems to be importing the submodules. I should have said that in the last message.

I'll try to be clearer. What should the correct behavior be when entering "modules" in the interactive help system? This is an open question to anyone.

----------

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

From report at bugs.python.org  Fri Feb  3 01:07:47 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Feb 2012 00:07:47 +0000
Subject: [issue12902] help("modules") executes module code
In-Reply-To: <1315251083.43.0.259542197646.issue12902@psf.upfronthosting.co.za>
Message-ID: <1328227667.37.0.0410956204187.issue12902@psf.upfronthosting.co.za>


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

#13902 is essentially a duplicate of this and I may close it.
I am thinking now that executing unknown amounts of unknown code from unknown modules is a really bad idea. If a module just crashes the system, as happened with the OP of the above, there is no way to tell what the culprit is. So if we do not disable 'modules', I thing it should just read directory names and forget about docstrings. In any case, output should be flushed as available if not now.

----------

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

From report at bugs.python.org  Fri Feb  3 01:07:58 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Feb 2012 00:07:58 +0000
Subject: [issue13926] pydoc - stall when requesting a list of available
	modules in the online help utility
In-Reply-To: <CA+0o7Qhzry+gjk3dwLqwtvckxKq=QpDeg-84po9Ve-fHsn-boQ@mail.gmail.com>
Message-ID: <1328227678.28.0.480266017796.issue13926@psf.upfronthosting.co.za>


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

This issue is essentially a duplicate of #12092. For the OP there, the stall happens because something on Gnome pops up a configuration GUI and, I presume, waits for response. I am thinking now that 'modules' is simply a bad idea and should be removed or severely changed to only list and not execute. There is no telling *what* might be on the search path.

I noted there that there are two issues: documenting help() better, and changing the behavior of help('modules') and that there is least a behavior bug. I am only leaving this issue open because of the report of IDLE crashing - which does not happen on Win7, 3.2. I know nothing of how IDLE executes on *nix and whether there is anything that might be done to at least exit more gracefully.

We might make this the 'change code' issue, though if code is change, some of the proposed doc change will become obsolete.

----------
superseder:  -> Clarify sentence in tutorial

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

From report at bugs.python.org  Fri Feb  3 02:04:00 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Feb 2012 01:04:00 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328231040.15.0.935693758023.issue13882@psf.upfronthosting.co.za>


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

As expected, size_t is too small on Windows 32 bits.

Patch version 8: _PyTime_t uses Py_LONG_LONG if available, instead of size_t, for numerator and denominator.

----------
title: Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object -> PEP 410: Use decimal.Decimal type for timestamps
Added file: http://bugs.python.org/file24402/time_decimal-8.patch

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

From report at bugs.python.org  Fri Feb  3 02:04:16 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Feb 2012 01:04:16 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328231056.7.0.741924397345.issue13882@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file24372/time_decimal-5.patch

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

From report at bugs.python.org  Fri Feb  3 02:04:17 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Feb 2012 01:04:17 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328231057.97.0.336266594653.issue13882@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file24378/time_decimal-6.patch

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

From report at bugs.python.org  Fri Feb  3 02:04:19 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Feb 2012 01:04:19 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328231059.33.0.0910047206815.issue13882@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file24396/time_decimal-7.patch

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

From report at bugs.python.org  Fri Feb  3 02:04:59 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Feb 2012 01:04:59 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328231099.5.0.941091129495.issue13882@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file24402/time_decimal-8.patch

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

From report at bugs.python.org  Fri Feb  3 02:05:38 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Feb 2012 01:05:38 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328231138.07.0.868825460882.issue13882@psf.upfronthosting.co.za>


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

(Resend patch version 8 without the git diff format to support review on Rietveld.)

----------
Added file: http://bugs.python.org/file24403/time_decimal-8.patch

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

From report at bugs.python.org  Fri Feb  3 02:08:22 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Feb 2012 01:08:22 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328231302.72.0.0177046268566.issue13882@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file24403/time_decimal-8.patch

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

From report at bugs.python.org  Fri Feb  3 02:09:04 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Feb 2012 01:09:04 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328231344.65.0.838346123268.issue13882@psf.upfronthosting.co.za>


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

Oops, win32_pyclock() was disabled (for tests) in patch version 8. Fixed in version 9.

----------
Added file: http://bugs.python.org/file24404/time_decimal-9.patch

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

From report at bugs.python.org  Fri Feb  3 02:52:39 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 03 Feb 2012 01:52:39 +0000
Subject: [issue13901] test_get_outputs (test_distutils) failure with
	--enable-shared on Mac OS X
In-Reply-To: <1327826805.0.0.304314009246.issue13901@psf.upfronthosting.co.za>
Message-ID: <E1Rt8KI-0004Nj-Sp@dinsdale.python.org>


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

New changeset 41cabdff2686 by Ned Deily in branch '2.7':
Issue #13901: Prevent test_distutils failures on OS X with --enable-shared.
http://hg.python.org/cpython/rev/41cabdff2686

New changeset 6f6100a752ba by Ned Deily in branch '3.2':
Issue #13901: Prevent test_distutils failures on OS X with --enable-shared.
http://hg.python.org/cpython/rev/6f6100a752ba

New changeset 84be86af9161 by Ned Deily in branch 'default':
Issue #13901: Prevent test_packaging failures on OS X with --enable-shared.
http://hg.python.org/cpython/rev/84be86af9161

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

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

From report at bugs.python.org  Fri Feb  3 02:58:53 2012
From: report at bugs.python.org (Ned Deily)
Date: Fri, 03 Feb 2012 01:58:53 +0000
Subject: [issue13901] test_get_outputs (test_distutils) failure with
	--enable-shared on Mac OS X
In-Reply-To: <1327826805.0.0.304314009246.issue13901@psf.upfronthosting.co.za>
Message-ID: <1328234333.61.0.0228466882809.issue13901@psf.upfronthosting.co.za>


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

Modified support.py in test_distutils for 2.7 (for 2.7.3), 3.2 (for 3.2.3), and 3.3, as well as in test_packaging for 3.3, to skip shared library fixing for Mac OS X.

----------
assignee: tarek -> ned.deily
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Feb  3 03:10:06 2012
From: report at bugs.python.org (Eric Snow)
Date: Fri, 03 Feb 2012 02:10:06 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1328235006.46.0.976490578344.issue13405@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

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

From report at bugs.python.org  Fri Feb  3 04:59:59 2012
From: report at bugs.python.org (adamhj)
Date: Fri, 03 Feb 2012 03:59:59 +0000
Subject: [issue13928] bug in asyncore.dispatcher_with_send
Message-ID: <1328241599.62.0.482443622644.issue13928@psf.upfronthosting.co.za>


New submission from adamhj <adamhm at gmail.com>:

i found 2 relative bugs in asyncore.dispatcher_with_send class:

one is in the asyncore.dispatcher_with_send.writable():
    def writable(self):
        return (not self.connected) or len(self.out_buffer)
why is a not connected connection writable? i think this is definitely a bug
my fix:
    def writable(self):
        return self.connected and len(self.out_buffer)

another bug is more obscure, i'm not sure is it a bug or something should be handled by user(programmer)

the bug is also in asyncore.dispatcher_with_send class, and maybe also in asyncore.dispatcher class. asyncore.dispatcher uses unblocking socket to handle network missions, when we use the connect() method of dispatcher to establish the socket, it will call socket.connect_ex() method to create the connection, however, socket.connect_ex() may return 10035(EWOULDBLOCK) as it is an unblocking socket indicates that the connection creating is not finished yet, if we call dispatcher.connect() immediately after .connect(), socket error 10057 may be raised, indicating that the socket is not established yet, then the asyncore main loop catches this exception, and calls handle_error(in my case i close the connection in handle_error so the connection which would be established with no problem breaks), i think there should be a connection state check in asyncore.dispatcher.send(), or at least in asyncore.dispatcher_with_send.send.

my fix for asyncore.dispatcher_with_send.send():
    def send(self, data):
        if self.debug:
            self.log_info('sending %s' % repr(data))
        self.out_buffer = self.out_buffer + data
        if self.connected:        # do not call send() if connection is
            self.initiate_send()  # not established yet, just put data 
                                  # in buffer

for the second bug, to reproduce it, just create a unblocking socket to a remote, long delay port with socket.connect_ex and call send immediately

----------
components: Library (Lib)
messages: 152494
nosy: adamhj
priority: normal
severity: normal
status: open
title: bug in asyncore.dispatcher_with_send
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb  3 07:50:23 2012
From: report at bugs.python.org (Israel Fruchter)
Date: Fri, 03 Feb 2012 06:50:23 +0000
Subject: [issue13929] fnmatch to support escape characters
Message-ID: <1328251823.76.0.3651219427.issue13929@psf.upfronthosting.co.za>


New submission from Israel Fruchter <israel.fruchter at gmail.com>:

fnmatch to support escape characters:
like that:

>>> name = "Document[Ver.2].doc"
>>> pattern = "*\[Ver.2\]*"
>>> fnmatch.fnmatch(name, pattern)
True

that's also fix glob module:
>>> pattern = "ipconfig /\?"
>>> glob.glob(pattern)
"ipconfig /?"

----------
components: Library (Lib)
messages: 152495
nosy: fruch
priority: normal
severity: normal
status: open
title: fnmatch to support escape characters
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb  3 08:10:52 2012
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Feb 2012 07:10:52 +0000
Subject: [issue13927] Extra spaces in the output of time.ctime
In-Reply-To: <1328215776.48.0.974828105123.issue13927@psf.upfronthosting.co.za>
Message-ID: <1328253052.08.0.497945753054.issue13927@psf.upfronthosting.co.za>


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

asctime() docs say it's a 24 char string.

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

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

From report at bugs.python.org  Fri Feb  3 08:26:28 2012
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 03 Feb 2012 07:26:28 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1328253988.52.0.303144949275.issue6210@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

PEP 409 has been accepted.  :)

Attached is the latest patch implementing it, with the (hopefully ;) final changes.

Because Ellipsis is now the default value for __cause__, 'raise ... from Ellipsis' is treated the same as 'raise ...'

----------
Added file: http://bugs.python.org/file24405/raise_from_none_v7.diff

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

From report at bugs.python.org  Fri Feb  3 08:41:28 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 03 Feb 2012 07:41:28 +0000
Subject: [issue13930] lib2to3 ability to output files into a different
	directory and alter their names
Message-ID: <1328254888.57.0.86339015419.issue13930@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

In order for lib2to3 to be integrated into parts of our workflow at work we need it to be able to write converted code out to new directory and modify the filename in the process.  While doing that, it is very convenient if it can also write all files regardless of if refactoring caused any changes.

This patch adds those three features.

Uploading it to the bugtracker in hope of it showing up with a code review link.

----------
assignee: gregory.p.smith
components: 2to3 (2.x to 3.x conversion tool)
files: 2to3-output-to-new-dir-gps01.patch
hgrepos: 111
keywords: patch
messages: 152498
nosy: gregory.p.smith, twouters
priority: normal
severity: normal
stage: patch review
status: open
title: lib2to3 ability to output files into a different directory and alter their names
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24406/2to3-output-to-new-dir-gps01.patch

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

From report at bugs.python.org  Fri Feb  3 10:13:34 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 03 Feb 2012 09:13:34 +0000
Subject: [issue10811] sqlite segfault with generators
In-Reply-To: <1294018427.94.0.141740646278.issue10811@psf.upfronthosting.co.za>
Message-ID: <1328260414.24.0.737115596336.issue10811@psf.upfronthosting.co.za>


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

It seems to me that the fix still needs to be backported to 3.2 and 2.7.

----------
nosy: +petri.lehtinen
status: pending -> open
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Feb  3 10:17:34 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 03 Feb 2012 09:17:34 +0000
Subject: [issue13445] Enable linking the module pysqlite with Berkeley DB SQL
	instead of SQLite
In-Reply-To: <1321894515.42.0.740720237959.issue13445@psf.upfronthosting.co.za>
Message-ID: <1328260654.65.0.0876518474051.issue13445@psf.upfronthosting.co.za>


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

Is it possible to compile pysqlite so that it links with both, or so that the linking type can be changed at run time?

I'm -1 on adding a compile-time option to switch the storage backend to Python itself, but a runtime flag or a separate connection class for the sqlite3 module would do.

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

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

From report at bugs.python.org  Fri Feb  3 10:19:00 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 03 Feb 2012 09:19:00 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1328260740.63.0.980052196968.issue9750@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Feb  3 10:19:39 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 03 Feb 2012 09:19:39 +0000
Subject: [issue13299] namedtuple row factory for sqlite3
In-Reply-To: <1320021145.59.0.53370875256.issue13299@psf.upfronthosting.co.za>
Message-ID: <1328260779.88.0.0709535609349.issue13299@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Feb  3 11:41:06 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Feb 2012 10:41:06 +0000
Subject: [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1328202378.3418.6.camel@localhost.localdomain>
Message-ID: <20120203104103.GA21108@sleipnir.bytereef.org>


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

Antoine Pitrou <report at bugs.python.org> wrote:
> I'm sure some admins will prefer using their system's packages (I think
> buildbot is packaged for Debian/Ubuntu, I see it in Mageia's packages,
> not sure about Fedora).

Yes, certainly. I had a bad experience using the packaged buildbot-slave,
but I don't remember which distro it was.

Generally speaking, I've had so much trouble with rarely used packages
on multiple distros that I *always* compile or install that kind of
software directly from upstream.

> Anyway, the current instructions are on the wiki:
> http://wiki.python.org/moin/BuildBot

That's probably the best place.

Eric: I'm afraid the excerpts from the mailing list discussion you put
there are a bit confusing and don't reflect any kind of majority opinion.

For example I'm running two bots and I don't even know what this means:

"Some tests, as the start of this thread [...] indicates, must have some
 special logic to make sure they do or do not run, or run differently, in
 privileged vs. unprivileged configurations, but generally speaking most
 things should work in both places."

That does not concern a buildbot owner, since he has no influence on that.

Also, you included that nasty quote "executing arbitrarily horrible and/or
malicious code". I re-read the thread, and that quote is a half-sarcastic
concession from Glyph (who actually had a much lighter view on the whole
situation initially!) to the concerns of the people who were almost accusing
buildbot owners of being clueless.

The other side of the discussion (Martin's view) is missing completely,
despite the fact that most core developers *probably* share that view.

I'm sure you meant well, but I think we should give buildbot admins some
credit. Experienced admins don't need any advice, inexperienced admins
would be served better by a cookbook approach.

The script I posted is a start: All buildbot software is in /home/buildbot
and runs under the password-less user buildbot. In combination with a VM,
this is enough for me. If anyone thinks this is not secure enough and wants
to add chroot, jails, whatever, the best way forward is to post an improved
version.

----------

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

From report at bugs.python.org  Fri Feb  3 13:16:44 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Feb 2012 12:16:44 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1328231344.65.0.838346123268.issue13882@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYTQL3fSN5GAknQ1rURrzCaKpea3+=7uVY_Ev0oVQdd2g@mail.gmail.com>


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

Patch version 10:
 - deprecate os.stat_float_times()
 - fix docstring of os.*stat() functions
 - add a reference to the PEP
 - add a comment to indicate that _PyTime_gettimeofday() ignores
integer overflow

----------
Added file: http://bugs.python.org/file24407/time_decimal-10.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/os.rst b/Doc/library/os.rst
--- a/Doc/library/os.rst
+++ b/Doc/library/os.rst
@@ -808,13 +808,16 @@ as internal buffering of data.
    Availability: Unix.
 
 
-.. function:: fstat(fd)
+.. function:: fstat(fd, timestamp=None)
 
    Return status for file descriptor *fd*, like :func:`~os.stat`.
 
    Availability: Unix, Windows.
 
-.. function:: fstatat(dirfd, path, flags=0)
+   .. versionchanged:: 3.3
+      Added the *timestamp* argument.
+
+.. function:: fstatat(dirfd, path, flags=0, timestamp="float")
 
    Like :func:`stat` but if *path* is relative, it is taken as relative to *dirfd*.
    *flags* is optional and may be 0 or :data:`AT_SYMLINK_NOFOLLOW`.
@@ -1696,7 +1699,7 @@ Files and Directories
    .. versionadded:: 3.3
 
 
-.. function:: lstat(path)
+.. function:: lstat(path, timestamp=None)
 
    Perform the equivalent of an :c:func:`lstat` system call on the given path.
    Similar to :func:`~os.stat`, but does not follow symbolic links.  On
@@ -1706,6 +1709,9 @@ Files and Directories
    .. versionchanged:: 3.2
       Added support for Windows 6.0 (Vista) symbolic links.
 
+   .. versionchanged:: 3.3
+      The *timestamp* argument was added.
+
 
 .. function:: lutimes(path[, times])
 
@@ -1969,7 +1975,7 @@ Files and Directories
    .. versionadded:: 3.3
 
 
-.. function:: stat(path)
+.. function:: stat(path, timestamp=None)
 
    Perform the equivalent of a :c:func:`stat` system call on the given path.
    (This function follows symlinks; to stat a symlink use :func:`lstat`.)
@@ -1989,6 +1995,11 @@ Files and Directories
    * :attr:`st_ctime` - platform dependent; time of most recent metadata change on
      Unix, or the time of creation on Windows)
 
+   :attr:`st_atime`, :attr:`st_mtime` and :attr:`st_ctime` are :class:`float`
+   by default, or :class:`int` if :func:`os.stat_float_times` is ``False``. Set
+   the *timestamp* argument to get another :ref:`timestamp type
+   <timestamp-types>`.
+
    On some Unix systems (such as Linux), the following attributes may also be
    available:
 
@@ -2044,6 +2055,9 @@ Files and Directories
 
    Availability: Unix, Windows.
 
+   .. versionchanged:: 3.3
+      Added the *timestamp* argument.
+
 
 .. function:: stat_float_times([newvalue])
 
@@ -2069,6 +2083,9 @@ Files and Directories
    are processed, this application should turn the feature off until the library
    has been corrected.
 
+   .. deprecated:: 3.3
+      Use *timestamp* argument of stat functions instead.
+
 
 .. function:: statvfs(path)
 
diff --git a/Doc/library/time.rst b/Doc/library/time.rst
--- a/Doc/library/time.rst
+++ b/Doc/library/time.rst
@@ -95,6 +95,14 @@ An explanation of some terminology and c
   | local time              |                         |                         |
   +-------------------------+-------------------------+-------------------------+
 
+.. _timestamp-types:
+
+* Python supports the following timestamp types:
+
+  * :class:`int`
+  * :class:`float`
+  * :class:`decimal.Decimal`
+
 
 The module defines the following functions and data items:
 
@@ -119,7 +127,7 @@ The module defines the following functio
       trailing newline.
 
 
-.. function:: clock()
+.. function:: clock(timestamp=float)
 
    .. index::
       single: CPU time
@@ -136,16 +144,27 @@ The module defines the following functio
    :c:func:`QueryPerformanceCounter`. The resolution is typically better than one
    microsecond.
 
+   Return as a floating point number by default, set the *timestamp* argument
+   to get another :ref:`timestamp type <timestamp-types>`.
 
-.. function:: clock_getres(clk_id)
+   .. versionchanged:: 3.3
+      Added the *timestamp* argument.
+
+
+.. function:: clock_getres(clk_id, timestamp=float)
 
    Return the resolution (precision) of the specified clock *clk_id*.
+   Return a floating point number by default, set the *timestamp* argument to
+   get another :ref:`timestamp type <timestamp-types>`.
+
 
    .. versionadded:: 3.3
 
-.. function:: clock_gettime(clk_id)
+.. function:: clock_gettime(clk_id, timestamp=float)
 
    Return the time of the specified clock *clk_id*.
+   Return a floating point number by default, set the *timestamp* argument to
+   get another :ref:`timestamp type <timestamp-types>`.
 
    .. versionadded:: 3.3
 
@@ -214,12 +233,15 @@ The module defines the following functio
    flag is set to ``1`` when DST applies to the given time.
 
 
-.. function:: mktime(t)
+.. function:: mktime(t, timestamp=float)
 
    This is the inverse function of :func:`localtime`.  Its argument is the
    :class:`struct_time` or full 9-tuple (since the dst flag is needed; use ``-1``
    as the dst flag if it is unknown) which expresses the time in *local* time, not
-   UTC.  It returns a floating point number, for compatibility with :func:`time`.
+   It returns a floating point number by default, for compatibility with
+   :func:`time`, set the *timestamp* argument to get another :ref:`timestamp
+   type <timestamp-types>`.
+
    If the input value cannot be represented as a valid time, either
    :exc:`OverflowError` or :exc:`ValueError` will be raised (which depends on
    whether the invalid value is caught by Python or the underlying C libraries).
@@ -432,15 +454,20 @@ The module defines the following functio
    :exc:`TypeError` is raised.
 
 
-.. function:: time()
+.. function:: time(timestamp=float)
 
-   Return the time as a floating point number expressed in seconds since the epoch,
-   in UTC.  Note that even though the time is always returned as a floating point
+   Return the time expressed in seconds since the epoch in UTC. Return a
+   floating point number by default, set the *timestamp* argument to get
+   another :ref:`timestamp type <timestamp-types>`.
+   Note that even though the time is always returned as a floating point
    number, not all systems provide time with a better precision than 1 second.
    While this function normally returns non-decreasing values, it can return a
    lower value than a previous call if the system clock has been set back between
    the two calls.
 
+   .. versionchanged:: 3.3
+      Added the *timestamp* argument.
+
 
 .. data:: timezone
 
@@ -538,13 +565,16 @@ The module defines the following functio
       ('EET', 'EEST')
 
 
-.. function:: wallclock()
+.. function:: wallclock(timestamp=float)
 
    .. index::
       single: Wallclock
       single: benchmarking
 
    Return the current time in fractions of a second to the system's best ability.
+   Return a floating point number by default, set the *timestamp* argument to
+   get another :ref:`timestamp type <timestamp-types>`.
+
    Use this when the most accurate representation of wall-clock is required, i.e.
    when "processor time" is inappropriate.  The reference point of the returned
    value is undefined so only the difference of consecutive calls is valid.
diff --git a/Doc/whatsnew/3.3.rst b/Doc/whatsnew/3.3.rst
--- a/Doc/whatsnew/3.3.rst
+++ b/Doc/whatsnew/3.3.rst
@@ -270,6 +270,38 @@ new, more precise information::
    '<function C.D.meth at 0x7f46b9fe31e0>'
 
 
+PEP 410: Use decimal.Decimal type for timestamps
+================================================
+
+:pep:`410` - Use decimal.Decimal type for timestamps
+ PEP written and implemented by Victor Stinner.
+
+The following functions have a new optional *timestamp* argument to get a
+timestamp as a :class:`decimal.Decimal` instead of :class:`int` or
+:class:`float`:
+
+ * :mod:`time` module: :func:`~time.clock`, :func:`~time.clock_gettime`,
+   :func:`~time.clock_getres`, :func:`~time.time` and :func:`~time.wallclock`
+ * :mod:`os` module: :func:`~os.fstat`, :func:`~os.fstatat`, :func:`~os.lstat`
+   and :func:`~os.stat` (``st_atime``, ``st_ctime`` and ``st_mtime`` fields of
+   the stat structure)
+
+:class:`decimal.Decimal` supports a resolution of a nanosecond (10^-9)
+resolution, whereas :class:`float` has only a resolution of a microsecond
+(10^-6) in common cases. See the list of available :ref:`timestamp types
+<timestamp-types>`.
+
+Example::
+
+    >>> import decimal, time
+    >>> time.time()
+    1328006975.681211
+    >>> time.time(timestamp=int)
+    1328006979
+    >>> time.time(timestamp=decimal.Decimal)
+    Decimal('1328006983.761119')
+
+
 Other Language Changes
 ======================
 
diff --git a/Include/pytime.h b/Include/pytime.h
--- a/Include/pytime.h
+++ b/Include/pytime.h
@@ -2,7 +2,8 @@
 #ifndef Py_PYTIME_H
 #define Py_PYTIME_H
 
-#include "pyconfig.h" /* include for defines */
+#include "pyport.h"
+#include "object.h"
 
 /**************************************************************************
 Symbols and macros to supply platform-independent interfaces to time related
@@ -37,6 +38,31 @@ do { \
     ((tv_end.tv_sec - tv_start.tv_sec) + \
      (tv_end.tv_usec - tv_start.tv_usec) * 0.000001)
 
+#if defined(HAVE_LONG_LONG)
+typedef unsigned PY_LONG_LONG _PyTime_fraction_t;
+#else
+typedef size_t _PyTime_fraction_t;
+#endif
+
+typedef struct
+{
+    /* timestamp = seconds + numerator / denominator */
+    time_t seconds;
+    _PyTime_fraction_t numerator;
+    /* denominator cannot be zero */
+    _PyTime_fraction_t denominator;
+    /* the timestamp resolution is 1/divisor */
+} _PyTime_t;
+
+/* Similar to POSIX gettimeofday.  If system gettimeofday
+   fails or is not available, fall back to lower resolution clocks.  */
+PyAPI_FUNC(void) _PyTime_get(_PyTime_t *tp);
+
+/* Convert a timestamp structure to the specified timestamp type.
+
+   Raise a ValueError if the timestamp type is unknown. */
+PyAPI_FUNC(PyObject*) _PyTime_Convert(_PyTime_t *ts, PyObject *timestamp);
+
 /* Dummy to force linking. */
 PyAPI_FUNC(void) _PyTime_Init(void);
 
diff --git a/Lib/test/test_os.py b/Lib/test/test_os.py
--- a/Lib/test/test_os.py
+++ b/Lib/test/test_os.py
@@ -2,24 +2,25 @@
 # does add tests for a few functions which have been determined to be more
 # portable than they had been thought to be.
 
+import asynchat
+import asyncore
+import contextlib
+import decimal
+import errno
+import mmap
 import os
-import errno
-import unittest
-import warnings
-import sys
-import signal
-import subprocess
-import time
-import shutil
-from test import support
-import contextlib
-import mmap
 import platform
 import re
+import shutil
+import signal
+import socket
+import subprocess
+import sys
+from test import support
+import time
+import unittest
 import uuid
-import asyncore
-import asynchat
-import socket
+import warnings
 try:
     import threading
 except ImportError:
@@ -229,6 +230,37 @@ class StatAttributeTests(unittest.TestCa
             warnings.simplefilter("ignore", DeprecationWarning)
             self.check_stat_attributes(fname)
 
+    def test_stat_timestamp(self):
+        # test deprecation
+        with warnings.catch_warnings():
+            warnings.simplefilter("error", DeprecationWarning)
+            self.assertRaises(DeprecationWarning, os.stat_float_times, False)
+            print("la")
+
+        with warnings.catch_warnings():
+            warnings.simplefilter("ignore", DeprecationWarning)
+            old_value = os.stat_float_times()
+            try:
+                # test invalid timestamp types
+                self.assertRaises(ValueError, os.stat, self.fname,
+                                  timestamp="abc")
+                self.assertRaises(ValueError, os.stat, self.fname,
+                                  timestamp=decimal.Context)
+
+                for float_times in (False, True):
+                    os.stat_float_times(float_times)
+                    t = os.stat(self.fname).st_mtime
+                    if float_times:
+                        self.assertIsInstance(t, float)
+                    else:
+                        self.assertIsInstance(t, int)
+
+                    for type in (int, float, decimal.Decimal):
+                        t = os.stat(self.fname, timestamp=type).st_mtime
+                        self.assertIsInstance(t, type)
+            finally:
+                os.stat_float_times(old_value)
+
     def test_statvfs_attributes(self):
         if not hasattr(os, "statvfs"):
             return
diff --git a/Lib/test/test_time.py b/Lib/test/test_time.py
--- a/Lib/test/test_time.py
+++ b/Lib/test/test_time.py
@@ -1,10 +1,10 @@
+import locale
+import platform
+import sys
+import sysconfig
 from test import support
 import time
 import unittest
-import locale
-import sysconfig
-import sys
-import platform
 
 # Max year is only limited by the size of C int.
 SIZEOF_INT = sysconfig.get_config_var('SIZEOF_INT') or 4
@@ -331,6 +331,29 @@ class TimeTestCase(unittest.TestCase):
             pass
         self.assertEqual(time.strftime('%Z', tt), tzname)
 
+    def test_timestamp(self):
+        import decimal
+        calls = [
+            (time.time,),
+            (time.mktime, time.localtime()),
+        ]
+        if hasattr(time, 'wallclock'):
+            calls.append((time.wallclock,))
+        if hasattr(time, 'CLOCK_REALTIME'):
+            if hasattr(time, 'clock_gettime'):
+                calls.append((time.clock_gettime, time.CLOCK_REALTIME))
+            if hasattr(time, 'clock_getres'):
+                calls.append((time.clock_getres, time.CLOCK_REALTIME))
+        for call in calls:
+            func, *args = call
+
+            # test invalid timestamp
+            for invalid in ("int", decimal.Context):
+                self.assertRaises(ValueError, func, *args, timestamp=invalid)
+
+            for type in (int, float, decimal.Decimal):
+                self.assertIsInstance(func(*args, timestamp=type), type)
+
     def test_wallclock(self):
         t1 = time.wallclock()
         t2 = time.wallclock()
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -1699,6 +1699,12 @@ stat_float_times(PyObject* self, PyObjec
     int newval = -1;
     if (!PyArg_ParseTuple(args, "|i:stat_float_times", &newval))
         return NULL;
+    if (PyErr_WarnEx(PyExc_DeprecationWarning,
+                     "os.stat_float_times() has been deprecated, "
+                     "use timestamp argument of os.stat() instead",
+                     1))
+        return NULL;
+
     if (newval == -1)
         /* Return old value */
         return PyBool_FromLong(_stat_float_times);
@@ -1708,9 +1714,12 @@ stat_float_times(PyObject* self, PyObjec
 }
 
 static void
-fill_time(PyObject *v, int index, time_t sec, unsigned long nsec)
+fill_time(PyObject *v, int index, time_t sec, unsigned long nsec,
+          PyObject *timestamp)
 {
     PyObject *fval,*ival;
+    _PyTime_t ts;
+
 #if SIZEOF_TIME_T > SIZEOF_LONG
     ival = PyLong_FromLongLong((PY_LONG_LONG)sec);
 #else
@@ -1718,9 +1727,15 @@ fill_time(PyObject *v, int index, time_t
 #endif
     if (!ival)
         return;
-    if (_stat_float_times) {
-        fval = PyFloat_FromDouble(sec + 1e-9*nsec);
-    } else {
+    if (timestamp == NULL && _stat_float_times)
+        timestamp = (PyObject*)&PyFloat_Type;
+    if (timestamp != NULL) {
+        ts.seconds = sec;
+        ts.numerator = nsec;
+        ts.denominator = 1000000000;
+        fval = _PyTime_Convert(&ts, timestamp);
+    }
+    else {
         fval = ival;
         Py_INCREF(fval);
     }
@@ -1731,7 +1746,7 @@ fill_time(PyObject *v, int index, time_t
 /* pack a system stat C structure into the Python stat tuple
    (used by posix_stat() and posix_fstat()) */
 static PyObject*
-_pystat_fromstructstat(STRUCT_STAT *st)
+_pystat_fromstructstat(STRUCT_STAT *st, PyObject *timestamp)
 {
     unsigned long ansec, mnsec, cnsec;
     PyObject *v = PyStructSequence_New(&StatResultType);
@@ -1776,9 +1791,9 @@ _pystat_fromstructstat(STRUCT_STAT *st)
 #else
     ansec = mnsec = cnsec = 0;
 #endif
-    fill_time(v, 7, st->st_atime, ansec);
-    fill_time(v, 8, st->st_mtime, mnsec);
-    fill_time(v, 9, st->st_ctime, cnsec);
+    fill_time(v, 7, st->st_atime, ansec, timestamp);
+    fill_time(v, 8, st->st_mtime, mnsec, timestamp);
+    fill_time(v, 9, st->st_ctime, cnsec, timestamp);
 
 #ifdef HAVE_STRUCT_STAT_ST_BLKSIZE
     PyStructSequence_SET_ITEM(v, ST_BLKSIZE_IDX,
@@ -1829,7 +1844,7 @@ _pystat_fromstructstat(STRUCT_STAT *st)
 }
 
 static PyObject *
-posix_do_stat(PyObject *self, PyObject *args,
+posix_do_stat(PyObject *self, PyObject *args, PyObject *kw,
               char *format,
 #ifdef __VMS
               int (*statfunc)(const char *, STRUCT_STAT *, ...),
@@ -1839,15 +1854,18 @@ posix_do_stat(PyObject *self, PyObject *
               char *wformat,
               int (*wstatfunc)(const wchar_t *, STRUCT_STAT *))
 {
+    static char *kwlist[] = {"path", "timestamp", NULL};
     STRUCT_STAT st;
     PyObject *opath;
     char *path;
     int res;
     PyObject *result;
+    PyObject *timestamp = NULL;
 
 #ifdef MS_WINDOWS
     PyObject *po;
-    if (PyArg_ParseTuple(args, wformat, &po)) {
+    if (PyArg_ParseTupleAndKeywords(args, kw, wformat, kwlist,
+                                    &po, &timestamp)) {
         wchar_t *wpath = PyUnicode_AsUnicode(po);
         if (wpath == NULL)
             return NULL;
@@ -1858,15 +1876,17 @@ posix_do_stat(PyObject *self, PyObject *
 
         if (res != 0)
             return win32_error_object("stat", po);
-        return _pystat_fromstructstat(&st);
+        return _pystat_fromstructstat(&st, timestamp);
     }
     /* Drop the argument parsing error as narrow strings
        are also valid. */
     PyErr_Clear();
-#endif
-
-    if (!PyArg_ParseTuple(args, format,
-                          PyUnicode_FSConverter, &opath))
+    timestamp = NULL;
+#endif
+
+    if (!PyArg_ParseTupleAndKeywords(args, kw, format, kwlist,
+                                     PyUnicode_FSConverter, &opath,
+                                     &timestamp))
         return NULL;
 #ifdef MS_WINDOWS
     if (win32_warn_bytes_api()) {
@@ -1887,7 +1907,7 @@ posix_do_stat(PyObject *self, PyObject *
 #endif
     }
     else
-        result = _pystat_fromstructstat(&st);
+        result = _pystat_fromstructstat(&st, timestamp);
 
     Py_DECREF(opath);
     return result;
@@ -3378,16 +3398,16 @@ posix_rmdir(PyObject *self, PyObject *ar
 
 
 PyDoc_STRVAR(posix_stat__doc__,
-"stat(path) -> stat result\n\n\
+"stat(path, timestamp=None) -> stat result\n\n\
 Perform a stat system call on the given path.");
 
 static PyObject *
-posix_stat(PyObject *self, PyObject *args)
+posix_stat(PyObject *self, PyObject *args, PyObject *kw)
 {
 #ifdef MS_WINDOWS
-    return posix_do_stat(self, args, "O&:stat", STAT, "U:stat", win32_stat_w);
+    return posix_do_stat(self, args, kw, "O&|O:stat", STAT, "U:stat", win32_stat_w);
 #else
-    return posix_do_stat(self, args, "O&:stat", STAT, NULL, NULL);
+    return posix_do_stat(self, args, kw, "O&|O:stat", STAT, NULL, NULL);
 #endif
 }
 
@@ -6383,20 +6403,20 @@ posix_wait(PyObject *self, PyObject *noa
 
 
 PyDoc_STRVAR(posix_lstat__doc__,
-"lstat(path) -> stat result\n\n\
+"lstat(path, timestamp=None) -> stat result\n\n\
 Like stat(path), but do not follow symbolic links.");
 
 static PyObject *
-posix_lstat(PyObject *self, PyObject *args)
+posix_lstat(PyObject *self, PyObject *args, PyObject *kw)
 {
 #ifdef HAVE_LSTAT
-    return posix_do_stat(self, args, "O&:lstat", lstat, NULL, NULL);
+    return posix_do_stat(self, args, kw, "O&|O:lstat", lstat, NULL, NULL);
 #else /* !HAVE_LSTAT */
 #ifdef MS_WINDOWS
-    return posix_do_stat(self, args, "O&:lstat", win32_lstat, "U:lstat",
+    return posix_do_stat(self, args, kw, "O&|O:lstat", win32_lstat, "U|O:lstat",
                          win32_lstat_w);
 #else
-    return posix_do_stat(self, args, "O&:lstat", STAT, NULL, NULL);
+    return posix_do_stat(self, args, "kw, O&|O:lstat", STAT, NULL, NULL);
 #endif
 #endif /* !HAVE_LSTAT */
 }
@@ -7355,16 +7375,19 @@ done:
 #endif
 
 PyDoc_STRVAR(posix_fstat__doc__,
-"fstat(fd) -> stat result\n\n\
+"fstat(fd, timestamp=None) -> stat result\n\n\
 Like stat(), but for an open file descriptor.");
 
 static PyObject *
-posix_fstat(PyObject *self, PyObject *args)
-{
+posix_fstat(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+    static char *kwlist[] = {"fd", "timestamp", NULL};
     int fd;
     STRUCT_STAT st;
     int res;
-    if (!PyArg_ParseTuple(args, "i:fstat", &fd))
+    PyObject *timestamp = NULL;
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "i|O:fstat", kwlist,
+                                     &fd, &timestamp))
         return NULL;
 #ifdef __VMS
     /* on OpenVMS we must ensure that all bytes are written to the file */
@@ -7383,7 +7406,7 @@ posix_fstat(PyObject *self, PyObject *ar
 #endif
     }
 
-    return _pystat_fromstructstat(&st);
+    return _pystat_fromstructstat(&st, timestamp);
 }
 
 PyDoc_STRVAR(posix_isatty__doc__,
@@ -9667,22 +9690,25 @@ posix_fchownat(PyObject *self, PyObject 
 
 #ifdef HAVE_FSTATAT
 PyDoc_STRVAR(posix_fstatat__doc__,
-"fstatat(dirfd, path, flags=0) -> stat result\n\n\
+"fstatat(dirfd, path, flags=0, timestamp=None) -> stat result\n\n\
 Like stat() but if path is relative, it is taken as relative to dirfd.\n\
 flags is optional and may be 0 or AT_SYMLINK_NOFOLLOW.\n\
 If path is relative and dirfd is the special value AT_FDCWD, then path\n\
 is interpreted relative to the current working directory.");
 
 static PyObject *
-posix_fstatat(PyObject *self, PyObject *args)
-{
+posix_fstatat(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+    static char *kwlist[] = {"dirfd", "path", "flags", "timestamp", NULL};
     PyObject *opath;
     char *path;
     STRUCT_STAT st;
     int dirfd, res, flags = 0;
-
-    if (!PyArg_ParseTuple(args, "iO&|i:fstatat",
-            &dirfd, PyUnicode_FSConverter, &opath, &flags))
+    PyObject *timestamp = NULL;
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "iO&|iO:fstatat", kwlist,
+                                     &dirfd, PyUnicode_FSConverter, &opath,
+                                     &flags, &timestamp))
         return NULL;
     path = PyBytes_AsString(opath);
 
@@ -9693,7 +9719,7 @@ posix_fstatat(PyObject *self, PyObject *
     if (res != 0)
         return posix_error();
 
-    return _pystat_fromstructstat(&st);
+    return _pystat_fromstructstat(&st, timestamp);
 }
 #endif
 
@@ -10557,7 +10583,7 @@ static PyMethodDef posix_methods[] = {
 #ifdef HAVE_FDOPENDIR
     {"fdlistdir",       posix_fdlistdir, METH_VARARGS, posix_fdlistdir__doc__},
 #endif
-    {"lstat",           posix_lstat, METH_VARARGS, posix_lstat__doc__},
+    {"lstat",           (PyCFunction)posix_lstat, METH_VARARGS | METH_KEYWORDS, posix_lstat__doc__},
     {"mkdir",           posix_mkdir, METH_VARARGS, posix_mkdir__doc__},
 #ifdef HAVE_NICE
     {"nice",            posix_nice, METH_VARARGS, posix_nice__doc__},
@@ -10577,7 +10603,7 @@ static PyMethodDef posix_methods[] = {
     {"rename",          posix_rename, METH_VARARGS, posix_rename__doc__},
     {"replace",         posix_replace, METH_VARARGS, posix_replace__doc__},
     {"rmdir",           posix_rmdir, METH_VARARGS, posix_rmdir__doc__},
-    {"stat",            posix_stat, METH_VARARGS, posix_stat__doc__},
+    {"stat",            (PyCFunction)posix_stat, METH_VARARGS | METH_KEYWORDS, posix_stat__doc__},
     {"stat_float_times", stat_float_times, METH_VARARGS, stat_float_times__doc__},
 #if defined(HAVE_SYMLINK) && !defined(MS_WINDOWS)
     {"symlink",         posix_symlink, METH_VARARGS, posix_symlink__doc__},
@@ -10792,7 +10818,8 @@ static PyMethodDef posix_methods[] = {
     {"sendfile",        (PyCFunction)posix_sendfile, METH_VARARGS | METH_KEYWORDS,
                             posix_sendfile__doc__},
 #endif
-    {"fstat",           posix_fstat, METH_VARARGS, posix_fstat__doc__},
+    {"fstat",           (PyCFunction)posix_fstat, METH_VARARGS | METH_KEYWORDS,
+                            posix_fstat__doc__},
     {"isatty",          posix_isatty, METH_VARARGS, posix_isatty__doc__},
 #ifdef HAVE_PIPE
     {"pipe",            posix_pipe, METH_NOARGS, posix_pipe__doc__},
@@ -10927,7 +10954,8 @@ static PyMethodDef posix_methods[] = {
     {"fchownat",        posix_fchownat, METH_VARARGS, posix_fchownat__doc__},
 #endif /* HAVE_FCHOWNAT */
 #ifdef HAVE_FSTATAT
-    {"fstatat",         posix_fstatat, METH_VARARGS, posix_fstatat__doc__},
+    {"fstatat",         (PyCFunction)posix_fstatat, METH_VARARGS | METH_KEYWORDS,
+                            posix_fstatat__doc__},
 #endif
 #ifdef HAVE_FUTIMESAT
     {"futimesat",       posix_futimesat, METH_VARARGS, posix_futimesat__doc__},
diff --git a/Modules/timemodule.c b/Modules/timemodule.c
--- a/Modules/timemodule.c
+++ b/Modules/timemodule.c
@@ -40,24 +40,30 @@
 #include <sys/time.h>
 #endif
 
+#if (defined(MS_WINDOWS) && !defined(__BORLANDC__)) || defined(HAVE_CLOCK)
+#  define HAVE_PYCLOCK
+#endif
+
 /* Forward declarations */
 static int floatsleep(double);
-static double floattime(void);
 
 static PyObject *
-time_time(PyObject *self, PyObject *unused)
+time_time(PyObject *self, PyObject *args, PyObject *kwargs)
 {
-    double secs;
-    secs = floattime();
-    if (secs == 0.0) {
-        PyErr_SetFromErrno(PyExc_IOError);
+    static char *kwlist[] = {"timestamp", NULL};
+    PyObject *timestamp = NULL;
+    _PyTime_t ts;
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "|O:time", kwlist,
+                                     &timestamp))
         return NULL;
-    }
-    return PyFloat_FromDouble(secs);
+
+    _PyTime_get(&ts);
+    return _PyTime_Convert(&ts, timestamp);
 }
 
 PyDoc_STRVAR(time_doc,
-"time() -> floating point number\n\
+"time(timestamp=float) -> floating point number\n\
 \n\
 Return the current time in seconds since the Epoch.\n\
 Fractions of a second may be present if the system clock provides them.");
@@ -72,60 +78,88 @@ Fractions of a second may be present if 
 #endif
 #endif
 
-static PyObject *
-pyclock(void)
+static int
+pyclock(_PyTime_t *ts)
 {
-    clock_t value;
-    value = clock();
-    if (value == (clock_t)-1) {
+    clock_t processor_time;
+    processor_time = clock();
+    if (processor_time == (clock_t)-1) {
         PyErr_SetString(PyExc_RuntimeError,
                 "the processor time used is not available "
                 "or its value cannot be represented");
-        return NULL;
+        return -1;
     }
-    return PyFloat_FromDouble((double)value / CLOCKS_PER_SEC);
+    ts->seconds = 0;
+    assert(sizeof(clock_t) <= sizeof(_PyTime_fraction_t));
+    ts->numerator = Py_SAFE_DOWNCAST(processor_time,
+                                     clock_t, _PyTime_fraction_t);
+    ts->denominator = CLOCKS_PER_SEC;
+    return 0;
 }
 #endif /* HAVE_CLOCK */
 
 #if defined(MS_WINDOWS) && !defined(__BORLANDC__)
 /* Win32 has better clock replacement; we have our own version, due to Mark
    Hammond and Tim Peters */
-static PyObject *
-time_clock(PyObject *self, PyObject *unused)
+static int
+win32_pyclock(_PyTime_t *ts)
 {
     static LARGE_INTEGER ctrStart;
-    static double divisor = 0.0;
+    static LONGLONG cpu_frequency = 0;
     LARGE_INTEGER now;
-    double diff;
+    LONGLONG dt;
 
-    if (divisor == 0.0) {
+    if (cpu_frequency == 0) {
         LARGE_INTEGER freq;
         QueryPerformanceCounter(&ctrStart);
-        if (!QueryPerformanceFrequency(&freq) || freq.QuadPart == 0) {
+        if (!QueryPerformanceFrequency(&freq) || freq.QuadPart == 0)
+        {
             /* Unlikely to happen - this works on all intel
                machines at least!  Revert to clock() */
-            return pyclock();
+            return pyclock(ts);
         }
-        divisor = (double)freq.QuadPart;
+        cpu_frequency = freq.QuadPart;
     }
     QueryPerformanceCounter(&now);
-    diff = (double)(now.QuadPart - ctrStart.QuadPart);
-    return PyFloat_FromDouble(diff / divisor);
+    dt = now.QuadPart - ctrStart.QuadPart;
+
+    ts->seconds = 0;
+    assert(sizeof(LONGLONG) <= sizeof(_PyTime_fraction_t));
+    ts->numerator = Py_SAFE_DOWNCAST(dt,
+                                     LONGLONG, _PyTime_fraction_t);
+    ts->denominator = Py_SAFE_DOWNCAST(cpu_frequency,
+                                       LONGLONG, _PyTime_fraction_t);
+    return 0;
 }
+#endif
 
-#elif defined(HAVE_CLOCK)
+#ifdef HAVE_PYCLOCK
+static PyObject *
+time_clock(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+    static char *kwlist[] = {"timestamp", NULL};
+    _PyTime_t ts;
+    PyObject *timestamp = NULL;
 
-static PyObject *
-time_clock(PyObject *self, PyObject *unused)
-{
-    return pyclock();
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "|O:clock", kwlist,
+                                     &timestamp))
+        return NULL;
+
+#if defined(MS_WINDOWS) && !defined(__BORLANDC__)
+    if (win32_pyclock(&ts))
+        return NULL;
+#else
+    if (pyclock(&ts))
+        return NULL;
+#endif
+    return _PyTime_Convert(&ts, timestamp);
 }
-#endif /* HAVE_CLOCK */
+#endif
 
 
 #ifdef HAVE_CLOCK
 PyDoc_STRVAR(clock_doc,
-"clock() -> floating point number\n\
+"clock(timestamp=float) -> floating point number\n\
 \n\
 Return the CPU time or real time since the start of the process or since\n\
 the first call to clock().  This has as much precision as the system\n\
@@ -134,13 +168,17 @@ records.");
 
 #ifdef HAVE_CLOCK_GETTIME
 static PyObject *
-time_clock_gettime(PyObject *self, PyObject *args)
+time_clock_gettime(PyObject *self, PyObject *args, PyObject *kwargs)
 {
+    static char *kwlist[] = {"clk_id", "timestamp", NULL};
+    PyObject *timestamp = NULL;
     int ret;
     clockid_t clk_id;
     struct timespec tp;
+    _PyTime_t ts;
 
-    if (!PyArg_ParseTuple(args, "i:clock_gettime", &clk_id))
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "i|O:clock_gettime", kwlist,
+                                     &clk_id, &timestamp))
         return NULL;
 
     ret = clock_gettime((clockid_t)clk_id, &tp);
@@ -148,25 +186,31 @@ time_clock_gettime(PyObject *self, PyObj
         PyErr_SetFromErrno(PyExc_IOError);
         return NULL;
     }
-
-    return PyFloat_FromDouble(tp.tv_sec + tp.tv_nsec * 1e-9);
+    ts.seconds = tp.tv_sec;
+    ts.numerator = tp.tv_nsec;
+    ts.denominator = 1000000000;
+    return _PyTime_Convert(&ts, timestamp);
 }
 
 PyDoc_STRVAR(clock_gettime_doc,
-"clock_gettime(clk_id) -> floating point number\n\
+"clock_gettime(clk_id, timestamp=float) -> floating point number\n\
 \n\
 Return the time of the specified clock clk_id.");
 #endif
 
 #ifdef HAVE_CLOCK_GETRES
 static PyObject *
-time_clock_getres(PyObject *self, PyObject *args)
+time_clock_getres(PyObject *self, PyObject *args, PyObject *kwargs)
 {
+    static char *kwlist[] = {"clk_id", "timestamp", NULL};
+    PyObject *timestamp = NULL;
     int ret;
     clockid_t clk_id;
     struct timespec tp;
+    _PyTime_t ts;
 
-    if (!PyArg_ParseTuple(args, "i:clock_getres", &clk_id))
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "i|O:clock_getres", kwlist,
+                                     &clk_id, &timestamp))
         return NULL;
 
     ret = clock_getres((clockid_t)clk_id, &tp);
@@ -174,12 +218,14 @@ time_clock_getres(PyObject *self, PyObje
         PyErr_SetFromErrno(PyExc_IOError);
         return NULL;
     }
-
-    return PyFloat_FromDouble(tp.tv_sec + tp.tv_nsec * 1e-9);
+    ts.seconds = tp.tv_sec;
+    ts.numerator = tp.tv_nsec;
+    ts.denominator = 1000000000;
+    return _PyTime_Convert(&ts, timestamp);
 }
 
 PyDoc_STRVAR(clock_getres_doc,
-"clock_getres(clk_id) -> floating point number\n\
+"clock_getres(clk_id, timestamp=float) -> floating point number\n\
 \n\
 Return the resolution (precision) of the specified clock clk_id.");
 #endif
@@ -702,10 +748,19 @@ not present, current time as returned by
 
 #ifdef HAVE_MKTIME
 static PyObject *
-time_mktime(PyObject *self, PyObject *tup)
+time_mktime(PyObject *self, PyObject *args, PyObject *kwargs)
 {
+    static char *kwlist[] = {"t", "timestamp", NULL};
+    PyObject *tup;
+    PyObject *timestamp = NULL;
     struct tm buf;
     time_t tt;
+    _PyTime_t ts;
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O|O:mktime", kwlist,
+                                     &tup, &timestamp))
+        return NULL;
+
     if (!gettmarg(tup, &buf))
         return NULL;
     buf.tm_wday = -1;  /* sentinel; original value ignored */
@@ -717,7 +772,10 @@ time_mktime(PyObject *self, PyObject *tu
                         "mktime argument out of range");
         return NULL;
     }
-    return PyFloat_FromDouble((double)tt);
+    ts.seconds = tt;
+    ts.numerator = 0;
+    ts.denominator = 1;
+    return _PyTime_Convert(&ts, timestamp);
 }
 
 PyDoc_STRVAR(mktime_doc,
@@ -763,12 +821,14 @@ the local timezone used by methods such 
 should not be relied on.");
 #endif /* HAVE_WORKING_TZSET */
 
-static PyObject *
-time_wallclock(PyObject *self, PyObject *unused)
+static int
+pywallclock(_PyTime_t *ts)
 {
 #if defined(MS_WINDOWS) && !defined(__BORLANDC__)
-    return time_clock(self, NULL);
-#elif defined(HAVE_CLOCK_GETTIME) && defined(CLOCK_MONOTONIC)
+    return win32_pyclock(ts);
+#else
+
+#if defined(HAVE_CLOCK_GETTIME) && defined(CLOCK_MONOTONIC)
     static int clk_index = 0;
     clockid_t clk_ids[] = {
 #ifdef CLOCK_MONOTONIC_RAW
@@ -788,20 +848,40 @@ time_wallclock(PyObject *self, PyObject 
         clockid_t clk_id = clk_ids[clk_index];
         ret = clock_gettime(clk_id, &tp);
         if (ret == 0)
-            return PyFloat_FromDouble(tp.tv_sec + tp.tv_nsec * 1e-9);
+        {
+            ts->seconds = tp.tv_sec;
+            ts->numerator = tp.tv_nsec;
+            ts->denominator = 1000000000;
+            return 0;
+        }
 
         clk_index++;
         if (Py_ARRAY_LENGTH(clk_ids) <= clk_index)
             clk_index = -1;
     }
-    return time_time(self, NULL);
-#else
-    return time_time(self, NULL);
+#endif /* defined(HAVE_CLOCK_GETTIME) && defined(CLOCK_MONOTONIC) */
+    _PyTime_get(ts);
+    return 0;
 #endif
 }
 
+static PyObject *
+time_wallclock(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+    static char *kwlist[] = {"timestamp", NULL};
+    PyObject *timestamp = NULL;
+    _PyTime_t ts;
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "|O:wallclock", kwlist,
+                                     &timestamp))
+        return NULL;
+    if (pywallclock(&ts))
+        return NULL;
+    return _PyTime_Convert(&ts, timestamp);
+}
+
 PyDoc_STRVAR(wallclock_doc,
-"wallclock() -> float\n\
+"wallclock(timestamp=float)\n\
 \n\
 Return the current time in fractions of a second to the system's best\n\
 ability. Use this when the most accurate representation of wall-clock is\n\
@@ -919,15 +999,19 @@ PyInit_timezone(PyObject *m) {
 
 
 static PyMethodDef time_methods[] = {
-    {"time",            time_time, METH_NOARGS, time_doc},
-#if (defined(MS_WINDOWS) && !defined(__BORLANDC__)) || defined(HAVE_CLOCK)
-    {"clock",           time_clock, METH_NOARGS, clock_doc},
+    {"time",            (PyCFunction)time_time,
+                        METH_VARARGS | METH_KEYWORDS, time_doc},
+#ifdef HAVE_PYCLOCK
+    {"clock",           (PyCFunction)time_clock,
+                        METH_VARARGS | METH_KEYWORDS, clock_doc},
 #endif
 #ifdef HAVE_CLOCK_GETTIME
-    {"clock_gettime",   time_clock_gettime, METH_VARARGS, clock_gettime_doc},
+    {"clock_gettime",   (PyCFunction)time_clock_gettime,
+                        METH_VARARGS | METH_KEYWORDS, clock_gettime_doc},
 #endif
 #ifdef HAVE_CLOCK_GETRES
-    {"clock_getres",    time_clock_getres, METH_VARARGS, clock_getres_doc},
+    {"clock_getres",    (PyCFunction)time_clock_getres,
+                        METH_VARARGS | METH_KEYWORDS, clock_getres_doc},
 #endif
     {"sleep",           time_sleep, METH_VARARGS, sleep_doc},
     {"gmtime",          time_gmtime, METH_VARARGS, gmtime_doc},
@@ -935,7 +1019,8 @@ static PyMethodDef time_methods[] = {
     {"asctime",         time_asctime, METH_VARARGS, asctime_doc},
     {"ctime",           time_ctime, METH_VARARGS, ctime_doc},
 #ifdef HAVE_MKTIME
-    {"mktime",          time_mktime, METH_O, mktime_doc},
+    {"mktime",          (PyCFunction)time_mktime,
+                        METH_VARARGS | METH_KEYWORDS, mktime_doc},
 #endif
 #ifdef HAVE_STRFTIME
     {"strftime",        time_strftime, METH_VARARGS, strftime_doc},
@@ -944,7 +1029,8 @@ static PyMethodDef time_methods[] = {
 #ifdef HAVE_WORKING_TZSET
     {"tzset",           time_tzset, METH_NOARGS, tzset_doc},
 #endif
-    {"wallclock",       time_wallclock, METH_NOARGS, wallclock_doc},
+    {"wallclock",       (PyCFunction)time_wallclock,
+                        METH_VARARGS | METH_KEYWORDS, wallclock_doc},
     {NULL,              NULL}           /* sentinel */
 };
 
@@ -1029,15 +1115,6 @@ PyInit_time(void)
     return m;
 }
 
-static double
-floattime(void)
-{
-    _PyTime_timeval t;
-    _PyTime_gettimeofday(&t);
-    return (double)t.tv_sec + t.tv_usec*0.000001;
-}
-
-
 /* Implement floatsleep() for various platforms.
    When interrupted (or when another error occurs), return -1 and
    set an exception; else return 0. */
diff --git a/Python/pytime.c b/Python/pytime.c
--- a/Python/pytime.c
+++ b/Python/pytime.c
@@ -19,8 +19,10 @@ extern int ftime(struct timeb *);
 #endif /* MS_WINDOWS */
 #endif /* HAVE_FTIME */
 
+#define MICROSECONDS    1000000
+
 void
-_PyTime_gettimeofday(_PyTime_timeval *tp)
+_PyTime_get(_PyTime_t *ts)
 {
     /* There are three ways to get the time:
       (1) gettimeofday() -- resolution in microseconds
@@ -30,27 +32,331 @@ _PyTime_gettimeofday(_PyTime_timeval *tp
       Since on some systems (e.g. SCO ODT 3.0) gettimeofday() may
       fail, so we fall back on ftime() or time().
       Note: clock resolution does not imply clock accuracy! */
+
+#ifdef HAVE_GETTIMEOFDAY
+    struct timeval tv;
+    int err;
+#endif
+#if defined(HAVE_FTIME)
+    struct timeb t;
+#endif
+
 #ifdef HAVE_GETTIMEOFDAY
 #ifdef GETTIMEOFDAY_NO_TZ
-    if (gettimeofday(tp) == 0)
+    err = gettimeofday(&tv);
+#else /* !GETTIMEOFDAY_NO_TZ */
+    err = gettimeofday(&tv, (struct timezone *)NULL);
+#endif /* !GETTIMEOFDAY_NO_TZ */
+    if (err == 0)
+    {
+        ts->seconds = tv.tv_sec;
+        ts->numerator = tv.tv_usec;
+        ts->denominator = MICROSECONDS;
         return;
-#else /* !GETTIMEOFDAY_NO_TZ */
-    if (gettimeofday(tp, (struct timezone *)NULL) == 0)
-        return;
-#endif /* !GETTIMEOFDAY_NO_TZ */
+    }
 #endif /* !HAVE_GETTIMEOFDAY */
+
 #if defined(HAVE_FTIME)
+    ftime(&t);
+    ts->seconds = t.time;
+    ts->numerator = t.millitm;
+    ts->denominator = 1000;
+#else /* !HAVE_FTIME */
+    ts->seconds = time(NULL);
+    ts->numerator = 0;
+    ts->denominator = 1;
+#endif /* !HAVE_FTIME */
+}
+
+void
+_PyTime_gettimeofday(_PyTime_timeval *tv)
+{
+    _PyTime_t ts;
+    _PyTime_fraction_t k;
+    time_t sec;
+
+    _PyTime_get(&ts);
+    tv->tv_sec = ts.seconds;
+    if (ts.numerator) {
+        if (ts.numerator > ts.denominator) {
+            sec = Py_SAFE_DOWNCAST(ts.numerator / ts.denominator,
+                                   _PyTime_fraction_t, time_t);
+            /* ignore integer overflow because _PyTime_gettimeofday() has
+               no return value */
+            tv->tv_sec += sec;
+            ts.numerator = ts.numerator % ts.denominator;
+        }
+        if (MICROSECONDS >= ts.denominator) {
+            k = (_PyTime_fraction_t)MICROSECONDS / ts.denominator;
+            tv->tv_usec = (long)(ts.numerator * k);
+        }
+        else {
+            k = ts.denominator / (_PyTime_fraction_t)MICROSECONDS;
+            tv->tv_usec = (long)(ts.numerator / k);
+        }
+    }
+    else {
+        tv->tv_usec = 0;
+    }
+}
+
+static PyObject*
+_PyLong_FromTime_t(time_t value)
+{
+#if SIZEOF_TIME_T <= SIZEOF_LONG
+    return PyLong_FromLong(value);
+#else
+    assert(sizeof(time_t) <= sizeof(PY_LONG_LONG));
+    return PyLong_FromLongLong(value);
+#endif
+}
+
+#if defined(HAVE_LONG_LONG)
+#  define _PyLong_FromTimeFraction_t PyLong_FromLongLong
+#else
+#  define _PyLong_FromTimeFraction_t PyLong_FromSize_t
+#endif
+
+/* Convert a timestamp to a PyFloat object */
+static PyObject*
+_PyTime_AsFloat(_PyTime_t *ts)
+{
+    double d;
+    d = (double)ts->seconds;
+    d += (double)ts->numerator / (double)ts->denominator;
+    return PyFloat_FromDouble(d);
+}
+
+/* Convert a timestamp to a PyLong object */
+static PyObject*
+_PyTime_AsLong(_PyTime_t *ts)
+{
+    PyObject *a, *b, *c;
+
+    a = _PyLong_FromTime_t(ts->seconds);
+    if (a == NULL)
+        return NULL;
+    b = _PyLong_FromTimeFraction_t(ts->numerator / ts->denominator);
+    if (b == NULL)
     {
-        struct timeb t;
-        ftime(&t);
-        tp->tv_sec = t.time;
-        tp->tv_usec = t.millitm * 1000;
+        Py_DECREF(a);
+        return NULL;
     }
-#else /* !HAVE_FTIME */
-    tp->tv_sec = time(NULL);
-    tp->tv_usec = 0;
-#endif /* !HAVE_FTIME */
-    return;
+    c = PyNumber_Add(a, b);
+    Py_DECREF(a);
+    Py_DECREF(b);
+    return c;
+}
+
+/* Convert a timestamp to a decimal.Decimal object */
+static PyObject*
+_PyTime_AsDecimal(_PyTime_t *ts)
+{
+    static PyObject* module = NULL;
+    static PyObject* decimal = NULL;
+    static PyObject* exponent_context = NULL;
+    static PyObject* context = NULL;
+    /* exponent cache, dictionary of:
+       int (denominator) => Decimal (1/denominator) */
+    static PyObject* exponent_cache = NULL;
+    PyObject *t = NULL;
+    PyObject *key, *exponent, *quantized;
+    _Py_IDENTIFIER(quantize);
+    _Py_IDENTIFIER(__truediv__);
+
+    if (!module) {
+        module = PyImport_ImportModuleNoBlock("decimal");
+        if (module == NULL)
+            return NULL;
+    }
+
+    if (!decimal) {
+        decimal = PyObject_GetAttrString(module, "Decimal");
+        if (decimal == NULL)
+            return NULL;
+    }
+
+    if (context == NULL)
+    {
+        /* Use 12 decimal digits to store 10,000 years in seconds + 9
+           decimal digits for the floating part in nanoseconds + 1 decimal
+           digit to round correctly.
+
+           context = decimal.Context(22, rounding=decimal.ROUND_HALF_EVEN)
+           exponent_context = decimal.Context(1, rounding=decimal.ROUND_HALF_EVEN)
+        */
+        PyObject *context_class, *rounding;
+        context_class = PyObject_GetAttrString(module, "Context");
+        if (context_class == NULL)
+            return NULL;
+        rounding = PyObject_GetAttrString(module, "ROUND_HALF_EVEN");
+        if (rounding == NULL)
+        {
+            Py_DECREF(context_class);
+            return NULL;
+        }
+        context = PyObject_CallFunction(context_class, "iO", 22, rounding);
+        if (context == NULL)
+        {
+            Py_DECREF(context_class);
+            Py_DECREF(rounding);
+            return NULL;
+        }
+
+        exponent_context = PyObject_CallFunction(context_class, "iO", 1, rounding);
+        Py_DECREF(context_class);
+        Py_DECREF(rounding);
+        if (exponent_context == NULL)
+        {
+            Py_CLEAR(context);
+            return NULL;
+        }
+    }
+
+    /* t = decimal.Decimal(value) */
+    if (ts->seconds) {
+        PyObject *f = _PyLong_FromTime_t(ts->seconds);
+        t = PyObject_CallFunction(decimal, "O", f);
+        Py_CLEAR(f);
+    }
+    else {
+        t = PyObject_CallFunction(decimal, "iO", 0, context);
+    }
+    if (t == NULL)
+        return NULL;
+
+    if (ts->numerator)
+    {
+        /* t += decimal.Decimal(numerator, ctx) / decimal.Decimal(denominator, ctx) */
+        PyObject *a, *b, *c, *d, *x;
+
+        x = _PyLong_FromTimeFraction_t(ts->numerator);
+        if (x == NULL)
+            goto error;
+        a = PyObject_CallFunction(decimal, "OO", x, context);
+        Py_CLEAR(x);
+        if (a == NULL)
+            goto error;
+
+        x = _PyLong_FromTimeFraction_t(ts->denominator);
+        if (x == NULL)
+        {
+            Py_DECREF(a);
+            goto error;
+        }
+        b = PyObject_CallFunction(decimal, "OO", x, context);
+        Py_CLEAR(x);
+        if (b == NULL)
+        {
+            Py_DECREF(a);
+            goto error;
+        }
+
+        c = _PyObject_CallMethodId(a, &PyId___truediv__, "OO",
+                                   b, context);
+        Py_DECREF(a);
+        Py_DECREF(b);
+        if (c == NULL)
+            goto error;
+
+        d = PyNumber_Add(t, c);
+        Py_DECREF(c);
+        if (d == NULL)
+            goto error;
+        Py_DECREF(t);
+        t = d;
+    }
+
+    if (exponent_cache == NULL) {
+        exponent_cache = PyDict_New();
+        if (exponent_cache == NULL)
+            goto error;
+    }
+
+    key = _PyLong_FromTimeFraction_t(ts->denominator);
+    if (key == NULL)
+        goto error;
+    exponent = PyDict_GetItem(exponent_cache, key);
+    if (exponent == NULL) {
+        /* exponent = decimal.Decimal(1) / decimal.Decimal(resolution) */
+        PyObject *one, *denominator;
+
+        one = PyObject_CallFunction(decimal, "i", 1);
+        if (one == NULL) {
+            Py_DECREF(key);
+            goto error;
+        }
+
+        denominator = PyObject_CallFunction(decimal, "O", key);
+        if (denominator == NULL) {
+            Py_DECREF(key);
+            Py_DECREF(one);
+            goto error;
+        }
+
+        exponent = _PyObject_CallMethodId(one, &PyId___truediv__, "OO",
+                                          denominator, exponent_context);
+        Py_DECREF(one);
+        Py_DECREF(denominator);
+        if (exponent == NULL) {
+            Py_DECREF(key);
+            goto error;
+        }
+
+        if (PyDict_SetItem(exponent_cache, key, exponent) < 0) {
+            Py_DECREF(key);
+            Py_DECREF(exponent);
+            goto error;
+        }
+        Py_DECREF(key);
+    }
+
+    /* t = t.quantize(exponent, None, context) */
+    quantized = _PyObject_CallMethodId(t, &PyId_quantize, "OOO",
+                                       exponent, Py_None, context);
+    if (quantized == NULL)
+        goto error;
+    Py_DECREF(t);
+    t = quantized;
+
+    return t;
+
+error:
+    Py_XDECREF(t);
+    return NULL;
+}
+
+PyObject*
+_PyTime_Convert(_PyTime_t *ts, PyObject *format)
+{
+    assert(ts->denominator != 0);
+
+    if (format == NULL || (PyTypeObject *)format == &PyFloat_Type)
+        return _PyTime_AsFloat(ts);
+    if ((PyTypeObject *)format == &PyLong_Type)
+        return _PyTime_AsLong(ts);
+
+    if (PyType_Check(format))
+    {
+        PyObject *module, *name;
+        _Py_IDENTIFIER(__name__);
+        _Py_IDENTIFIER(__module__);
+
+        module = _PyObject_GetAttrId(format, &PyId___module__);
+        name = _PyObject_GetAttrId(format, &PyId___name__);
+        if (module != NULL && PyUnicode_Check(module)
+            && name != NULL && PyUnicode_Check(name))
+        {
+            if (PyUnicode_CompareWithASCIIString(module, "decimal") == 0
+                && PyUnicode_CompareWithASCIIString(name, "Decimal") == 0)
+                return _PyTime_AsDecimal(ts);
+        }
+        else
+            PyErr_Clear();
+    }
+
+    PyErr_Format(PyExc_ValueError, "Unknown timestamp format: %R", format);
+    return NULL;
 }
 
 void

From report at bugs.python.org  Fri Feb  3 14:18:10 2012
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 03 Feb 2012 13:18:10 +0000
Subject: [issue13928] bug in asyncore.dispatcher_with_send
In-Reply-To: <1328241599.62.0.482443622644.issue13928@psf.upfronthosting.co.za>
Message-ID: <1328275090.46.0.532785822047.issue13928@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> why is a not connected connection writable? 

A non connected socket must be writable in order to connect.

> if we call dispatcher.connect() immediately after .connect(), 
> socket error 10057 may be raised, 

Not sure what you mean here. Why would you call connect() twice?

----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Fri Feb  3 14:26:51 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 13:26:51 +0000
Subject: [issue13892] distutils handling of windows manifest isn't optimal
In-Reply-To: <1327698565.84.0.667656042788.issue13892@psf.upfronthosting.co.za>
Message-ID: <1328275611.04.0.822431608096.issue13892@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Feb  3 14:36:41 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 13:36:41 +0000
Subject: [issue13763] Potentially hard to understand wording in devguide
In-Reply-To: <1326278487.37.0.199929224509.issue13763@psf.upfronthosting.co.za>
Message-ID: <1328276201.36.0.705986707535.issue13763@psf.upfronthosting.co.za>


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

I like the result, thanks!

----------

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

From report at bugs.python.org  Fri Feb  3 14:40:06 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 13:40:06 +0000
Subject: [issue13846] Add time.monotonic() function
In-Reply-To: <1327364549.64.0.960699645726.issue13846@psf.upfronthosting.co.za>
Message-ID: <1328276406.16.0.20009373138.issue13846@psf.upfronthosting.co.za>


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

I don?t understand why this new function would be useful.  Time-related modules in Python are already complicated.

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

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

From report at bugs.python.org  Fri Feb  3 14:41:39 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 13:41:39 +0000
Subject: [issue13850] Summary tables for argparse add_argument options
In-Reply-To: <1327384498.23.0.981832544617.issue13850@psf.upfronthosting.co.za>
Message-ID: <1328276499.15.0.466151003352.issue13850@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/issue13850>
_______________________________________

From report at bugs.python.org  Fri Feb  3 14:43:52 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 13:43:52 +0000
Subject: [issue13851] Packaging distutils2 for Fedora
In-Reply-To: <1327409259.69.0.346795065424.issue13851@psf.upfronthosting.co.za>
Message-ID: <1328276632.51.0.737960087302.issue13851@psf.upfronthosting.co.za>


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


----------
resolution:  -> invalid
stage:  -> committed/rejected

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

From report at bugs.python.org  Fri Feb  3 14:46:44 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Feb 2012 13:46:44 +0000
Subject: [issue13846] Add time.monotonic() function
In-Reply-To: <1327364549.64.0.960699645726.issue13846@psf.upfronthosting.co.za>
Message-ID: <1328276804.66.0.310405783323.issue13846@psf.upfronthosting.co.za>


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

If you are trying to time something (an interval), having the time go backward can really screw up your data.  And that *will* happen on a system that is running NTP (or even just resets its time).  monotonic clocks were introduced at the OS level for a reason, and it seems reasonable for Python to expose them (when the are available) like it does other system resources.

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

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

From report at bugs.python.org  Fri Feb  3 14:47:12 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 13:47:12 +0000
Subject: [issue13861] test_pydoc failure
In-Reply-To: <1327517017.59.0.678002352905.issue13861@psf.upfronthosting.co.za>
Message-ID: <1328276832.69.0.171538388828.issue13861@psf.upfronthosting.co.za>


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

I have the same one on Debian testing:

======================================================================
FAIL: test_apropos_with_bad_package (test.test_pydoc.PydocImportTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test/test_pydoc.py", line 403, in test_apropos_with_bad_package
    self.assertEqual(b'', result)
AssertionError: b'' != b'docutils.parsers.null - A do-nothing parser.\ndocutils.writers.null - A do-nothing Writer.'

======================================================================
FAIL: test_apropos_with_unreadable_dir (test.test_pydoc.PydocImportTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test/test_pydoc.py", line 413, in test_apropos_with_unreadable_dir
    self.assertEqual(b'', result)
AssertionError: b'' != b'docutils.parsers.null - A do-nothing parser.\ndocutils.writers.null - A do-nothing Writer.'


docutils is the first package that?s found in my user site-packages; can you tell if your Crypto package is in that same location?

----------
nosy: +eric.araujo
versions: +Python 3.2

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

From report at bugs.python.org  Fri Feb  3 14:48:48 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 13:48:48 +0000
Subject: [issue13865] distutils documentation says Extension has "optional"
	argument
In-Reply-To: <1327525493.46.0.373823292504.issue13865@psf.upfronthosting.co.za>
Message-ID: <1328276928.16.0.934665613779.issue13865@psf.upfronthosting.co.za>


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

It was me who ported that doc change from 3.2, but distutils in 2.7 does not provide that feature.  Thanks for catching it, I?ll revert the commit when I get the chance.

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

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

From report at bugs.python.org  Fri Feb  3 14:49:01 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 13:49:01 +0000
Subject: [issue13865] distutils documentation says Extension has "optional"
	argument
In-Reply-To: <1327525493.46.0.373823292504.issue13865@psf.upfronthosting.co.za>
Message-ID: <1328276941.21.0.545549965342.issue13865@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> eric.araujo

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

From report at bugs.python.org  Fri Feb  3 14:49:25 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 13:49:25 +0000
Subject: [issue13866] {urllib,
	urllib.parse}.urlencode should not use quote_plus
In-Reply-To: <1327529522.13.0.464287316871.issue13866@psf.upfronthosting.co.za>
Message-ID: <1328276965.47.0.798674099082.issue13866@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/issue13866>
_______________________________________

From report at bugs.python.org  Fri Feb  3 14:51:41 2012
From: report at bugs.python.org (Samuel Iseli)
Date: Fri, 03 Feb 2012 13:51:41 +0000
Subject: [issue13889] str(float) and round(float) issues with FPU precision
In-Reply-To: <1327676303.66.0.487112802864.issue13889@psf.upfronthosting.co.za>
Message-ID: <1328277101.06.0.344991852847.issue13889@psf.upfronthosting.co.za>


Samuel Iseli <samuel.iseli at gmail.com> added the comment:

I would definitely classify this as a bug in Python 2.7 as it breaks backwards-compatibility for embedding environments that default to 64bit FPU precision (e.g. Delphi).

Additionally the bug is very hard to detect and leads to wrong values with possibly disastrous effects.

Appended a patch with a new implementation of the Py_SET_53BIT_PRECISION_* macros for win32:

- precision is set only when needed
- setting and restoring only the x87 controlword (using __control87_2
  function).
- macros are not used for WIN64 as there's no x87 there
- there's no need for a custom symbol in the vc project anymore, 
  as I'm using the predefined _WIN32 symbol.

----------
Added file: http://bugs.python.org/file24408/74745.patch

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

From report at bugs.python.org  Fri Feb  3 14:54:42 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 13:54:42 +0000
Subject: [issue13875] cmd: no user documentation
In-Reply-To: <1327588077.77.0.0954132482021.issue13875@psf.upfronthosting.co.za>
Message-ID: <1328277282.53.0.871675858088.issue13875@psf.upfronthosting.co.za>


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

+1 to expanding the introduction.  Do you have a phrasing suggestion?

> MOTW links are a more global issue that was discussion on python-dev (I forget the outcome,
> but I think it was "no").
IIRC it was on python-ideas, and (among other criticisms about licensing, site reliability, etc.) the strongest opinion against adding links was Alexander?s, who reviewed the PyMOTW page for datetime and was not satisfied.  So the discussion ruled out systematic addition of links for all modules, but I think that as usual a core dev is free to add a link to an external resource if they think it is useful.

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

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

From report at bugs.python.org  Fri Feb  3 14:55:13 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 13:55:13 +0000
Subject: [issue13875] Improve description of cmd module
In-Reply-To: <1327588077.77.0.0954132482021.issue13875@psf.upfronthosting.co.za>
Message-ID: <1328277313.95.0.183697588455.issue13875@psf.upfronthosting.co.za>


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


----------
resolution: works for me -> 
stage:  -> needs patch
title: cmd: no user documentation -> Improve description of cmd module

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

From report at bugs.python.org  Fri Feb  3 14:58:21 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 13:58:21 +0000
Subject: [issue13605] document argparse's nargs=REMAINDER
In-Reply-To: <1323955710.42.0.753468095058.issue13605@psf.upfronthosting.co.za>
Message-ID: <1328277501.08.0.776584551838.issue13605@psf.upfronthosting.co.za>


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

It would be best if the 3.x docs did not use a print statement <wink>.  The code block should also be preceded by ::.

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

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

From report at bugs.python.org  Fri Feb  3 14:58:59 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 13:58:59 +0000
Subject: [issue13879] Argparse does not support subparser aliases in 2.7
In-Reply-To: <1327597168.42.0.828007379667.issue13879@psf.upfronthosting.co.za>
Message-ID: <1328277539.11.0.0919353619301.issue13879@psf.upfronthosting.co.za>


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

Agreed, this looks like a doc glitch.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, eric.araujo, ezio.melotti

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

From report at bugs.python.org  Fri Feb  3 15:09:52 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 14:09:52 +0000
Subject: [issue13833] No documentation for PyStructSequence
In-Reply-To: <1327010174.09.0.407534369688.issue13833@psf.upfronthosting.co.za>
Message-ID: <1328278192.19.0.0475313787821.issue13833@psf.upfronthosting.co.za>


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


----------
nosy: +eric.araujo
stage:  -> patch review
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Feb  3 15:12:06 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 14:12:06 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1328278326.18.0.659652715169.issue1625@psf.upfronthosting.co.za>


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

As the bug/feature judgment is not easy to make, I think python-dev should be asked.

----------

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

From report at bugs.python.org  Fri Feb  3 15:12:30 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 14:12:30 +0000
Subject: [issue13846] Add time.monotonic() function
In-Reply-To: <1327364549.64.0.960699645726.issue13846@psf.upfronthosting.co.za>
Message-ID: <1328278350.59.0.997533494966.issue13846@psf.upfronthosting.co.za>


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

Thanks, now I see the usefulness.

----------

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

From report at bugs.python.org  Fri Feb  3 15:13:23 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 14:13:23 +0000
Subject: [issue13799] Base 16 should be hexadecimal in Unicode HOWTO
In-Reply-To: <1326718246.49.0.980962494093.issue13799@psf.upfronthosting.co.za>
Message-ID: <1328278403.42.0.359634925784.issue13799@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/issue13799>
_______________________________________

From report at bugs.python.org  Fri Feb  3 15:15:40 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 14:15:40 +0000
Subject: [issue13770] python3 & json: add ensure_ascii documentation
In-Reply-To: <1326300131.17.0.750918490995.issue13770@psf.upfronthosting.co.za>
Message-ID: <1328278540.51.0.222500604329.issue13770@psf.upfronthosting.co.za>


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

FTR I?ve fixed this and now need to find a place with SSH access so I can push.

----------

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

From report at bugs.python.org  Fri Feb  3 15:16:23 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 14:16:23 +0000
Subject: [issue2945] bdist_rpm does not list dist files (should effect upload)
In-Reply-To: <1211466871.95.0.658180804984.issue2945@psf.upfronthosting.co.za>
Message-ID: <1328278583.24.0.294135487977.issue2945@psf.upfronthosting.co.za>


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

FYI I have committed the patch to my repo and will push as soon as I can.

----------
assignee: tarek -> eric.araujo

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

From report at bugs.python.org  Fri Feb  3 15:21:37 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 14:21:37 +0000
Subject: [issue13815] tarfile.ExFileObject can't be wrapped using
	io.TextIOWrapper
In-Reply-To: <1326892577.13.0.456815776311.issue13815@psf.upfronthosting.co.za>
Message-ID: <1328278897.76.0.568558008557.issue13815@psf.upfronthosting.co.za>


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

Please always use explicit roles in reST, i.e. :meth:`flush` instead of `flush` (use ``flush`` when you don?t want a ton of identical links).

In the test, using assertEqual instead of assertTrue will certainly give more useful output in case of failure.

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

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

From report at bugs.python.org  Fri Feb  3 15:32:58 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 14:32:58 +0000
Subject: [issue13824] argparse.FileType opens a file and never closes it
In-Reply-To: <1326975939.94.0.524131708506.issue13824@psf.upfronthosting.co.za>
Message-ID: <1328279578.82.0.551680442696.issue13824@psf.upfronthosting.co.za>


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

> Additionally, there is no way to prevent FileType from clobbering an existing file
> when used with write mode.
I think this deserves its own feature request: now that Python 3.3 has an ?exclusive create? mode, argparse.FileType could gain support for it.  Would you open that request?

> Given these issues and others,
We have one issue and one missing feature; what are the other issues?

> it seems to me that the usefulness of FileType is outweighed by propensity to encourage bad
> coding.
I think the problem is not as bad as you paint it.  A great number of unclosed file handles may cause problem to some OSes, but that?s it.  On the plus side, the fact that argparse accepts for its type argument any callable that can check and convert a string input is simple, clean and works.  FileType is needed.

In packaging/distutils2 for example we have similar functions that return an open file object and never close it: the responsibility is at a higher level.  Other packaging code calling these functions does so in a with statement.  It is not evil by nature.

The problem here is that FileType may return stdin or stdout, so we can?t just always close the file object (or maybe we can, say using an atexit handler?).

> Perhaps, it would be best if FileType (or some replacement) simply checked that the file exists
But then you?d run into race conditions.  The only sure was to say if a file can be opened is to open it.

----------
nosy: +eric.araujo
title: argparse.FileType opens a file without excepting resposibility for closing it -> argparse.FileType opens a file and never closes it

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

From report at bugs.python.org  Fri Feb  3 15:35:00 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 14:35:00 +0000
Subject: [issue13826] Having a shlex example in the subprocess.Popen docs is
	confusing
In-Reply-To: <1326983115.48.0.551767400168.issue13826@psf.upfronthosting.co.za>
Message-ID: <1328279700.73.0.27210184466.issue13826@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/issue13826>
_______________________________________

From report at bugs.python.org  Fri Feb  3 15:37:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 14:37:07 +0000
Subject: [issue13830] codecs error handler is called with a UnicodeDecodeError
	with the same args
In-Reply-To: <1327002997.43.0.435824061039.issue13830@psf.upfronthosting.co.za>
Message-ID: <1328279827.49.0.794598965.issue13830@psf.upfronthosting.co.za>


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


----------
nosy: +haypo, lemburg

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

From report at bugs.python.org  Fri Feb  3 15:37:43 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 14:37:43 +0000
Subject: [issue13824] argparse.FileType opens a file and never closes it
In-Reply-To: <1326975939.94.0.524131708506.issue13824@psf.upfronthosting.co.za>
Message-ID: <1328279863.46.0.0636535662554.issue13824@psf.upfronthosting.co.za>


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

s/sure was/sure way/

----------

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

From report at bugs.python.org  Fri Feb  3 15:41:18 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 14:41:18 +0000
Subject: [issue13771] HTTPSConnection __init__ super implementation causes
	recursion error
In-Reply-To: <1326304391.56.0.972578337686.issue13771@psf.upfronthosting.co.za>
Message-ID: <1328280078.83.0.426348131078.issue13771@psf.upfronthosting.co.za>


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

Hi,

> wsgi_intercept has overridden http.client.HTTPSConnection with a class that subclasses
> HTTPSConnection and overrides a few methonds.
Do you mean that the module is monkey-patched?

> Fix the issue in http/client.py:1074 by replacing "super(HTTPSConnection, self)" with
> "super()", which if I'm not mistaken is the recommended usage of super in Python 3.
Because it?s possible does not mean it?s liked :)  Some of us still dislike that hack.

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

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

From report at bugs.python.org  Fri Feb  3 15:45:19 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 14:45:19 +0000
Subject: [issue13773] Support sqlite3 uri filenames
In-Reply-To: <1326313998.63.0.583537561643.issue13773@psf.upfronthosting.co.za>
Message-ID: <1328280319.36.0.124411238238.issue13773@psf.upfronthosting.co.za>


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

> Should I also rewrap modified lines that were already much too long?
Please don?t, it would make the diff harder to read.

> I also noticed & fixed an unrelated typo in Lib/sqlite3/test/hooks.py...
Can you open a bug report for that?

I think the doc could link to the sqlite.org doc about URIs.

----------

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

From report at bugs.python.org  Fri Feb  3 16:15:05 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 15:15:05 +0000
Subject: [issue13807] logging.Handler.handlerError() may raise AttributeError
	in traceback.print_exception()
In-Reply-To: <1326816014.41.0.202399739958.issue13807@psf.upfronthosting.co.za>
Message-ID: <1328282105.62.0.552290630265.issue13807@psf.upfronthosting.co.za>


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

As said on python-checkins/-dev, this bug fix should be reverted in 3.1 (in security mode).

----------
nosy: +eric.araujo
versions:  -Python 2.6, Python 3.1, Python 3.4

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

From report at bugs.python.org  Fri Feb  3 16:36:24 2012
From: report at bugs.python.org (Samuel Iseli)
Date: Fri, 03 Feb 2012 15:36:24 +0000
Subject: [issue13889] str(float) and round(float) issues with FPU precision
In-Reply-To: <1327676303.66.0.487112802864.issue13889@psf.upfronthosting.co.za>
Message-ID: <1328283384.19.0.77412146228.issue13889@psf.upfronthosting.co.za>


Samuel Iseli <samuel.iseli at gmail.com> added the comment:

There's an excess space after a line continuation backslash in my last patch, so it doesn't compile (pyport.h, line 567).
Here's an additional patch that removes the space.
Didn't find out how to combine the 2 revisions in one patch-file...

Sorry about that.

----------
Added file: http://bugs.python.org/file24409/74747.patch

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

From report at bugs.python.org  Fri Feb  3 16:44:56 2012
From: report at bugs.python.org (zxw)
Date: Fri, 03 Feb 2012 15:44:56 +0000
Subject: [issue13931] os.path.exists inconsistent between 32 bit and 64 bit
Message-ID: <1328283896.91.0.836013924946.issue13931@psf.upfronthosting.co.za>


New submission from zxw <eeyore.tkc at gmail.com>:

When I run the following line while the 32 bit version of python is installed it returns false, however with the 64 bit version it correctly returns true.
os.path.exists('C:\\Windows\\System32\\msg.exe')

I'm using Python 2.7.2 with Windows 7 Professional 64bit.

----------
components: Windows
messages: 152524
nosy: zxw
priority: normal
severity: normal
status: open
title: os.path.exists inconsistent between 32 bit and 64 bit
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb  3 16:50:44 2012
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBCYXJ0aMOpbMOpbXk=?=)
Date: Fri, 03 Feb 2012 15:50:44 +0000
Subject: [issue13932] If some test module fails to import another module
	unittest reports a very misleading message
Message-ID: <1328284244.56.0.791299564661.issue13932@psf.upfronthosting.co.za>


New submission from S?bastien Barth?l?my <barthelemy at crans.org>:

If some test module (say, testmath) fails to import some other module, unittest reports a very misleading message:

  AttributeError: 'module' object has no attribute 'testmath'

Would it be possible improve the message or, better, to simply make the test as failed. (Maybe be by inspecting the ImportError exception message).

Consider the following example (and notice the typo at "import mathhh"):

mkdir -p test
touch test/__init__.py
cat > test/testmath.py <<EOL
import unittest
import mathhh
class MathTestCase(unittest.TestCase):
    def testSin(self):
        self.assertEqual(math.sin(0), 0)
EOL
python -m unittest test.testmath

it returns 

Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/usr/lib/python2.7/unittest/__main__.py", line 12, in <module>
    main(module=None)
  File "/usr/lib/python2.7/unittest/main.py", line 94, in __init__
    self.parseArgs(argv)
  File "/usr/lib/python2.7/unittest/main.py", line 149, in parseArgs
    self.createTests()
  File "/usr/lib/python2.7/unittest/main.py", line 158, in createTests
    self.module)
  File "/usr/lib/python2.7/unittest/loader.py", line 128, in loadTestsFromNames
    suites = [self.loadTestsFromName(name, module) for name in names]
  File "/usr/lib/python2.7/unittest/loader.py", line 100, in loadTestsFromName
    parent, obj = obj, getattr(obj, part)
AttributeError: 'module' object has no attribute 'testmath'

----------
components: Library (Lib)
messages: 152525
nosy: sbarthelemy
priority: normal
severity: normal
status: open
title: If some test module fails to import another module unittest reports a very misleading message
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb  3 16:52:08 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 03 Feb 2012 15:52:08 +0000
Subject: [issue13777] socket: communicating with Mac OS X KEXT controls
In-Reply-To: <1326392192.39.0.824287439397.issue13777@psf.upfronthosting.co.za>
Message-ID: <1328284328.88.0.826037179426.issue13777@psf.upfronthosting.co.za>


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

The patch fails to apply in configure.in. Can you please regenerate it?

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

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

From report at bugs.python.org  Fri Feb  3 16:53:51 2012
From: report at bugs.python.org (Tim Golden)
Date: Fri, 03 Feb 2012 15:53:51 +0000
Subject: [issue13931] os.path.exists inconsistent between 32 bit and 64 bit
In-Reply-To: <1328283896.91.0.836013924946.issue13931@psf.upfronthosting.co.za>
Message-ID: <4F2C030B.4000908@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

This is the Windows x64 file system redirector at work. I can't get 
through to msdn at the moment to get a link, but Google for those
terms.

----------
nosy: +tim.golden

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

From report at bugs.python.org  Fri Feb  3 16:56:39 2012
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Fri, 03 Feb 2012 15:56:39 +0000
Subject: [issue13830] codecs error handler is called with a UnicodeDecodeError
	with the same args
In-Reply-To: <1327002997.43.0.435824061039.issue13830@psf.upfronthosting.co.za>
Message-ID: <1328284599.76.0.0634774649002.issue13830@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

See this ancient posting about this problem:

   http://mail.python.org/pipermail/python-dev/2002-August/027661.html

(see point 4.). So I guess somebody did finally complain! ;)

The error attributes are documented in PEP 293. The existence of the attributes is documented in Doc/c-api/exceptions.rst, but not their meaning.

----------
nosy: +doerwalter

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

From report at bugs.python.org  Fri Feb  3 16:58:54 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 03 Feb 2012 15:58:54 +0000
Subject: [issue13777] socket: communicating with Mac OS X KEXT controls
In-Reply-To: <1326392192.39.0.824287439397.issue13777@psf.upfronthosting.co.za>
Message-ID: <1328284734.48.0.962298406306.issue13777@psf.upfronthosting.co.za>


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

Also: Can you propose test cases for this socket family?

----------

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

From report at bugs.python.org  Fri Feb  3 16:59:13 2012
From: report at bugs.python.org (David Layton)
Date: Fri, 03 Feb 2012 15:59:13 +0000
Subject: [issue13824] argparse.FileType opens a file and never closes it
In-Reply-To: <1328279863.46.0.0636535662554.issue13824@psf.upfronthosting.co.za>
Message-ID: <CAMLf2pe+tv4o2pN72YNOs1CoksTVQjqDqVOx3_Y8=VFqFS7aLQ@mail.gmail.com>


David Layton <dmlayton at gmail.com> added the comment:

Eric,

checked that the file exists
But then you?d run into race conditions.  The only sure was to say if a
file can be opened is to open it.

    I think you misunderstand me. I am NOT suggesting that you open and
close the file. I am saying that you should not open it in the first place.
If I cannot open the file at the point in my program where I actually want
to open it, then fine, I can decide, in my own code, what to do.

propensity to encourage bad
> coding.
I think the problem is not as bad as you paint it.  A great number of
unclosed file handles may cause problem to some OSes, but that?s it.  On
the plus side, the fact that argparse accepts for its type argument any
callable that can check and convert a string input is simple, clean and
works.  FileType is needed.

  Causing a problem on some OSes and not others is worse than causing a
problem on all OSes as it increases the likelihood of buggy code passing
tests and moving to production.
 I think argparse is wonderful; I just think that by having FileType not
open the file, the number of it's use cases is increased. As it stands now,
I would prefer the just pass the argument as a string argument and handling
the opening myself unless:

   1. I wanted my program to open the file at the very beginning of the
   program (where one traditionally handles arg parsing)
   2. I wanted to exit on the first, and only, attempt to open the file
   3. I really did not care if the file closed properly--which, granted, is
   often the case with tiny scripts

The moment any of these is not true due to a change in requirements, I will
have to refactor my code to use a filename arg. Where as if I start out
with a bog-standard filename and open it myself, I can easily add the
behaviour I want. I just don't see FileType as a big convenience. However,
I do see that changing this would break backwards compatibility and would
not want to see that happen. Perhaps a new FileNameType that does some
basic, perhaps, optional checks would have wider use-cases.

I hope this helps.

                David Layton

On Fri, Feb 3, 2012 at 2:37 PM, ?ric Araujo <report at bugs.python.org> wrote:

>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> s/sure was/sure way/
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13824>
> _______________________________________
>

----------

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

From report at bugs.python.org  Fri Feb  3 17:00:06 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 03 Feb 2012 16:00:06 +0000
Subject: [issue13933] IDLE:not able to complete the hashlib module
Message-ID: <1328284806.31.0.442750340549.issue13933@psf.upfronthosting.co.za>


New submission from Ramchandra Apte <maniandram01 at gmail.com>:

No completion appears when I import hashlib in IDLE and type in "hashlib." and press Tab to complete.
With any other module it works.

----------
components: IDLE, Library (Lib)
messages: 152531
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: IDLE:not able to complete the hashlib module
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Feb  3 17:15:20 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Feb 2012 16:15:20 +0000
Subject: [issue13861] test_pydoc failure
In-Reply-To: <1328276832.69.0.171538388828.issue13861@psf.upfronthosting.co.za>
Message-ID: <20120203161519.GA23732@sleipnir.bytereef.org>


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

Eric Araujo <report at bugs.python.org> wrote:
> docutils is the first package that???s found in my user site-packages;
> can you tell if your Crypto package is in that same location?

The package is here:

/usr/local/lib/python3.3/site-packages/Crypto/SelfTest/Protocol/test_AllOrNothing.py

The tests are (naturally) run in the cpython repo, but
/usr/local/lib/python3.3/site-packages is in sys.path.

----------

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

From report at bugs.python.org  Fri Feb  3 17:17:34 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 16:17:34 +0000
Subject: [issue13861] test_pydoc failure
In-Reply-To: <1327517017.59.0.678002352905.issue13861@psf.upfronthosting.co.za>
Message-ID: <1328285854.41.0.637826414754.issue13861@psf.upfronthosting.co.za>


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

Adding Ned, who refactored these tests, to nosy.

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

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

From report at bugs.python.org  Fri Feb  3 17:21:02 2012
From: report at bugs.python.org (John Dennis)
Date: Fri, 03 Feb 2012 16:21:02 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1328286062.21.0.397195519482.issue11104@psf.upfronthosting.co.za>


John Dennis <jdennis at redhat.com> added the comment:

The changesets are not in the release27-maint branch. sdist still does not generate a correct archive for release, this is a very serious regression.

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

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

From report at bugs.python.org  Fri Feb  3 17:25:31 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 16:25:31 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1328286331.96.0.535978894347.issue11104@psf.upfronthosting.co.za>


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

> The changesets are not in the release27-maint branch.
Where did you look?  This looks like a Subversion branch name, but now we?re using Mercurial.  If you look a few messages up, you?ll see that a changeset was committed to the 2.7 branch and will be included in 2.7.3.

----------

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

From report at bugs.python.org  Fri Feb  3 17:26:23 2012
From: report at bugs.python.org (Stephen Thorne)
Date: Fri, 03 Feb 2012 16:26:23 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1328286383.46.0.829804296625.issue11104@psf.upfronthosting.co.za>


Stephen Thorne <stephen at thorne.id.au> added the comment:

Yep - 2.7.2 was released 11th June 2011, the fix was committed Aug 1st 2011. So it won't be in the current 2.7 release.

----------

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

From report at bugs.python.org  Fri Feb  3 17:30:52 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Feb 2012 16:30:52 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1328286652.96.0.180440507873.issue11104@psf.upfronthosting.co.za>


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

Obviously I can?t fix past releases.  Sometimes the time machine is not available :)

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

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

From report at bugs.python.org  Fri Feb  3 17:33:25 2012
From: report at bugs.python.org (Michael Goderbauer)
Date: Fri, 03 Feb 2012 16:33:25 +0000
Subject: [issue13777] socket: communicating with Mac OS X KEXT controls
In-Reply-To: <1326392192.39.0.824287439397.issue13777@psf.upfronthosting.co.za>
Message-ID: <1328286805.4.0.982364641705.issue13777@psf.upfronthosting.co.za>


Michael Goderbauer <contact at m-goderbauer.de> added the comment:

Here is the regenerated patch.

To write a test case I would need a PF_SYSTEM socket to connect to. As far as I know Mac OS X doesn't provide a demo socket for this.

----------
Added file: http://bugs.python.org/file24410/patch2.patch

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

From report at bugs.python.org  Fri Feb  3 17:45:08 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 03 Feb 2012 16:45:08 +0000
Subject: [issue13777] socket: communicating with Mac OS X KEXT controls
In-Reply-To: <1326392192.39.0.824287439397.issue13777@psf.upfronthosting.co.za>
Message-ID: <E1RtMG2-0002SW-SP@dinsdale.python.org>


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

New changeset aa3680d2c24d by Martin v. L?wis in branch 'default':
Issue #13777: Add PF_SYSTEM sockets on OS X.
http://hg.python.org/cpython/rev/aa3680d2c24d

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

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

From report at bugs.python.org  Fri Feb  3 17:46:13 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 03 Feb 2012 16:46:13 +0000
Subject: [issue13777] socket: communicating with Mac OS X KEXT controls
In-Reply-To: <1326392192.39.0.824287439397.issue13777@psf.upfronthosting.co.za>
Message-ID: <1328287573.17.0.256322855061.issue13777@psf.upfronthosting.co.za>


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

Thanks for the patch. Committed with an additional fix in refcounting.

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

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

From report at bugs.python.org  Fri Feb  3 17:50:21 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 03 Feb 2012 16:50:21 +0000
Subject: [issue13889] str(float) and round(float) issues with FPU precision
In-Reply-To: <1327676303.66.0.487112802864.issue13889@psf.upfronthosting.co.za>
Message-ID: <1328287821.02.0.723629164688.issue13889@psf.upfronthosting.co.za>


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

General shape of the patch looks good.

I'd suggest using a mask of _MCW_PC | _MCW_RC instead of just _MCW_PC, so that the rounding mode is also set correctly.  Probably rarely an issue in practice, but it's the same thing that we're doing on Linux.

If this is going near the maintenance branches (2.7, 3.2), we need to be very careful.

Have you had the opportunity to test the patch (e.g., run the complete Python test suite) both on 32-bit and 64-bit Windows?

----------

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

From report at bugs.python.org  Fri Feb  3 17:54:10 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Feb 2012 16:54:10 +0000
Subject: [issue13889] str(float) and round(float) issues with FPU precision
In-Reply-To: <1327676303.66.0.487112802864.issue13889@psf.upfronthosting.co.za>
Message-ID: <1328288050.03.0.153814307731.issue13889@psf.upfronthosting.co.za>


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


----------
components: +Windows
stage:  -> patch review

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

From report at bugs.python.org  Fri Feb  3 18:03:10 2012
From: report at bugs.python.org (zxw)
Date: Fri, 03 Feb 2012 17:03:10 +0000
Subject: [issue13931] os.path.exists inconsistent between 32 bit and 64 bit
In-Reply-To: <1328283896.91.0.836013924946.issue13931@psf.upfronthosting.co.za>
Message-ID: <1328288590.25.0.286221474664.issue13931@psf.upfronthosting.co.za>


zxw <eeyore.tkc at gmail.com> added the comment:

Ok, thanks, that fixed it. I'll probably post some example code for anyone else who stumbles across this with the same problem, don't have the time right now however.

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

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

From report at bugs.python.org  Fri Feb  3 18:09:01 2012
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 03 Feb 2012 17:09:01 +0000
Subject: [issue13931] os.path.exists inconsistent between 32 bit and 64 bit
In-Reply-To: <1328283896.91.0.836013924946.issue13931@psf.upfronthosting.co.za>
Message-ID: <1328288941.42.0.76204112153.issue13931@psf.upfronthosting.co.za>


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


----------
resolution:  -> invalid
stage:  -> committed/rejected

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

From report at bugs.python.org  Fri Feb  3 18:15:47 2012
From: report at bugs.python.org (Nick Wilson)
Date: Fri, 03 Feb 2012 17:15:47 +0000
Subject: [issue13463] Fix parsing of package_data
In-Reply-To: <1322068433.36.0.783240091616.issue13463@psf.upfronthosting.co.za>
Message-ID: <1328289347.69.0.806307612621.issue13463@psf.upfronthosting.co.za>


Changes by Nick Wilson <nick at njwilson.net>:


----------
nosy: +njwilson

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

From report at bugs.python.org  Fri Feb  3 18:29:36 2012
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 03 Feb 2012 17:29:36 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1328290176.82.0.0425865075157.issue6210@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

> Because Ellipsis is now the default value for __cause__,
> 'raise ... from Ellipsis' is treated the same as 'raise ...'

Not exactly true -- if ... is a new exception then they are the same; if ... is a caught exception that is being reraised, __cause__ will be (re)set to Ellipsis.

----------

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

From report at bugs.python.org  Fri Feb  3 18:38:54 2012
From: report at bugs.python.org (Eric Snow)
Date: Fri, 03 Feb 2012 17:38:54 +0000
Subject: [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za>
Message-ID: <1328290734.44.0.984144953749.issue13124@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

No problem, Stefan.  :)  The main motivation was to capture the discussion at the time so that something actually came of it.

Adding info to the devguide, essentially the catalog/how-to of core dev activities, was meant to simply provide another clear avenue for those that wanted to help with Python's core development.  If not a dedicated page, we should at least have a link in the "Contributing" section to the (single, authoritative) resource we have on setting-up/running a build slave, regardless of where that resource resides.

That said, I gladly defer to those that are more involved with the buildbots.  Incidentally, the second patch is a bit cleaner than the first.

----------

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

From report at bugs.python.org  Fri Feb  3 19:03:36 2012
From: report at bugs.python.org (Tim Willis)
Date: Fri, 03 Feb 2012 18:03:36 +0000
Subject: [issue13879] Argparse does not support subparser aliases in 2.7
In-Reply-To: <1327597168.42.0.828007379667.issue13879@psf.upfronthosting.co.za>
Message-ID: <1328292216.63.0.614115651886.issue13879@psf.upfronthosting.co.za>


Tim Willis <schadenfreude328 at gmail.com> added the comment:

The documentation appears to be up to date in the current 2.7 repository, so this can probably be marked as closed/fixed.

----------

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

From report at bugs.python.org  Fri Feb  3 19:24:38 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 03 Feb 2012 18:24:38 +0000
Subject: [issue13807] logging.Handler.handlerError() may raise AttributeError
	in traceback.print_exception()
In-Reply-To: <1326816014.41.0.202399739958.issue13807@psf.upfronthosting.co.za>
Message-ID: <E1RtNoK-0003ld-W8@dinsdale.python.org>


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

New changeset 813a34170ac5 by Vinay Sajip in branch '3.1':
Revert fix for #13807 mistakenly applied in this branch.
http://hg.python.org/cpython/rev/813a34170ac5

----------

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

From report at bugs.python.org  Fri Feb  3 19:39:08 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 03 Feb 2012 18:39:08 +0000
Subject: [issue13930] lib2to3 ability to output files into a different
	directory and alter their names
In-Reply-To: <1328254888.57.0.86339015419.issue13930@psf.upfronthosting.co.za>
Message-ID: <1328294348.73.0.500731541588.issue13930@psf.upfronthosting.co.za>


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

while the initial patch below was against 3.1 I'm only intending to commit this to 3.2, 3.3 and 2.7.

Feature backports on lib2to3 are allowed per http://mail.python.org/pipermail/python-dev/2011-December/115089.html.

----------
nosy: +benjamin.peterson
versions:  -Python 3.1

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

From report at bugs.python.org  Fri Feb  3 19:39:54 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 03 Feb 2012 18:39:54 +0000
Subject: [issue13930] lib2to3 ability to output files into a different
	directory and alter their names
In-Reply-To: <1328254888.57.0.86339015419.issue13930@psf.upfronthosting.co.za>
Message-ID: <1328294394.07.0.35311682805.issue13930@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file24411/a6cd0518495e.diff

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

From report at bugs.python.org  Fri Feb  3 19:44:21 2012
From: report at bugs.python.org (poq)
Date: Fri, 03 Feb 2012 18:44:21 +0000
Subject: [issue13934] sqlite3 test typo
Message-ID: <1328294661.43.0.135509150445.issue13934@psf.upfronthosting.co.za>


New submission from poq <poq at gmx.com>:

The test CheckCollationIsUsed in Lib/sqlite3/test/hooks.py never runs because it checks the wrong version tuple. Patch attached.

----------
components: Tests
files: sqlite3-test-hooks.patch
keywords: patch
messages: 152548
nosy: poq
priority: normal
severity: normal
status: open
title: sqlite3 test typo
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24412/sqlite3-test-hooks.patch

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

From report at bugs.python.org  Fri Feb  3 19:54:47 2012
From: report at bugs.python.org (poq)
Date: Fri, 03 Feb 2012 18:54:47 +0000
Subject: [issue13773] Support sqlite3 uri filenames
In-Reply-To: <1326313998.63.0.583537561643.issue13773@psf.upfronthosting.co.za>
Message-ID: <1328295287.85.0.66872253402.issue13773@psf.upfronthosting.co.za>


poq <poq at gmx.com> added the comment:

> Can you open a bug report for that?

Opened #13934.

> I think the doc could link to the sqlite.org doc about URIs.

I considered this, but the rest of the sqlite3 module documentation doesn't link to the sqlite.org doc pages either. There is only a link to http://www.sqlite.org under 'See also'.

----------

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

From report at bugs.python.org  Fri Feb  3 19:56:31 2012
From: report at bugs.python.org (Oskar Wycislak)
Date: Fri, 03 Feb 2012 18:56:31 +0000
Subject: [issue13935] Tarfile - Fixed GNU tar header base-256 handling
Message-ID: <1328295391.26.0.207109805209.issue13935@psf.upfronthosting.co.za>


New submission from Oskar Wycislak <cantorek at gmail.com>:

On line 199 in tarfile.py comparison should be done without chr() because s[0] is an integer.
Also on line 208 there should be no ord() for the same reason.

I think this is fixed in Python 3.3

I'm sorry for not providing a patch but it's late and I do not have mercurial installed.

----------
components: Library (Lib)
messages: 152550
nosy: canto
priority: normal
severity: normal
status: open
title: Tarfile - Fixed GNU tar header base-256 handling
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb  3 20:48:05 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 03 Feb 2012 19:48:05 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1328298485.4.0.227390739663.issue1625@psf.upfronthosting.co.za>


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

> In fact, you can create those files from python, files that python can not unpack later.

Really? How so? BZ2File only started accepting the "a" mode in 3.3
(thanks to Nir's patch for this issue, actually).

> If the refusal of backporting this to 3.2 and 2.7 is firm, I would beg to document this limitation in the 2.7/3.2 docs. It is serious enough.

Of course. I'll add a note to the docs once I've created the bz2file
package on PyPI, so we can refer readers to it.


> As the bug/feature judgment is not easy to make, I think python-dev should be asked.

Fair enough; I was actually going to suggest consulting the 2.7 release
manager, but I suppose getting more opinions on the mailing list makes
sense.

----------

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

From report at bugs.python.org  Fri Feb  3 21:10:37 2012
From: report at bugs.python.org (poq)
Date: Fri, 03 Feb 2012 20:10:37 +0000
Subject: [issue12142] Reference cycle when importing ctypes
In-Reply-To: <1306017588.73.0.650837416325.issue12142@psf.upfronthosting.co.za>
Message-ID: <1328299837.01.0.779906416299.issue12142@psf.upfronthosting.co.za>


poq <poq at gmx.com> added the comment:

I've attached a patch for the _array_type change.

The long double fix is probably dependent on PEP3118 (#3132).

----------
keywords: +patch
Added file: http://bugs.python.org/file24413/ctypes-leak.patch

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

From report at bugs.python.org  Fri Feb  3 21:12:35 2012
From: report at bugs.python.org (poq)
Date: Fri, 03 Feb 2012 20:12:35 +0000
Subject: [issue12993] prepared statements in sqlite3 module
In-Reply-To: <1316176459.71.0.201980894918.issue12993@psf.upfronthosting.co.za>
Message-ID: <1328299955.2.0.203261764092.issue12993@psf.upfronthosting.co.za>


poq <poq at gmx.com> added the comment:

This can be closed.

----------

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

From report at bugs.python.org  Fri Feb  3 21:18:16 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Feb 2012 20:18:16 +0000
Subject: [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1328290734.44.0.984144953749.issue13124@psf.upfronthosting.co.za>
Message-ID: <20120203201812.GA24627@sleipnir.bytereef.org>


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

Eric Snow <report at bugs.python.org> wrote:
> Incidentally, the second patch is a bit cleaner than the first.

Yes, indeed it is. :) To prevent a misunderstanding: In my last mail I was
talking about the "Build Slaves and Security" additions to:

http://wiki.python.org/moin/BuildBot

----------

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

From report at bugs.python.org  Fri Feb  3 21:20:01 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Feb 2012 20:20:01 +0000
Subject: [issue12142] Reference cycle when importing ctypes
In-Reply-To: <1306017588.73.0.650837416325.issue12142@psf.upfronthosting.co.za>
Message-ID: <1328300401.47.0.117565696023.issue12142@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Feb  3 21:23:22 2012
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 03 Feb 2012 20:23:22 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1328300602.13.0.117677595595.issue6210@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

I just noticed that no one is assigned to this issue -- anybody on the nosy list able to review?

----------

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

From report at bugs.python.org  Fri Feb  3 21:43:16 2012
From: report at bugs.python.org (Lakin Wecker)
Date: Fri, 03 Feb 2012 20:43:16 +0000
Subject: [issue13936] datetime.time(0, 0,
	0) evaluates to False despite being a valid time
Message-ID: <1328301796.8.0.996607861145.issue13936@psf.upfronthosting.co.za>


New submission from Lakin Wecker <lakin.wecker at gmail.com>:

midnight is represented by datetime.time(0,0,0).  However, this time (unlike all other valid times, including datetime.time(0,0,1)) evalutes to false in if conditions:

import datetime
if datetime.time(0,0,0):
    print "datetime.time(0,0,0) is not a bug!"
else:
    print "datetime.time(0,0,0) is a bug!"

if datetime.time(0,0,1):
    print "datetime.time(0,0,1) is not a bug!"
else:
    print "datetime.time(0,0,1) is a bug!"

----------
messages: 152556
nosy: Lakin.Wecker
priority: normal
severity: normal
status: open
title: datetime.time(0,0,0) evaluates to False despite being a valid time

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

From report at bugs.python.org  Fri Feb  3 21:43:44 2012
From: report at bugs.python.org (Lakin Wecker)
Date: Fri, 03 Feb 2012 20:43:44 +0000
Subject: [issue13936] datetime.time(0, 0,
	0) evaluates to False despite being a valid time
In-Reply-To: <1328301796.8.0.996607861145.issue13936@psf.upfronthosting.co.za>
Message-ID: <1328301824.36.0.0486056098445.issue13936@psf.upfronthosting.co.za>


Lakin Wecker <lakin.wecker at gmail.com> added the comment:

I'm updating the versions to the ones that I've actually tried it on - this is not an exhaustive search at this point.

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

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

From report at bugs.python.org  Fri Feb  3 21:44:23 2012
From: report at bugs.python.org (Lakin Wecker)
Date: Fri, 03 Feb 2012 20:44:23 +0000
Subject: [issue13936] datetime.time(0, 0,
	0) evaluates to False despite being a valid time
In-Reply-To: <1328301796.8.0.996607861145.issue13936@psf.upfronthosting.co.za>
Message-ID: <1328301863.75.0.886598567586.issue13936@psf.upfronthosting.co.za>


Changes by Lakin Wecker <lakin.wecker at gmail.com>:


----------
components: +Library (Lib)
type:  -> behavior

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

From report at bugs.python.org  Fri Feb  3 21:52:02 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Feb 2012 20:52:02 +0000
Subject: [issue13936] datetime.time(0, 0,
	0) evaluates to False despite being a valid time
In-Reply-To: <1328301796.8.0.996607861145.issue13936@psf.upfronthosting.co.za>
Message-ID: <1328302322.18.0.0298503242216.issue13936@psf.upfronthosting.co.za>


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

I don't think I would have ever thought of testing a datetime for its truth value.  But the behavior you observe is consistent with the rest of Python: 0 is false.

I wonder if this is by design or by accident.

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

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

From report at bugs.python.org  Fri Feb  3 21:52:17 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Feb 2012 20:52:17 +0000
Subject: [issue13936] datetime.time(0, 0,
	0) evaluates to False despite being a valid time
In-Reply-To: <1328301796.8.0.996607861145.issue13936@psf.upfronthosting.co.za>
Message-ID: <1328302337.47.0.911194022871.issue13936@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


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

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

From report at bugs.python.org  Fri Feb  3 21:55:11 2012
From: report at bugs.python.org (Lakin Wecker)
Date: Fri, 03 Feb 2012 20:55:11 +0000
Subject: [issue13936] datetime.time(0, 0,
	0) evaluates to False despite being a valid time
In-Reply-To: <1328301796.8.0.996607861145.issue13936@psf.upfronthosting.co.za>
Message-ID: <1328302511.16.0.180137160278.issue13936@psf.upfronthosting.co.za>


Lakin Wecker <lakin.wecker at gmail.com> added the comment:

Right. I've updated my code to be more correct:

instead of:

if not start_time:
    start_time = default_time

it now reads:

if start_time is None:
    start_time = default_time

which operates correctly and works fine for my case, I just thought it was odd that one time out of all of them evaluates to False.  I too wonder if it's by design or not.

It's definitely not documented if it is by design.

----------

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

From report at bugs.python.org  Fri Feb  3 21:56:27 2012
From: report at bugs.python.org (Patrick Andrew)
Date: Fri, 03 Feb 2012 20:56:27 +0000
Subject: [issue5300] build_module faulre
In-Reply-To: <1234907694.25.0.317480697226.issue5300@psf.upfronthosting.co.za>
Message-ID: <1328302587.61.0.847474662236.issue5300@psf.upfronthosting.co.za>


Changes by Patrick Andrew <pandrew at isilon.com>:


----------
components: +Distutils -Distutils2
title: Distutils ignores file permissions -> build_module faulre
versions: +Python 2.7 -3rd party

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

From report at bugs.python.org  Fri Feb  3 21:56:31 2012
From: report at bugs.python.org (Patrick Andrew)
Date: Fri, 03 Feb 2012 20:56:31 +0000
Subject: [issue5300] build_module failure
In-Reply-To: <1234907694.25.0.317480697226.issue5300@psf.upfronthosting.co.za>
Message-ID: <1328302591.55.0.800206339279.issue5300@psf.upfronthosting.co.za>


Changes by Patrick Andrew <pandrew at isilon.com>:


----------
title: build_module faulre -> build_module failure

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

From report at bugs.python.org  Fri Feb  3 21:57:52 2012
From: report at bugs.python.org (Patrick Andrew)
Date: Fri, 03 Feb 2012 20:57:52 +0000
Subject: [issue5300] distutils ignores file permissions
In-Reply-To: <1234907694.25.0.317480697226.issue5300@psf.upfronthosting.co.za>
Message-ID: <1328302672.71.0.410294278052.issue5300@psf.upfronthosting.co.za>


Changes by Patrick Andrew <pandrew at isilon.com>:


----------
components: +Distutils2 -Distutils
nosy: +alexis
title: build_module failure -> distutils ignores file permissions
versions: +3rd party -Python 2.7

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

From report at bugs.python.org  Fri Feb  3 22:04:48 2012
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Feb 2012 21:04:48 +0000
Subject: [issue13936] datetime.time(0, 0,
	0) evaluates to False despite being a valid time
In-Reply-To: <1328301796.8.0.996607861145.issue13936@psf.upfronthosting.co.za>
Message-ID: <1328303088.73.0.0897075024521.issue13936@psf.upfronthosting.co.za>


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

It must be by design -- someone has implemented a __bool__ (formerly __nonzero__) method; otherwise all objects would be true.

----------
nosy: +georg.brandl, lemburg

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

From report at bugs.python.org  Fri Feb  3 22:05:38 2012
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Feb 2012 21:05:38 +0000
Subject: [issue13936] datetime.time(0, 0,
	0) evaluates to False despite being a valid time
In-Reply-To: <1328301796.8.0.996607861145.issue13936@psf.upfronthosting.co.za>
Message-ID: <1328303138.19.0.356918070142.issue13936@psf.upfronthosting.co.za>


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

BTW, "being a valid time" is not a good argument: 0, "" or False are all valid instances of their types.

----------

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

From report at bugs.python.org  Fri Feb  3 22:06:19 2012
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Feb 2012 21:06:19 +0000
Subject: [issue12993] prepared statements in sqlite3 module
In-Reply-To: <1316176459.71.0.201980894918.issue12993@psf.upfronthosting.co.za>
Message-ID: <1328303179.38.0.037228174789.issue12993@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Feb  3 22:09:23 2012
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Feb 2012 21:09:23 +0000
Subject: [issue13936] datetime.time(0, 0,
	0) evaluates to False despite being a valid time
In-Reply-To: <1328301796.8.0.996607861145.issue13936@psf.upfronthosting.co.za>
Message-ID: <1328303363.36.0.297554460363.issue13936@psf.upfronthosting.co.za>


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

This is by design.  I don't have a reference, but I do remember this being discussed.  Suggestions for improving the documentation are welcome.

----------

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

From report at bugs.python.org  Fri Feb  3 22:19:49 2012
From: report at bugs.python.org (Tim Peters)
Date: Fri, 03 Feb 2012 21:19:49 +0000
Subject: [issue13936] datetime.time(0, 0,
	0) evaluates to False despite being a valid time
In-Reply-To: <1328301796.8.0.996607861145.issue13936@psf.upfronthosting.co.za>
Message-ID: <1328303989.97.0.73693552985.issue13936@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

>From the docs, at:

http://docs.python.org/library/datetime.html#time-objects

"""
in Boolean contexts, a time object is considered to be true if and only if, after converting it to minutes and subtracting utcoffset() (or 0 if that?s None), the result is non-zero.
"""

----------
nosy: +tim_one

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

From report at bugs.python.org  Fri Feb  3 22:23:40 2012
From: report at bugs.python.org (Lakin Wecker)
Date: Fri, 03 Feb 2012 21:23:40 +0000
Subject: [issue13936] datetime.time(0, 0,
	0) evaluates to False despite being a valid time
In-Reply-To: <1328301796.8.0.996607861145.issue13936@psf.upfronthosting.co.za>
Message-ID: <1328304220.69.0.110384549401.issue13936@psf.upfronthosting.co.za>


Lakin Wecker <lakin.wecker at gmail.com> added the comment:

Although I find it odd, you are all correct.

It is documented.  (I don't know how I missed that when I read those docs looking for that exact documentation).

It is consistent with the rest of python.

Do I close this? Do you guys? I'm fine with closing it.  Thanks and sorry for the noise.

----------

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

From report at bugs.python.org  Fri Feb  3 22:28:18 2012
From: report at bugs.python.org (Tim Peters)
Date: Fri, 03 Feb 2012 21:28:18 +0000
Subject: [issue13936] datetime.time(0, 0,
	0) evaluates to False despite being a valid time
In-Reply-To: <1328301796.8.0.996607861145.issue13936@psf.upfronthosting.co.za>
Message-ID: <1328304498.68.0.122996531655.issue13936@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

It is odd, but really no odder than "zero values" of other types evaluating to false in Boolean contexts ;-)  Closing as "invalid".

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

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

From report at bugs.python.org  Fri Feb  3 22:29:23 2012
From: report at bugs.python.org (Ben Timby)
Date: Fri, 03 Feb 2012 21:29:23 +0000
Subject: [issue13937] multiprocessing.ThreadPool.join() blocks indefinitely.
Message-ID: <1328304563.24.0.329312202759.issue13937@psf.upfronthosting.co.za>


New submission from Ben Timby <btimby at gmail.com>:

If you instantiate a ThreadPool, then call map() with an empty list, the join() method will block indefinitely on self._result_handler.join()

$ python
> from multiprocessing.pool import ThreadPool
> t = ThreadPool(1)
> t.map_async(lambda x: x, [])
> t.close()
> t.join()  # <- never returns

I was not able to determine the root cause, however, I found that the join() blocks when joining the _result_handler thread.

----------
components: Library (Lib)
messages: 152566
nosy: Ben.Timby
priority: normal
severity: normal
status: open
title: multiprocessing.ThreadPool.join() blocks indefinitely.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb  3 22:30:47 2012
From: report at bugs.python.org (Lakin Wecker)
Date: Fri, 03 Feb 2012 21:30:47 +0000
Subject: [issue13936] datetime.time(0, 0,
	0) evaluates to False despite being a valid time
In-Reply-To: <1328301796.8.0.996607861145.issue13936@psf.upfronthosting.co.za>
Message-ID: <1328304647.75.0.0246257582569.issue13936@psf.upfronthosting.co.za>


Lakin Wecker <lakin.wecker at gmail.com> added the comment:

Yeah - good point, and I agree.

----------

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

From report at bugs.python.org  Fri Feb  3 23:16:47 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 03 Feb 2012 22:16:47 +0000
Subject: [issue13861] test_pydoc failure
In-Reply-To: <1327517017.59.0.678002352905.issue13861@psf.upfronthosting.co.za>
Message-ID: <E1RtRR0-0003iR-An@dinsdale.python.org>


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

New changeset e5f2c04055a2 by Ned Deily in branch '2.7':
Issue #13861: Prevent test_apropos* test case failures in test_pydoc.
http://hg.python.org/cpython/rev/e5f2c04055a2

New changeset 5eb47e1732a0 by Ned Deily in branch '3.2':
Issue #13861: Prevent test_apropos* test case failures in test_pydoc.
http://hg.python.org/cpython/rev/5eb47e1732a0

New changeset ff230e366610 by Ned Deily in branch 'default':
Issue #13861: merge
http://hg.python.org/cpython/rev/ff230e366610

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

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

From report at bugs.python.org  Fri Feb  3 23:22:53 2012
From: report at bugs.python.org (Ned Deily)
Date: Fri, 03 Feb 2012 22:22:53 +0000
Subject: [issue13861] test_pydoc failure
In-Reply-To: <1327517017.59.0.678002352905.issue13861@psf.upfronthosting.co.za>
Message-ID: <1328307773.74.0.0573177615348.issue13861@psf.upfronthosting.co.za>


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

For the as-yet unreleased changes for Issue7425, I added some test cases for pydoc -k (apropos) and chose a keyword of "nothing", a keyword which has no hits in the standard library.  Unfortunately, you both installed third-party packages that *do* have hits for "nothing".  Cute!  I've now changed the keyword to a nonsense one which I hope will have a zero probability of getting a hit.

----------
assignee:  -> ned.deily
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/issue13861>
_______________________________________

From report at bugs.python.org  Sat Feb  4 00:36:12 2012
From: report at bugs.python.org (Ned Deily)
Date: Fri, 03 Feb 2012 23:36:12 +0000
Subject: [issue13926] pydoc - stall when requesting a list of available
	modules in the online help utility
In-Reply-To: <CA+0o7Qhzry+gjk3dwLqwtvckxKq=QpDeg-84po9Ve-fHsn-boQ@mail.gmail.com>
Message-ID: <1328312172.48.0.598520535711.issue13926@psf.upfronthosting.co.za>


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

Jeroen, if you try running "help()" from a command-line python2.7, rather than in IDLE, what results do you get?  Most likely, Python will crash there and there should be an exception and traceback printed, in which case the problem has nothing to do with IDLE directly.  Note that there have been some improvements to pydoc's robustness since 2.7.2 was released (for instance, the changes for issue7425 and issue7367).

(Terry, are you sure you meant Issue12092?)

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

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

From report at bugs.python.org  Sat Feb  4 01:24:08 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Feb 2012 00:24:08 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328315048.67.0.231205738361.issue13882@psf.upfronthosting.co.za>


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

Even if some people dislike the idea of adding datetime.datetime type, here is a patch implementing it (it requires time_decimal-XX.patch). The patch is at least a proof-of-concept that it is possible to change the internal structure without touching the public API.

Example:

$ ./python
>>> import datetime, os, time
>>> open("x", "wb").close(); print(datetime.datetime.now())
2012-02-04 01:17:27.593834                                                                                                                  
>>> print(os.stat("x", timestamp=datetime.datetime).st_ctime)                                                                        
2012-02-04 00:17:27.592284+00:00                                                                                                            
>>> print(time.time(timestamp=datetime.datetime))                                                                                           
2012-02-04 00:18:21.329012+00:00
>>> time.clock(timestamp=datetime.datetime)
ValueError: clock has an unspecified starting point
>>> print(time.clock_gettime(time.CLOCK_REALTIME, timestamp=datetime.datetime))
2012-02-04 00:21:37.815663+00:00
>>> print(time.clock_gettime(time.CLOCK_MONOTONIC, timestamp=datetime.datetime))
ValueError: clock has an unspecified starting point

As you can see: conversion to datetime.datetime fails with ValueError('clock has an unspecified starting point') for some functions, sometimes depending on the function argument (clock_gettime).

----------
Added file: http://bugs.python.org/file24414/timestamp_datetime.patch

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

From report at bugs.python.org  Sat Feb  4 01:39:58 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 00:39:58 +0000
Subject: [issue13926] pydoc - stall when requesting a list of available
	modules in the online help utility
In-Reply-To: <CA+0o7Qhzry+gjk3dwLqwtvckxKq=QpDeg-84po9Ve-fHsn-boQ@mail.gmail.com>
Message-ID: <1328315998.78.0.852181163211.issue13926@psf.upfronthosting.co.za>


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


----------
superseder: Clarify sentence in tutorial -> help("modules") executes module code

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

From report at bugs.python.org  Sat Feb  4 01:41:49 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 00:41:49 +0000
Subject: [issue13926] pydoc - stall when requesting a list of available
	modules in the online help utility
In-Reply-To: <CA+0o7Qhzry+gjk3dwLqwtvckxKq=QpDeg-84po9Ve-fHsn-boQ@mail.gmail.com>
Message-ID: <1328316109.77.0.0369850161985.issue13926@psf.upfronthosting.co.za>


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

digit transposition corrected 12902

----------

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

From report at bugs.python.org  Sat Feb  4 01:52:47 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Feb 2012 00:52:47 +0000
Subject: [issue13830] codecs error handler is called with a UnicodeDecodeError
	with the same args
In-Reply-To: <1327002997.43.0.435824061039.issue13830@psf.upfronthosting.co.za>
Message-ID: <1328316767.26.0.669520812194.issue13830@psf.upfronthosting.co.za>


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

Codec encoders reuse the same exception object for speed, but set some attributes (start, end and reason). Recreate the args tuple each time that a attribute is set. UnicodeEncodeError and UnicodeDecodeError should maybe override args getter to create a new tuple at each call.

----------

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

From report at bugs.python.org  Sat Feb  4 02:39:17 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 01:39:17 +0000
Subject: [issue12955] urllib.request example should use "with ... as:"
In-Reply-To: <1315650628.73.0.673162910121.issue12955@psf.upfronthosting.co.za>
Message-ID: <1328319557.89.0.674064527887.issue12955@psf.upfronthosting.co.za>


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

Senthil:
http://docs.python.org/dev/library/contextlib.html#contextlib.closing
currently has this example:

from urllib.request import urlopen
with closing(urlopen('http://www.python.org')) as page:

which is misleading in that the object returned from urlopen
<class 'http.client.HTTPResponse'>
has __enter__ and __exit__ methods and therefore is a c.m. in itself and does not need to be wrapped in closing(). I did not really understand from your comment whether there is any need to use closing() with anything returned in urllib. 

At the moment, shelves are not C.M.s, and would make better examples, but #13896 suggests 'fixing' that also.

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

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

From report at bugs.python.org  Sat Feb  4 02:41:01 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 01:41:01 +0000
Subject: [issue13896] Make shelf instances work with 'with' as context managers
In-Reply-To: <1327749150.13.0.147725255938.issue13896@psf.upfronthosting.co.za>
Message-ID: <1328319661.52.0.163966087365.issue13896@psf.upfronthosting.co.za>


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

contextlib.closing is an adapter for using objects that have a close method but have not be modernized to be context managers by having _enter__ and __exit__ methods added. Its doc gives the example
with closing(urlopen('http://www.python.org')) as page:
This is now obsolete as the object returned is now a context manager.

A shelf instance would make a better example now, but...
I think it reasonable to update shelve.Shelf also. I believe
  def __enter__(self): return self
  def __exit__(self, e_typ, e_val, tb): self.close()
are all that are needed. (Nick, true?)

----------
nosy: +ncoghlan, terry.reedy
stage:  -> test needed
title: shelf doesn't work with 'with' -> Make shelf instances work with 'with' as context managers
type:  -> enhancement
versions: +Python 3.3

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

From report at bugs.python.org  Sat Feb  4 02:46:36 2012
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 04 Feb 2012 01:46:36 +0000
Subject: [issue13892] distutils handling of windows manifest isn't optimal
In-Reply-To: <1327698565.84.0.667656042788.issue13892@psf.upfronthosting.co.za>
Message-ID: <1328319996.3.0.123534139678.issue13892@psf.upfronthosting.co.za>


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

I thought this shouldn't be a problem - that as pythonxx.dll contains a manifest with the references and also contains hoops to ensure its "activation context" is used when loading dynamic modules, that things should work correctly.  The scenario you outline isn't that different to Python being used as a COM server - where a program like "cscript.exe", which comes with Windows but I'm pretty sure has no reference to the CRT manifest we care about, loads up a Python COM object, causing Python to be loaded and it to load extension modules - and that works correctly.

That said though, I agree it would be nice if the manifest handling was optional, but it isn't immediately clear how that could be done given how distutils is structured.  Indeed, there isn't even an obvious way to do it programatically other than by monkey-patching the compiler class.  At least if you do take the monkey-patch route, you should find it necessary to only patch one fairly small method in the class.

----------

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

From report at bugs.python.org  Sat Feb  4 02:58:13 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 01:58:13 +0000
Subject: [issue13899] re pattern r"[\A]" should work like "A" but matches
	nothing. Ditto B and Z.
In-Reply-To: <1327789733.95.0.48339527102.issue13899@psf.upfronthosting.co.za>
Message-ID: <1328320693.04.0.426159892049.issue13899@psf.upfronthosting.co.za>


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

Does anyone have regex installed, to see what it does?

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

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

From report at bugs.python.org  Sat Feb  4 03:06:33 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 02:06:33 +0000
Subject: [issue11944] Function call with * and generator hide exception raised
	by generator.
In-Reply-To: <1303952447.32.0.22528411021.issue11944@psf.upfronthosting.co.za>
Message-ID: <1328321193.06.0.211128132498.issue11944@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Function calls taking a generator as star argument can mask TypeErrors in the generator

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

From report at bugs.python.org  Sat Feb  4 03:08:31 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 02:08:31 +0000
Subject: [issue13904] Generator as *args: TypeError replaced
In-Reply-To: <1327855120.91.0.5569840716.issue13904@psf.upfronthosting.co.za>
Message-ID: <1328321311.21.0.70872020947.issue13904@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file24358/typeerror-replaced-in-stararg.diff

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

From report at bugs.python.org  Sat Feb  4 03:10:01 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 02:10:01 +0000
Subject: [issue13904] Generator as *args: TypeError replaced
In-Reply-To: <1327855120.91.0.5569840716.issue13904@psf.upfronthosting.co.za>
Message-ID: <1328321401.4.0.860155634944.issue13904@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file24358/typeerror-replaced-in-stararg.diff

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

From report at bugs.python.org  Sat Feb  4 03:11:28 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Sat, 04 Feb 2012 02:11:28 +0000
Subject: [issue13893] Make CGIHTTPServer capable of redirects (and status
	other than 200)
In-Reply-To: <1327705936.4.0.817960222769.issue13893@psf.upfronthosting.co.za>
Message-ID: <1328321488.82.0.341173778906.issue13893@psf.upfronthosting.co.za>


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

This seems related to issue 10487. Some of the code is different in Python 3.  Since this is an enhancement, it seems unlikely to ever be accepted for 2.x, which is in bugfix-only mode.

Sadly, most hosting companies are still running Python 2.x, with many as old as 2.4.

Happily, you can patch your own copy to work; I did that, for both 2.x and 3.x, and described the issues in a set of bug issues, but haven't had the time to figure out how to go through the development process and submit individual patches: my code is kind of a bundled solution to all the issues I submitted, and it doesn't seem likely that a single patch to solve all the issues would be acceptable.  I'm happy to share my code, if it would help someone generate patches.

----------
nosy: +v+python

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

From report at bugs.python.org  Sat Feb  4 03:12:56 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 02:12:56 +0000
Subject: [issue13904] Generator as *args: TypeError replaced
In-Reply-To: <1327855120.91.0.5569840716.issue13904@psf.upfronthosting.co.za>
Message-ID: <1328321576.68.0.311248096501.issue13904@psf.upfronthosting.co.za>


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

I unlinked to see if I could link it to 4806 instead. Did not work. Please nosy yourself there and upload your files to *that* issue.

----------
nosy: +terry.reedy
resolution:  -> duplicate
status: open -> closed
superseder:  -> Function calls taking a generator as star argument can mask TypeErrors in the generator
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Feb  4 03:13:17 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 02:13:17 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
	mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1328321597.42.0.193226874674.issue4806@psf.upfronthosting.co.za>


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

#13904 is another dup, with patches to test and ceval. I asked that they be reloaded to this issue.

----------
nosy: +ncoghlan
versions:  -Python 3.1

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

From report at bugs.python.org  Sat Feb  4 03:21:20 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 02:21:20 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
	mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1328322080.36.0.722062706859.issue4806@psf.upfronthosting.co.za>


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


----------
nosy: +ron_adam

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

From report at bugs.python.org  Sat Feb  4 03:27:30 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 02:27:30 +0000
Subject: [issue5218] Check for tp_iter in ceval:ext_do_call before overriding
	exception message
In-Reply-To: <1234380763.79.0.974439208897.issue5218@psf.upfronthosting.co.za>
Message-ID: <1328322450.38.0.655418987951.issue5218@psf.upfronthosting.co.za>


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

This is one of 4 duplicate issues, 3 with somewhat similar patches, with nearly disjoint nosy lists. Consolidating.

----------
nosy: +terry.reedy
resolution:  -> duplicate
status: open -> closed
superseder:  -> Function calls taking a generator as star argument can mask TypeErrors in the generator
versions: +Python 3.2, Python 3.3 -Python 3.1

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

From report at bugs.python.org  Sat Feb  4 03:28:01 2012
From: report at bugs.python.org (John Roth)
Date: Sat, 04 Feb 2012 02:28:01 +0000
Subject: [issue13915] Update Tutorial 6.1.3 for PEP 3145
In-Reply-To: <1328053198.63.0.994035147287.issue13915@psf.upfronthosting.co.za>
Message-ID: <1328322481.74.0.780663998328.issue13915@psf.upfronthosting.co.za>


John Roth <JohnRoth1 at gmail.com> added the comment:

I apologize for not submitting this in patch format, but I don't have a development system available.

I suggest replacing the entire 6.1.3 section with: 

To speed up loading modules, Python caches the compiled version of each module in the __pycache__ directory under the name module.cpython-xy.pyc, where xy is the Python version number. For example, in release 3.2 the compiled version of spam.py would be cached as __pycache__/spam.cpython-32.pyc. This naming convention allows compiled modules from different releases and different versions of Python to coexist.

Python checks the revision date of the source against the compiled version to see if it?s out of date and needs to be recompiled. This is a completely automatic process. Also, the compiled modules are platform-independent, so the same library can be shared among systems with different architectures.

Python does not check the cache in two circumstances. First, it always recompiles and does not store the result for the module that?s loaded directly from the command line. Second, it does not check the cache if there is no source module. To support a non-source (compiled only) distribution, the compiled module must be in the source directory, and there must not be a source module.

Some tips for experts:

* You can use the -O or -OO switches on the Python command to reduce the size of a compiled module. The -O switch removes assert statements, the -OO switch removes both assert statements and __doc__ strings. Neither optimization affects running time, however it?s possible that they may affect run-time behavior. Optimized modules have a .pyo rather than a .pyc suffix. Future releases may change the effects of optimization.

*   The module compileall can create .pyc files (or .pyo files when -O is used) for all modules in a directory.

*   There is more detail on this process, including a flow chart of the decisions, in PEP 3147.

----------
nosy: +JohnRoth1

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

From report at bugs.python.org  Sat Feb  4 03:28:38 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 02:28:38 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
	mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1328322518.59.0.802745114511.issue4806@psf.upfronthosting.co.za>


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

#5218 is a 4th duplicate, also with a patch to the ceval loop and test.

----------
nosy: +georg.brandl, gpolo, pitrou

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

From report at bugs.python.org  Sat Feb  4 03:31:17 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 02:31:17 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
	mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1328322677.38.0.0685960452004.issue4806@psf.upfronthosting.co.za>


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

Sorry Martin, I see you already said that. Anyway, I closed other three in favor of this one.

----------

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

From report at bugs.python.org  Sat Feb  4 03:32:54 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 02:32:54 +0000
Subject: [issue13909] Ordering of free variables in dis is dependent on dict
	ordering.
In-Reply-To: <1327879534.06.0.507724097117.issue13909@psf.upfronthosting.co.za>
Message-ID: <1328322774.73.0.959325273242.issue13909@psf.upfronthosting.co.za>


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


----------
nosy: +ncoghlan
stage:  -> test needed
versions: +Python 3.3

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

From report at bugs.python.org  Sat Feb  4 03:33:45 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 02:33:45 +0000
Subject: [issue13910] test_packaging is dependent on dict ordering.
In-Reply-To: <1327879872.45.0.0954403986846.issue13910@psf.upfronthosting.co.za>
Message-ID: <1328322825.89.0.803356641409.issue13910@psf.upfronthosting.co.za>


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


----------
nosy: +alexis, eric.araujo, tarek
stage:  -> test needed
versions: +Python 3.3

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

From report at bugs.python.org  Sat Feb  4 03:34:25 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 02:34:25 +0000
Subject: [issue13911] test_trace  depends on dict repr() ordering
In-Reply-To: <1327880152.89.0.0711859595035.issue13911@psf.upfronthosting.co.za>
Message-ID: <1328322865.17.0.357081040114.issue13911@psf.upfronthosting.co.za>


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


----------
nosy: +belopolsky
stage:  -> test needed
versions: +Python 3.3

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

From report at bugs.python.org  Sat Feb  4 03:47:13 2012
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 04 Feb 2012 02:47:13 +0000
Subject: [issue7833] bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1328323633.24.0.840832931386.issue7833@psf.upfronthosting.co.za>


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

Actually, I think this is OK - the reference to the "x86" is in the tests and those tests don't actually perform a build, just check the manifest is detected and stripped (ie, the test should still work fine on 64bit boxes).  Ideally the test could also check a manifest with a 64bit architecture, but I don't think that's really necessary...

----------

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

From report at bugs.python.org  Sat Feb  4 04:08:52 2012
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 04 Feb 2012 03:08:52 +0000
Subject: [issue13899] re pattern r"[\A]" should work like "A" but matches
	nothing. Ditto B and Z.
In-Reply-To: <1327789733.95.0.48339527102.issue13899@psf.upfronthosting.co.za>
Message-ID: <1328324932.36.0.327062416186.issue13899@psf.upfronthosting.co.za>


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

This should answer that question:

>>> re.findall(r"[\A\C]", r"\AC")
['C']
>>> regex.findall(r"[\A\C]", r"\AC")
['A', 'C']

The behaviour of regex is intended to match that of re for backwards compatibility.

----------

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

From report at bugs.python.org  Sat Feb  4 04:37:28 2012
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 04 Feb 2012 03:37:28 +0000
Subject: [issue8418] Crash 0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER on
	program exit
In-Reply-To: <1271425642.06.0.059153749397.issue8418@psf.upfronthosting.co.za>
Message-ID: <1328326648.58.0.523815434431.issue8418@psf.upfronthosting.co.za>


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

See also http://bugs.python.org/issue13038 - same exception but in a different content, but the underlying cause may be similar.

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

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

From report at bugs.python.org  Sat Feb  4 04:39:57 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 03:39:57 +0000
Subject: [issue13933] IDLE:not able to complete the hashlib module
In-Reply-To: <1328284806.31.0.442750340549.issue13933@psf.upfronthosting.co.za>
Message-ID: <1328326797.76.0.416934796475.issue13933@psf.upfronthosting.co.za>


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

Ramchandra: what OS and Python version? Please always include in reports.

I verified on win7,3.2.2, with hashlib versus itertools, idlelib, heapq, trace. (On my new machine, popup is so fast I do not need <tab>.) In fact, 'hashlib.' and <tab> results in a tab to next tab position. ^<space> to <show completions> also does not work, but it does without the '.'. Some files (only builtins?) work without being imported. Everything seemed to work the same in an edit window.

hashlib.__all__ exists as a tuple. Modules without .__all__ also work.
Both cases are handled in idlelib.AutoComplete.fetch_completions().
I see nothing strange about hashlib.

Looking at idlelib.AutoComplete.py, I see other problems to fix.

"This extension can complete either attribute names of file names."
/of/or/, but ^<sp> in name brings up globals list with cursor at closest name to what one has entered. Are these handled elsewhere?

# This string includes all chars that may be in a file name (without a path
# separator)
FILENAME_CHARS = string.ascii_letters + string.digits + os.curdir + "._~#$:-"
# This string includes all chars that may be in an identifier
ID_CHARS = string.ascii_letters + string.digits + "_"

FILENAME_CHARS looks Windows specific. Both definitions are obsolete. IDLE should not separately define such things if at all possible.

But 'hash' is not in the file and I see little specific to the text context. Without being able to insert print calls to see what is and is not executed, I have no idea how to proceed.

----------
nosy: +serwy, terry.reedy
versions: +Python 3.3

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

From report at bugs.python.org  Sat Feb  4 04:44:04 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 03:44:04 +0000
Subject: [issue13932] If some test module fails to import another module
	unittest reports a very misleading message
In-Reply-To: <1328284244.56.0.791299564661.issue13932@psf.upfronthosting.co.za>
Message-ID: <1328327044.87.0.691973871913.issue13932@psf.upfronthosting.co.za>


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


----------
components: +Tests
nosy: +ezio.melotti, michael.foord

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

From report at bugs.python.org  Sat Feb  4 05:04:36 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 04 Feb 2012 04:04:36 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1328328276.04.0.97640079608.issue1813@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Feb  4 05:40:03 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 04 Feb 2012 04:40:03 +0000
Subject: [issue13933] IDLE:not able to complete the hashlib module
In-Reply-To: <1328284806.31.0.442750340549.issue13933@psf.upfronthosting.co.za>
Message-ID: <1328330403.59.0.948443948467.issue13933@psf.upfronthosting.co.za>


Ramchandra Apte <maniandram01 at gmail.com> added the comment:

I am using Ubuntu 11.04 with Python 3.2.2 from the package reprositeries (binaries)

----------

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

From report at bugs.python.org  Sat Feb  4 05:41:12 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 04:41:12 +0000
Subject: [issue13929] fnmatch to support escape characters
In-Reply-To: <1328251823.76.0.3651219427.issue13929@psf.upfronthosting.co.za>
Message-ID: <1328330472.06.0.296320613225.issue13929@psf.upfronthosting.co.za>


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

The doc chapters are entitled "fnmatch ? Unix filename pattern matching" and "glob ? Unix style pathname pattern expansion". The first explicitly disclaims the feature you request: "Be aware there is no way to quote meta-characters.", suggests using re for anything beyond fnmatch, and shows to use .translate to make a start in doing so. For your example:

>>> re.match(r".*\[Ver\.2\].*",  "Document[Ver.2].doc")
<_sre.SRE_Match object at 0x000000000331AF38>

Indeed, fnmatch works by using translate() and re.match. What you are asking for in something in between the unix language and re. If one re feature is added, why not another?

So the scope of these modules is clearly circumscribed. I suspect their intent was to make it easy to translate unix shell scripts into Python. 
What you are asking for in something in between. If you want to pursue this, post on python-list or python-ideas to garner more support. But I anticipate rejection as not needed and contrary to intent.

Not obvious from the doc is that an unmatch '[' or ']' is escaped:
>>> name = "Document[Ver.2.doc"
>>> pattern = "*[Ver.2*"
>>> fnmatch.fnmatch(name, pattern)
True
>>> name = "DocumentVer.2].doc"
>>> pattern = "*Ver.2]*"
>>> fnmatch.fnmatch(name, pattern)
True
I presume this matches the *nix behavior, but don't know.

----------
nosy: +terry.reedy
resolution:  -> rejected
status: open -> closed
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4

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

From report at bugs.python.org  Sat Feb  4 05:56:09 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 04:56:09 +0000
Subject: [issue13899] re pattern r"[\A]" should work like "A" but matches
	nothing. Ditto B and Z.
In-Reply-To: <1327789733.95.0.48339527102.issue13899@psf.upfronthosting.co.za>
Message-ID: <1328331369.43.0.804705765042.issue13899@psf.upfronthosting.co.za>


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

I presume you intend regex to match the spec rather than bugs. So if re has a bug in an obsure corner case and the spec is ambiguous, as I have the impression is the case here, using the interpretation embodied in regex would avoid creating a conflict.

----------

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

From report at bugs.python.org  Sat Feb  4 06:31:33 2012
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 04 Feb 2012 05:31:33 +0000
Subject: [issue13938] 2to3 fails to convert types.StringTypes appropriately
Message-ID: <1328333493.54.0.112859472866.issue13938@psf.upfronthosting.co.za>


New submission from Mark Hammond <skippy.hammond at gmail.com>:

test_types.py converts "types.StringTypes" to "str" - but types.StringTypes is a tuple, so expressions like "type(x) in type.StringTypes" fails after conversion with "TypeError: argument of type 'type' is not iterable"

Attaching a fix and test.

Note that the fixer still seems "strange" after this fix - types.StringType gets converted to "bytes" but types.StringTypes uses str.  This means the expression "type.StringType in type.StringTypes" evaluates to True in 2.x but False once converted - however, that should probably be tackled in a different bug - the fact the expression now causes a TypeError once converted is more blatantly wrong and the focus of this bug.

----------
components: 2to3 (2.x to 3.x conversion tool)
files: fix_stringtypes_fixer.patch
keywords: patch
messages: 152592
nosy: mhammond
priority: normal
severity: normal
status: open
title: 2to3 fails to convert types.StringTypes appropriately
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file24415/fix_stringtypes_fixer.patch

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

From report at bugs.python.org  Sat Feb  4 07:17:51 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 04 Feb 2012 06:17:51 +0000
Subject: [issue13937] multiprocessing.ThreadPool.join() blocks indefinitely.
In-Reply-To: <1328304563.24.0.329312202759.issue13937@psf.upfronthosting.co.za>
Message-ID: <1328336271.83.0.15059612304.issue13937@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/issue13937>
_______________________________________

From report at bugs.python.org  Sat Feb  4 08:04:25 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Feb 2012 07:04:25 +0000
Subject: [issue13712] pysetup create should not convert package_data to
	extra_files
In-Reply-To: <1325689084.75.0.043764224634.issue13712@psf.upfronthosting.co.za>
Message-ID: <1328339065.3.0.393233444644.issue13712@psf.upfronthosting.co.za>


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


----------
dependencies: +package_data only allows one glob per-package

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

From report at bugs.python.org  Sat Feb  4 08:05:16 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Feb 2012 07:05:16 +0000
Subject: [issue13910] test_packaging is dependent on dict ordering.
In-Reply-To: <1327879872.45.0.0954403986846.issue13910@psf.upfronthosting.co.za>
Message-ID: <1328339116.39.0.341726705817.issue13910@psf.upfronthosting.co.za>


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

Thanks for the report; it was not obvious (due to title/scope change) that there was already one :)  I?m on this.

----------
assignee:  -> eric.araujo
resolution:  -> duplicate
stage: test needed -> committed/rejected
status: open -> closed
superseder:  -> pysetup create should not convert package_data to extra_files

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

From report at bugs.python.org  Sat Feb  4 08:11:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Feb 2012 07:11:07 +0000
Subject: [issue12955] urllib.request example should use "with ... as:"
In-Reply-To: <1315650628.73.0.673162910121.issue12955@psf.upfronthosting.co.za>
Message-ID: <1328339467.1.0.73619062067.issue12955@psf.upfronthosting.co.za>


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

Either we find a commonly used stdlib class that is not a context manager but has a close method and is not going to become a context manager (I can?t see why such a thing would be), or we can add something like: ?closing is useful with code that you can?t change to add context management, for example urllib.urlopen before Python 3.3?.

----------

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

From report at bugs.python.org  Sat Feb  4 08:18:08 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Feb 2012 07:18:08 +0000
Subject: [issue13773] Support sqlite3 uri filenames
In-Reply-To: <1326313998.63.0.583537561643.issue13773@psf.upfronthosting.co.za>
Message-ID: <1328339888.71.0.134089598636.issue13773@psf.upfronthosting.co.za>


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

[Amaury]
> The test function should use "from test.support import TESTFN" to get
> a temporary file name
I believe that TESTFN predates tempfile (and the tempfile helpers in regrtest and test.support) and is now seen as an ugly relic (at least by me :)

[poq]
>> I think the doc could link to the sqlite.org doc about URIs.
> I considered this, but the rest of the sqlite3 module documentation doesn't link to the
> sqlite.org doc pages either.
Well, users need a way to find the list of allowed options.  The Python docs should either list them (there aren?t much; pro: all the info is here, con: maintenance) or link to them.

By the way, do you want to give us your full name so that we can credit you?  (And on a related subject, I don?t know if this small patch requires a contributor agreement.)

----------

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

From report at bugs.python.org  Sat Feb  4 08:18:18 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Feb 2012 07:18:18 +0000
Subject: [issue13934] sqlite3 test typo
In-Reply-To: <1328294661.43.0.135509150445.issue13934@psf.upfronthosting.co.za>
Message-ID: <1328339898.32.0.369716246983.issue13934@psf.upfronthosting.co.za>


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


----------
assignee:  -> ghaering
keywords: +needs review
nosy: +ghaering
stage:  -> patch review
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Feb  4 08:20:08 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Feb 2012 07:20:08 +0000
Subject: [issue13879] Argparse does not support subparser aliases in 2.7
In-Reply-To: <1327597168.42.0.828007379667.issue13879@psf.upfronthosting.co.za>
Message-ID: <1328340008.07.0.314458393978.issue13879@psf.upfronthosting.co.za>


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

Ah, I did not see that your first message talked about the dev doc, which is 3.3.

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

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

From report at bugs.python.org  Sat Feb  4 08:23:53 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Feb 2012 07:23:53 +0000
Subject: [issue13893] Make CGIHTTPServer capable of redirects (and status
	other than 200)
In-Reply-To: <1327705936.4.0.817960222769.issue13893@psf.upfronthosting.co.za>
Message-ID: <1328340233.1.0.1058010641.issue13893@psf.upfronthosting.co.za>


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


----------
keywords: +needs review
stage:  -> test needed
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4

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

From report at bugs.python.org  Sat Feb  4 08:24:41 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Feb 2012 07:24:41 +0000
Subject: [issue13893] Make CGIHTTPServer capable of redirects (and status
	other than 200)
In-Reply-To: <1327705936.4.0.817960222769.issue13893@psf.upfronthosting.co.za>
Message-ID: <1328340281.23.0.742166976374.issue13893@psf.upfronthosting.co.za>


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

Can someone assess if this is actually a duplicate of #10487 or something else?  Thanks

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

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

From report at bugs.python.org  Sat Feb  4 08:25:04 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Feb 2012 07:25:04 +0000
Subject: [issue10487] http.server doesn't process Status header from CGI
	scripts
In-Reply-To: <1290325843.93.0.000870454658653.issue10487@psf.upfronthosting.co.za>
Message-ID: <1328340304.91.0.952930367152.issue10487@psf.upfronthosting.co.za>


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


----------
title: http.server - doesn't process Status: header from CGI scripts -> http.server doesn't process Status header from CGI scripts
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Sat Feb  4 08:46:16 2012
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sat, 04 Feb 2012 07:46:16 +0000
Subject: [issue13935] Tarfile - Fixed GNU tar header base-256 handling
In-Reply-To: <1328295391.26.0.207109805209.issue13935@psf.upfronthosting.co.za>
Message-ID: <1328341576.35.0.307517219402.issue13935@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/issue13935>
_______________________________________

From report at bugs.python.org  Sat Feb  4 09:05:22 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Feb 2012 08:05:22 +0000
Subject: [issue13932] If some test module fails to import another module
	unittest reports a very misleading message
In-Reply-To: <1328284244.56.0.791299564661.issue13932@psf.upfronthosting.co.za>
Message-ID: <1328342722.19.0.41806128729.issue13932@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/issue13932>
_______________________________________

From report at bugs.python.org  Sat Feb  4 09:11:28 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Feb 2012 08:11:28 +0000
Subject: [issue13929] fnmatch to support escape characters
In-Reply-To: <1328251823.76.0.3651219427.issue13929@psf.upfronthosting.co.za>
Message-ID: <1328343088.12.0.373436126489.issue13929@psf.upfronthosting.co.za>


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

> [fnmatch] explicitly disclaims the feature you request: "Be aware there is no way to quote
> meta-characters."

This reads like a warning to me, i.e. a potential future feature, not a design choice.

> What you are asking for in something in between the unix language and re. If one re
> feature is added, why not another?

When we use glob patterns in our shells, the shell language lets us escape what would otherwise be special characters.  Python would be nicer to let us do the same.

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

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

From report at bugs.python.org  Sat Feb  4 09:15:30 2012
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sat, 04 Feb 2012 08:15:30 +0000
Subject: [issue13935] Tarfile - Fixed GNU tar header base-256 handling
In-Reply-To: <1328295391.26.0.207109805209.issue13935@psf.upfronthosting.co.za>
Message-ID: <1328343330.99.0.293645514067.issue13935@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

This has been fixed (issue13158, http://hg.python.org/cpython/rev/341008eab87d). Thanks anyway for the report.

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

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

From report at bugs.python.org  Sat Feb  4 09:18:53 2012
From: report at bugs.python.org (Mark Nottingham)
Date: Sat, 04 Feb 2012 08:18:53 +0000
Subject: [issue7827] recv_into() argument 1 must be pinned buffer,
	not bytearray
In-Reply-To: <1264989221.02.0.754334241076.issue7827@psf.upfronthosting.co.za>
Message-ID: <1328343533.75.0.560432807676.issue7827@psf.upfronthosting.co.za>


Mark Nottingham <mnot at mnot.net> added the comment:

Seems to be fixed in 2.7, although I'm not sure when exactly :

Python 2.7.2 (default, Oct 21 2011, 22:13:39) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> sock = socket.socket()
>>> sock.connect( ("python.org", 80) )
>>> sock.send(b"GET / HTTP/1.0\r\n\r\n")
18
>>> buf = bytearray(b" " * 10)
>>> sock.recv_into(buf)
10
>>> print buf
HTTP/1.1 3

----------

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

From report at bugs.python.org  Sat Feb  4 09:19:16 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Feb 2012 08:19:16 +0000
Subject: [issue13923] new formatter for argparse
In-Reply-To: <1328133272.3.0.771637871025.issue13923@psf.upfronthosting.co.za>
Message-ID: <1328343556.49.0.431520798853.issue13923@psf.upfronthosting.co.za>


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

(This reminds me of another request; would you mind searching the other argparse bugs to see if this is a duplicate?  Thanks)

----------
nosy: +bethard, eric.araujo
versions: +Python 3.3

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

From report at bugs.python.org  Sat Feb  4 09:19:25 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Feb 2012 08:19:25 +0000
Subject: [issue13921] sqlite3: OptimizedUnicode obsolete in Py3k
In-Reply-To: <1328129858.32.0.164852943165.issue13921@psf.upfronthosting.co.za>
Message-ID: <1328343565.44.0.550944986354.issue13921@psf.upfronthosting.co.za>


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

I?m not sure the doc note is useful, but didn?t code search to confirm it.

Also, 3.2 may be out of bounds for this cleanup (I don?t know the rules for what can be committed in what branches these days).

----------
nosy: +eric.araujo
title: sqlite3: OptimizedUnicode doesn't work in Py3k -> sqlite3: OptimizedUnicode obsolete in Py3k

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

From report at bugs.python.org  Sat Feb  4 09:20:43 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Feb 2012 08:20:43 +0000
Subject: [issue13915] Update Tutorial 6.1.3 for PEP 3145
In-Reply-To: <1328053198.63.0.994035147287.issue13915@psf.upfronthosting.co.za>
Message-ID: <1328343643.69.0.525026687537.issue13915@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> eric.araujo
nosy: +eric.araujo

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

From report at bugs.python.org  Sat Feb  4 09:21:56 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Feb 2012 08:21:56 +0000
Subject: [issue13913] utf-8 or utf8 or utf-8 (codec display name inconsistency)
In-Reply-To: <1328030876.68.0.627537179228.issue13913@psf.upfronthosting.co.za>
Message-ID: <1328343716.49.0.165275608532.issue13913@psf.upfronthosting.co.za>


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


----------
priority: normal -> low
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Feb  4 09:22:53 2012
From: report at bugs.python.org (Mark Nottingham)
Date: Sat, 04 Feb 2012 08:22:53 +0000
Subject: [issue7827] recv_into() argument 1 must be pinned buffer,
	not bytearray
In-Reply-To: <1264989221.02.0.754334241076.issue7827@psf.upfronthosting.co.za>
Message-ID: <1328343773.56.0.864795886088.issue7827@psf.upfronthosting.co.za>


Mark Nottingham <mnot at mnot.net> added the comment:

>From the release notes, perhaps it was #8104.

----------

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

From report at bugs.python.org  Sat Feb  4 09:55:03 2012
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 04 Feb 2012 08:55:03 +0000
Subject: [issue13896] Make shelf instances work with 'with' as context managers
In-Reply-To: <1327749150.13.0.147725255938.issue13896@psf.upfronthosting.co.za>
Message-ID: <1328345703.91.0.192974717796.issue13896@psf.upfronthosting.co.za>


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

closing was solving my problem, but I'll be happy on working on this patch, if you think it's useful after all. I don't think the stage should be test needed, since the patch has tests (I know the drill here ;-)).

----------

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

From report at bugs.python.org  Sat Feb  4 10:48:53 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 09:48:53 +0000
Subject: [issue13929] fnmatch to support escape characters
In-Reply-To: <1328251823.76.0.3651219427.issue13929@psf.upfronthosting.co.za>
Message-ID: <1328348933.98.0.181099412603.issue13929@psf.upfronthosting.co.za>


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

If indeed fnmatch does not match current shells, then I would agree that it should. It looks to me so easy to add that I though it must be a deliberate decision to exclude. In translate:
...
        elif c == '\':
            if i < n-1:
                c2 = pat[i+1]
                <specify what to do for \c2 for all cases of c2>
            else:
                <specify what to do for pattern ending in '\'>
        else:  
            res = res + re.escape(c)
# the last two lines are current code, which is why '\' in patterns does not escape anything in the translated re.

Changing the meaning of '\' from ordinary character to escape char will break any code that depends on its current ordinariness.
>>> fn.fnmatch(r'\x', r'\?')
True # for x any 'ordinary' char, but not is '\?' means "match '?'.

This was another reason I closed, although I forgot to mention it. I suppose a new parameter 'escape = False' could be added to all 4 exposed functions to preserve back compatibility. Anyway, I have reopened for further discussion and specification.

----------
resolution: rejected -> 
status: closed -> open

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

From report at bugs.python.org  Sat Feb  4 10:51:16 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 09:51:16 +0000
Subject: [issue13896] Make shelf instances work with 'with' as context managers
In-Reply-To: <1327749150.13.0.147725255938.issue13896@psf.upfronthosting.co.za>
Message-ID: <1328349076.1.0.019826553701.issue13896@psf.upfronthosting.co.za>


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


----------
stage: test needed -> patch review

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

From report at bugs.python.org  Sat Feb  4 11:34:00 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 04 Feb 2012 10:34:00 +0000
Subject: [issue13937] multiprocessing.ThreadPool.join() blocks indefinitely.
In-Reply-To: <1328304563.24.0.329312202759.issue13937@psf.upfronthosting.co.za>
Message-ID: <1328351640.18.0.437303811027.issue13937@psf.upfronthosting.co.za>


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

It's a duplicate of issue #12157.

----------
nosy: +neologix
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> join method of multiprocessing Pool object hangs if iterable argument of pool.map is empty
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Feb  4 12:21:42 2012
From: report at bugs.python.org (adamhj)
Date: Sat, 04 Feb 2012 11:21:42 +0000
Subject: [issue13928] bug in asyncore.dispatcher_with_send
In-Reply-To: <1328241599.62.0.482443622644.issue13928@psf.upfronthosting.co.za>
Message-ID: <1328354502.13.0.51443470703.issue13928@psf.upfronthosting.co.za>


adamhj <adamhm at gmail.com> added the comment:

> A non connected socket must be writable in order to connect.
i can't understand this, does it means that one may use self.connect() in handle_write()? and in fact i found something seems opposite on this page: http://docs.python.org/howto/sockets.html

"If a socket is in the output readable list, you can be as-close-to-certain-as-we-ever-get-in-this-business that a recv on that socket will return something. Same idea for the writable list. You?ll be able to send something."

"If you have created a new socket to connect to someone else, put it in the potential_writers list. If it shows up in the writable list, you have a decent chance that it has connected."

from the latter paragraph may i assume that a writable socket should always has been connected?

> Not sure what you mean here. Why would you call connect() twice?
sorry for the typo, it should be "if we call dispatcher.send() immediately after .connect(), socket error 10057 may be raised", this happens if you connect to a high delay remote port, when the .send() is called before the SYN ACK is received. 

i think it maybe the programmer's responsibility to check the connection availability when using dispatcher class, but at least for dispatcher_with_send class, programmer should not need do anything special to use send() after a successful connect(), if .send() is called before connection established successfully, send() should only buffer the sending data and wait the socket to become writable

by the way, i found this behavior on windows 7 x32/python 2.7.2

----------

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

From report at bugs.python.org  Sat Feb  4 12:23:28 2012
From: report at bugs.python.org (Johannes Bauer)
Date: Sat, 04 Feb 2012 11:23:28 +0000
Subject: [issue13700] imaplib.IMAP4.authenticate authobject fails with PLAIN
	mechanism
In-Reply-To: <1325553089.14.0.504978991098.issue13700@psf.upfronthosting.co.za>
Message-ID: <1328354608.75.0.695810964899.issue13700@psf.upfronthosting.co.za>


Johannes Bauer <dfnsonfsduifb at gmx.de> added the comment:

Issue also affects Python3.1. Hunk succeeds against 3.1 imaplib.py and works for me.

----------
nosy: +joebauer
versions: +Python 3.1

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

From report at bugs.python.org  Sat Feb  4 12:31:44 2012
From: report at bugs.python.org (Jeroen)
Date: Sat, 04 Feb 2012 11:31:44 +0000
Subject: [issue13926] pydoc - stall when requesting a list of available
	modules in the online help utility
In-Reply-To: <1328312172.48.0.598520535711.issue13926@psf.upfronthosting.co.za>
Message-ID: <CA+0o7QjAAESQ7cced+Jc-FfhkNEwSuCGWQKA-Qn+hg2qSKcdrw@mail.gmail.com>


Jeroen <dariojee at gmail.com> added the comment:

Ned,

I've run the "help()" from the command-line as requested and the result was:

Python 2.7.2+ (default, Oct  4 2011, 20:06:09)
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> help()

Welcome to Python 2.7!  This is the online help utility.

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://docs.python.org/tutorial/.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To quit this help utility and
return to the interpreter, just type "quit".

To get a list of available modules, keywords, or topics, type "modules",
"keywords", or "topics".  Each module also comes with a one-line summary
of what it does; to list the modules whose summaries contain a given word
such as "spam", type "modules spam".

help> modules

Please wait a moment while I gather a list of all available modules...

/usr/lib/python2.7/dist-packages/gobject/constants.py:24: Warning:
g_boxed_type_register_static: assertion `g_type_from_name (name) == 0'
failed
  import gobject._gobject
/usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:40: Warning:
g_boxed_type_register_static: assertion `g_type_from_name (name) == 0'
failed
  from gtk import _gtk

** (python:2050): CRITICAL **: pyg_register_boxed: assertion `boxed_type !=
0' failed
/usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:40: Warning:
cannot register existing type `GdkDevice'
  from gtk import _gtk
/usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:40: Warning:
g_type_get_qdata: assertion `node != NULL' failed
  from gtk import _gtk
Segmentation fault

2012/2/4 Ned Deily <report at bugs.python.org>

>
> Ned Deily <nad at acm.org> added the comment:
>
> Jeroen, if you try running "help()" from a command-line python2.7, rather
> than in IDLE, what results do you get?  Most likely, Python will crash
> there and there should be an exception and traceback printed, in which case
> the problem has nothing to do with IDLE directly.  Note that there have
> been some improvements to pydoc's robustness since 2.7.2 was released (for
> instance, the changes for issue7425 and issue7367).
>
> (Terry, are you sure you meant Issue12092?)
>
> ----------
> nosy: +ned.deily
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13926>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sat Feb  4 12:42:30 2012
From: report at bugs.python.org (brian baker)
Date: Sat, 04 Feb 2012 11:42:30 +0000
Subject: [issue13939] excessive cpu usage
Message-ID: <1328355750.52.0.65922609962.issue13939@psf.upfronthosting.co.za>


New submission from brian baker <brian.m.baker at gmail.com>:

python causing one of my dual core cpu's to run @ 100% running ubuntu 12.04 with gnome-shell 3.3.4

----------
components: None
messages: 152610
nosy: brian-m-baker
priority: normal
severity: normal
status: open
title: excessive cpu usage
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Sat Feb  4 12:45:36 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 04 Feb 2012 11:45:36 +0000
Subject: [issue13939] excessive cpu usage
In-Reply-To: <1328355750.52.0.65922609962.issue13939@psf.upfronthosting.co.za>
Message-ID: <1328355936.22.0.788319418336.issue13939@psf.upfronthosting.co.za>


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

Hello,
i'm sorry but this is not the right place for this report. Please refer to ubuntu or gnome user support forum for help.

Sandro

----------
nosy: +sandro.tosi
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Feb  4 12:45:52 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 04 Feb 2012 11:45:52 +0000
Subject: [issue13939] excessive cpu usage
In-Reply-To: <1328355750.52.0.65922609962.issue13939@psf.upfronthosting.co.za>
Message-ID: <1328355952.38.0.877263326969.issue13939@psf.upfronthosting.co.za>


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


----------
components:  -None
versions:  -Python 2.7

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

From report at bugs.python.org  Sat Feb  4 12:55:08 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 04 Feb 2012 11:55:08 +0000
Subject: [issue12157] join method of multiprocessing Pool object hangs if
	iterable argument of pool.map is empty
In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>
Message-ID: <1328356508.29.0.388361882302.issue12157@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/issue12157>
_______________________________________

From report at bugs.python.org  Sat Feb  4 13:04:58 2012
From: report at bugs.python.org (Johannes Bauer)
Date: Sat, 04 Feb 2012 12:04:58 +0000
Subject: [issue13940] imaplib: Mailbox names are not quoted
Message-ID: <1328357098.01.0.78801274991.issue13940@psf.upfronthosting.co.za>


New submission from Johannes Bauer <dfnsonfsduifb at gmx.de>:

imaplib does not qupote mailbox names when it's sending it's query to the server in response to a status request, for example. This will lead to very strange errors if mailboxes are accessed which contain spaces:

i.e.

connection.status("mailbox name", "(MESSAGES)")

will return

  File "/home/joe/test/imaplib.py", line 920, in _command_complete
    raise self.error('%s command error: %s %s' % (name, typ, data))
imaplib.error: STATUS command error: BAD [b'Error in IMAP command STATUS: Status items must be list.']

which indicates that the error is within the actual flag list. It is not, however:

connection.status("\"mailbox name\"", "(MESSAGES)")

works as expected. This may arguably be or not be a bug -- however it is REALLY confusing to the user. Maybe at least a note should be included somewhere that -- just to be safe -- mailbox names should be quoted.

All the best,
Joe

----------
components: Library (Lib)
messages: 152612
nosy: joebauer
priority: normal
severity: normal
status: open
title: imaplib: Mailbox names are not quoted
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sat Feb  4 13:20:42 2012
From: report at bugs.python.org (Warren Turkal)
Date: Sat, 04 Feb 2012 12:20:42 +0000
Subject: [issue13923] new formatter for argparse
In-Reply-To: <1328133272.3.0.771637871025.issue13923@psf.upfronthosting.co.za>
Message-ID: <1328358042.12.0.196828767693.issue13923@psf.upfronthosting.co.za>


Warren Turkal <wt at penguintechs.org> added the comment:

[1] sounds somewhere related and more complicated than what I was asking for. I would think that it would need to wrap bulleted lists in a sane way in addition to what I asked for here.

Also, [1] seems to apply to the option help text, where this request applies to the prolog and epilog. Although, it really makes sense to me for the formatter to format all the text bits similarly.

[1]http://bugs.python.org/issue12806

----------

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

From report at bugs.python.org  Sat Feb  4 13:31:54 2012
From: report at bugs.python.org (Manish Mishra)
Date: Sat, 04 Feb 2012 12:31:54 +0000
Subject: [issue13941] Your Python may not be configured for Tk
Message-ID: <1328358714.03.0.716590047445.issue13941@psf.upfronthosting.co.za>


New submission from Manish Mishra <yogmaya at rediffmail.com>:

I am trying to install Python3.2.2 on Ubuntu 11.10.  I downloaded the tar file. Then as per readme file did ./configure , make, make test, and then  sudo make install.  When ?make? command is issued following appears along with many other messages 

Python build finished, but the necessary bits to build these modules were not found:
_curses            _curses_panel      _dbm            
_gdbm              _sqlite3           _ssl            
_tkinter           bz2                readline        
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

Now after final installation when I run idle following message appears 

** IDLE can't import Tkinter.  Your Python may not be configured for Tk. **

I tried ?sudo apt-get install python3-tk? and got following message
python3-tk is already the newest version.

I am new to programming and ubuntu both. Please Help.
Thanks n regards.

----------
components: Tkinter
messages: 152614
nosy: manish671
priority: normal
severity: normal
status: open
title: Your Python may not be configured for Tk
versions: Python 3.2

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

From report at bugs.python.org  Sat Feb  4 13:36:24 2012
From: report at bugs.python.org (Giovanni Funchal)
Date: Sat, 04 Feb 2012 12:36:24 +0000
Subject: [issue13893] Make CGIHTTPServer capable of redirects (and status
	other than 200)
In-Reply-To: <1327705936.4.0.817960222769.issue13893@psf.upfronthosting.co.za>
Message-ID: <1328358984.56.0.496566184436.issue13893@psf.upfronthosting.co.za>


Giovanni Funchal <gafunchal at gmail.com> added the comment:

@Glenn Linderman, can you please share your changes? You can upload a patch.

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

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

From report at bugs.python.org  Sat Feb  4 13:39:42 2012
From: report at bugs.python.org (Giovanni Funchal)
Date: Sat, 04 Feb 2012 12:39:42 +0000
Subject: [issue13893] Make CGIHTTPServer capable of redirects (and status
	other than 200)
In-Reply-To: <1327705936.4.0.817960222769.issue13893@psf.upfronthosting.co.za>
Message-ID: <1328359182.17.0.634611920057.issue13893@psf.upfronthosting.co.za>


Giovanni Funchal <gafunchal at gmail.com> added the comment:

@?ric Araujo, yes this is a duplicate of #10487. I now think this should be marked as bug instead of enhancement. The documentation warns about this behavior but it is documenting a bug.

----------
resolution:  -> duplicate

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

From report at bugs.python.org  Sat Feb  4 13:58:50 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 04 Feb 2012 12:58:50 +0000
Subject: [issue8184] multiprocessing.managers will not fail if listening ocket
	already in use
In-Reply-To: <1326308937.3531.24.camel@localhost.localdomain>
Message-ID: <CAH_1eM2m-Z5r=8cZLU8g67p7ssQVapbaUG43Pu4CHNm=b7W3jw@mail.gmail.com>


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

> Well it would probably be closed when the connection object is
> destroyed, but the patch looks ok anyway.

Let's be nice with those non refcount-based implementations out there :-)

What do you think of the patch attached
(connection_multiple_bind-1.diff) for the original problem?
It does two things:
1. add the FILE_FLAG_FIRST_PIPE_INSTANCE when creating a pipe on Windows
2. remove SO_REUSEADDR altogether on Windows, since it doesn't seem to
be required

For 2, it should be correct if I understand Microsoft's documentation
correctly, but then I wonder why test.support goes through the pain of
using SO_REUSEADDR + SO_EXCLUSIVEADDRUSE instead of just dropping
SO_REUSEADDR. Do you happen to know a Windows guru (or maybe should I
ask on python-dev?).

----------
Added file: http://bugs.python.org/file24416/connection_multiple_bind-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8184>
_______________________________________
-------------- next part --------------
diff --git a/Lib/multiprocessing/connection.py b/Lib/multiprocessing/connection.py
--- a/Lib/multiprocessing/connection.py
+++ b/Lib/multiprocessing/connection.py
@@ -544,7 +544,8 @@
             obsize, ibsize = 0, BUFSIZE
 
         h1 = win32.CreateNamedPipe(
-            address, openmode | win32.FILE_FLAG_OVERLAPPED,
+            address, openmode | win32.FILE_FLAG_OVERLAPPED |
+            win32.FILE_FLAG_FIRST_PIPE_INSTANCE,
             win32.PIPE_TYPE_MESSAGE | win32.PIPE_READMODE_MESSAGE |
             win32.PIPE_WAIT,
             1, obsize, ibsize, win32.NMPWAIT_WAIT_FOREVER, win32.NULL
@@ -576,7 +577,10 @@
     def __init__(self, address, family, backlog=1):
         self._socket = socket.socket(getattr(socket, family))
         try:
-            self._socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
+            # SO_REUSEADDR has different semantics on Windows (issue #8184). 
+            if os.name == 'posix':
+                self._socket.setsockopt(socket.SOL_SOCKET,
+                                        socket.SO_REUSEADDR, 1)
             self._socket.bind(address)
             self._socket.listen(backlog)
             self._address = self._socket.getsockname()
@@ -630,7 +634,8 @@
         def __init__(self, address, backlog=None):
             self._address = address
             handle = win32.CreateNamedPipe(
-                address, win32.PIPE_ACCESS_DUPLEX,
+                address, win32.PIPE_ACCESS_DUPLEX |
+                win32.FILE_FLAG_FIRST_PIPE_INSTANCE,
                 win32.PIPE_TYPE_MESSAGE | win32.PIPE_READMODE_MESSAGE |
                 win32.PIPE_WAIT,
                 win32.PIPE_UNLIMITED_INSTANCES, BUFSIZE, BUFSIZE,
diff --git a/Lib/test/test_multiprocessing.py b/Lib/test/test_multiprocessing.py
--- a/Lib/test/test_multiprocessing.py
+++ b/Lib/test/test_multiprocessing.py
@@ -1738,6 +1738,17 @@
         self.assertRaises(RuntimeError, reduction.recv_handle, conn)
         p.join()
 
+class _TestListener(BaseTestCase):
+
+    ALLOWED_TYPES = ('processes')
+
+    def test_multiple_bind(self):
+        for family in self.connection.families:
+            l = self.connection.Listener(family=family)
+            self.addCleanup(l.close)
+            self.assertRaises(OSError, self.connection.Listener,
+                              l.address, family)
+
 class _TestListenerClient(BaseTestCase):
 
     ALLOWED_TYPES = ('processes', 'threads')
@@ -1758,6 +1769,7 @@
             self.assertEqual(conn.recv(), 'hello')
             p.join()
             l.close()
+
 #
 # Test of sending connection and socket objects between processes
 #
diff --git a/Modules/_multiprocessing/win32_functions.c b/Modules/_multiprocessing/win32_functions.c
--- a/Modules/_multiprocessing/win32_functions.c
+++ b/Modules/_multiprocessing/win32_functions.c
@@ -771,6 +771,7 @@
     WIN32_CONSTANT(F_DWORD, ERROR_PIPE_CONNECTED);
     WIN32_CONSTANT(F_DWORD, ERROR_SEM_TIMEOUT);
     WIN32_CONSTANT(F_DWORD, FILE_FLAG_OVERLAPPED);
+    WIN32_CONSTANT(F_DWORD, FILE_FLAG_FIRST_PIPE_INSTANCE);
     WIN32_CONSTANT(F_DWORD, GENERIC_READ);
     WIN32_CONSTANT(F_DWORD, GENERIC_WRITE);
     WIN32_CONSTANT(F_DWORD, INFINITE);

From report at bugs.python.org  Sat Feb  4 14:00:02 2012
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 04 Feb 2012 13:00:02 +0000
Subject: [issue13928] bug in asyncore.dispatcher_with_send
In-Reply-To: <1328241599.62.0.482443622644.issue13928@psf.upfronthosting.co.za>
Message-ID: <1328360402.05.0.72883378817.issue13928@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> i can't understand this, does it means that one may use 
> self.connect() in handle_write()? 

Nope. When handle_write() is called you are supposed to be *already* connected, hence there's no point in calling connect() again. 
This is clear if you look at handle_write_event method or read asyncore doc.



> "If it shows up in the writable list, you have a decent 
> "chance that it has connected."
> from the latter paragraph may i assume that a writable 
> socket should always has been connected?

Nope. It means that *before* showing up the socket was *not* connected.


> if we call dispatcher.send() immediately after .connect(), 
> socket error 10057 may be raised",

Of course it does: you're not connected yet (10057 = WSAENOTCONN). 
You're supposed to use send() in handle_connect(), when the connection has already been established.
This:

     self.connect()
     self.send('hello')

...is not asyncore is supposed to be used.

----------

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

From report at bugs.python.org  Sat Feb  4 14:00:17 2012
From: report at bugs.python.org (adamhj)
Date: Sat, 04 Feb 2012 13:00:17 +0000
Subject: [issue13928] bug in asyncore.dispatcher_with_send
In-Reply-To: <1328241599.62.0.482443622644.issue13928@psf.upfronthosting.co.za>
Message-ID: <1328360417.67.0.777212740465.issue13928@psf.upfronthosting.co.za>


adamhj <adamhm at gmail.com> added the comment:

here is a script emulating what is happened in dispatcher class when the second bug triggered. you can use either a non-exist host/port, or a high delay remote port as target(see the comments in the script) and you may use a sniffer(tcpdump/wireshark e.g.) with the script to see what is happen

----------
Added file: http://bugs.python.org/file24417/bug-emu.py

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

From report at bugs.python.org  Sat Feb  4 14:26:11 2012
From: report at bugs.python.org (Omega Weapon)
Date: Sat, 04 Feb 2012 13:26:11 +0000
Subject: [issue444582] Finding programs in PATH, adding shutil.which
Message-ID: <1328361971.12.0.941992244963.issue444582@psf.upfronthosting.co.za>


Changes by Omega Weapon <OmegaPhil+Python.Bugs at gmail.com>:


----------
nosy: +Omega_Weapon

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

From report at bugs.python.org  Sat Feb  4 14:31:33 2012
From: report at bugs.python.org (adamhj)
Date: Sat, 04 Feb 2012 13:31:33 +0000
Subject: [issue13928] bug in asyncore.dispatcher_with_send
In-Reply-To: <1328241599.62.0.482443622644.issue13928@psf.upfronthosting.co.za>
Message-ID: <1328362293.2.0.214016127596.issue13928@psf.upfronthosting.co.za>


adamhj <adamhm at gmail.com> added the comment:

ah just ignore my previous msg as i post it without seeing yours.

> Nope. It means that *before* showing up the socket was *not* connected.
ok, i read more in the asyncore source and finally understand what do you mean by "A non connected socket must be writable in order to connect". i think this is a little confusing if without any explaining, shouldn't this be written into the asyncore reference page as both readable() and writable() may be override by user?

> Of course it does: you're not connected yet (10057 = WSAENOTCONN). 
> You're supposed to use send() in handle_connect(), when the connection has already been established.
> This:
>
>     self.connect()
>     self.send('hello')
>
> ...is not asyncore is supposed to be used.

oh it seems i forgot handle_connect(), thank you for your patient explanation and sorry to have troubled you. i think there is no problem anymore

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

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

From report at bugs.python.org  Sat Feb  4 14:38:21 2012
From: report at bugs.python.org (weary)
Date: Sat, 04 Feb 2012 13:38:21 +0000
Subject: [issue13942] ssl.wrap_socket does not work on socket.socketpair()'s
Message-ID: <1328362701.19.0.854143759056.issue13942@psf.upfronthosting.co.za>


New submission from weary <bugs.python at weary.nl>:

ssl.wrap_socket does not work on socket.socketpair()'s

note, this is the same as issue 1552, but for python 2.7. Also, the supplied patch does not work (patch results in: TypeError: must be _socket.socket, not _socketobject)


>>> import ssl
>>> import socket
>>> s1, s2 = socket.socketpair()
>>> ssl.wrap_socket(s1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/ssl.py", line 372, in wrap_socket
    ciphers=ciphers)
  File "/usr/lib/python2.7/ssl.py", line 105, in __init__
    socket.__init__(self, _sock=sock._sock)
AttributeError: '_socket.socket' object has no attribute '_sock'

----------
components: IO
messages: 152621
nosy: weary
priority: normal
severity: normal
status: open
title: ssl.wrap_socket does not work on socket.socketpair()'s
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Feb  4 14:42:44 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 04 Feb 2012 13:42:44 +0000
Subject: [issue13942] ssl.wrap_socket does not work on socket.socketpair()'s
In-Reply-To: <1328362701.19.0.854143759056.issue13942@psf.upfronthosting.co.za>
Message-ID: <1328362964.28.0.639080412795.issue13942@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Feb  4 15:13:11 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 04 Feb 2012 14:13:11 +0000
Subject: [issue8184] multiprocessing.managers will not fail if listening ocket
	already in use
In-Reply-To: <1269104932.24.0.802901286813.issue8184@psf.upfronthosting.co.za>
Message-ID: <E1RtgMY-0007Hv-AD@dinsdale.python.org>


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

New changeset 887d0ab5fb97 by Charles-Fran?ois Natali in branch '2.7':
Issue #8184: Fix a potential file descriptor leak when a
http://hg.python.org/cpython/rev/887d0ab5fb97

New changeset ba1e0a1ac5b7 by Charles-Fran?ois Natali in branch '3.2':
Issue #8184: Fix a potential file descriptor leak when a
http://hg.python.org/cpython/rev/ba1e0a1ac5b7

New changeset cca40a0ecffa by Charles-Fran?ois Natali in branch 'default':
Issue #8184: Fix a potential file descriptor leak when a
http://hg.python.org/cpython/rev/cca40a0ecffa

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

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

From report at bugs.python.org  Sat Feb  4 15:43:41 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 04 Feb 2012 14:43:41 +0000
Subject: [issue13941] Your Python may not be configured for Tk
In-Reply-To: <1328358714.03.0.716590047445.issue13941@psf.upfronthosting.co.za>
Message-ID: <1328366621.19.0.674574395086.issue13941@psf.upfronthosting.co.za>


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

Hi, the bug tracker is not here to receive help. Please ask your questions on the python-list mailing list.
This said, since you have already installed the packages "python3-tk" and "python3", so you could as well install "idle3" and use it...

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Sat Feb  4 15:51:07 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 04 Feb 2012 14:51:07 +0000
Subject: [issue13806] Audioop decompression frames size check fix
In-Reply-To: <1326813825.38.0.418557281447.issue13806@psf.upfronthosting.co.za>
Message-ID: <1328367067.53.0.294686100364.issue13806@psf.upfronthosting.co.za>


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

This broke a sparc buildbot:
"""

======================================================================
FAIL: test_alaw2lin (test.test_audioop.TestAudioop)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/2.7.loewis-sun/build/Lib/test/test_audioop.py", line 114, in test_alaw2lin
    self.assertEqual(audioop.alaw2lin(d, 2), b'\x08\x00\x08\x01\x10\x02')
AssertionError: '\x00\x08\x01\x08\x02\x10' != '\x08\x00\x08\x01\x10\x02'

======================================================================
FAIL: test_ulaw2lin (test.test_audioop.TestAudioop)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/2.7.loewis-sun/build/Lib/test/test_audioop.py", line 127, in test_ulaw2lin
    self.assertEqual(audioop.ulaw2lin(d, 2), b'\x00\x00\x04\x01\x0c\x02')
AssertionError: '\x00\x00\x01\x04\x02\x0c' != '\x00\x00\x04\x01\x0c\x02'
"""

It's obviously an endianess issue (sparc is big endian).

----------
nosy: +neologix
status: closed -> open

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

From report at bugs.python.org  Sat Feb  4 16:10:11 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 04 Feb 2012 15:10:11 +0000
Subject: [issue13878] test_sched failures on Windows buildbot
In-Reply-To: <1327597038.78.0.0899603043053.issue13878@psf.upfronthosting.co.za>
Message-ID: <1328368211.14.0.106052430413.issue13878@psf.upfronthosting.co.za>


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

"""
for x in [0.05, 0.04, 0.03, 0.02, 0.01]:
    z = scheduler.enter(x, 1, fun, (x,))
"""

Since the test uses relative times, if the process is preempted more than 0.01s between two calls to enter (or if the clock goes backwards), the absolute times won't be monotonic:

time.time() -> t
scheduler.enter(0.05, 1, fun, (0.05,)) -> scheduler.enterabs(t+0.05, 1, fun, (0,))
<preempted for 0.02s/clock goes backwards>
time.time() -> t+0.02
scheduler.enter(0.04, 1, fun, (0.04,)) -> scheduler.enterabs(t+0.02+0.04=t+0.06, 1, fun, (0,))
and 0.04 would end up after 0.05 in the queue.

Changing the sequence for [0.5, 0.4, 0.3, 0.2, 0.1] should make the test more robust (other tests seem to have the same problem).

----------
nosy: +neologix

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

From report at bugs.python.org  Sat Feb  4 16:34:14 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Feb 2012 15:34:14 +0000
Subject: [issue13942] ssl.wrap_socket does not work on socket.socketpair()'s
In-Reply-To: <1328362701.19.0.854143759056.issue13942@psf.upfronthosting.co.za>
Message-ID: <1328369654.77.0.835366798566.issue13942@psf.upfronthosting.co.za>


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

It's more of an enhancement than a bug (wrap_socket is not documented to work with all kinds of sockets), and 2.7 is in bugfix mode. I'd rather close this as won't fix.

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

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

From report at bugs.python.org  Sat Feb  4 16:46:59 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 04 Feb 2012 15:46:59 +0000
Subject: [issue13806] Audioop decompression frames size check fix
In-Reply-To: <1326813825.38.0.418557281447.issue13806@psf.upfronthosting.co.za>
Message-ID: <E1RthpJ-0005dT-WB@dinsdale.python.org>


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

New changeset bc6e768de2cc by Antoine Pitrou in branch '2.7':
Fix failing test on big-endian machines (issue #13806).
http://hg.python.org/cpython/rev/bc6e768de2cc

----------

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

From report at bugs.python.org  Sat Feb  4 16:52:13 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 04 Feb 2012 15:52:13 +0000
Subject: [issue13806] Audioop decompression frames size check fix
In-Reply-To: <1326813825.38.0.418557281447.issue13806@psf.upfronthosting.co.za>
Message-ID: <E1RthuK-0006Kj-S5@dinsdale.python.org>


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

New changeset cfbd800af3a4 by Antoine Pitrou in branch '3.2':
Fix failing test on big-endian machines (issue #13806).
http://hg.python.org/cpython/rev/cfbd800af3a4

New changeset 05b40b006565 by Antoine Pitrou in branch 'default':
Fix failing test on big-endian machines (issue #13806).
http://hg.python.org/cpython/rev/05b40b006565

----------

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

From report at bugs.python.org  Sat Feb  4 16:52:39 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Feb 2012 15:52:39 +0000
Subject: [issue13806] Audioop decompression frames size check fix
In-Reply-To: <1326813825.38.0.418557281447.issue13806@psf.upfronthosting.co.za>
Message-ID: <1328370759.64.0.0596232474239.issue13806@psf.upfronthosting.co.za>


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

Will wait for the buildbot to clear.

----------

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

From report at bugs.python.org  Sat Feb  4 16:54:13 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Feb 2012 15:54:13 +0000
Subject: [issue8418] Crash 0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER on
	program exit
In-Reply-To: <1271425642.06.0.059153749397.issue8418@psf.upfronthosting.co.za>
Message-ID: <1328370853.03.0.592579353446.issue8418@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/issue8418>
_______________________________________

From report at bugs.python.org  Sat Feb  4 17:09:55 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 04 Feb 2012 16:09:55 +0000
Subject: [issue13880] pydoc -k throws "AssertionError: distutils has already
	been patched by <class py2exe.Distribution at 0x0000000005987408>"
In-Reply-To: <1327606468.69.0.0708132604727.issue13880@psf.upfronthosting.co.za>
Message-ID: <1328371795.94.0.984698164021.issue13880@psf.upfronthosting.co.za>


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

I believe this problem has been fixed by the changes for Issue7425 which will be released in the next updates of Python 2.7 (2.7.3) and 3 (3.2.3).

----------
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Improve the robustness of "pydoc -k" in the face of broken modules

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

From report at bugs.python.org  Sat Feb  4 17:13:32 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 04 Feb 2012 16:13:32 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1328372012.27.0.364155210744.issue2377@psf.upfronthosting.co.za>


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

OK, I'm down to a single bug to be solved to call this work a "success" (there are other test failures, but they are not overtly difficult to solve).

At this point the bootstrapping is failing in the face of sub-interpreters. Specifically, when I try to load the frozen importlib code in Py_NewInterpreter() it leads to an assertion failure in the GC code when handling references in a GC generation. I have zero experience with sub-interpreters and my GC experience is rusty, so if anyone can have a look at the code I would appreciate it to see if they can figure out why loading a frozen module (while in marshal) is leading to a GC assertion error.

----------

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

From report at bugs.python.org  Sat Feb  4 17:14:33 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 04 Feb 2012 16:14:33 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1328372073.06.0.809480583266.issue2377@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file24418/f0b459af26fb.diff

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

From report at bugs.python.org  Sat Feb  4 17:22:33 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 04 Feb 2012 16:22:33 +0000
Subject: [issue13926] pydoc - stall when requesting a list of available
	modules in the online help utility
In-Reply-To: <CA+0o7Qhzry+gjk3dwLqwtvckxKq=QpDeg-84po9Ve-fHsn-boQ@mail.gmail.com>
Message-ID: <1328372553.55.0.676763606778.issue13926@psf.upfronthosting.co.za>


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

Thanks for the additional output.  It demonstrates that the problem you've encountered is an old known issue with pydoc help when there are modules that cause exceptions upon importing.  And the additional issue Roger brought up is also due to pydoc importing modules.  Neither of these is specific to IDLE environments.  There are a number of open duplicate and/or closely related issues on the bug tracker, including #12901, #10060, and #11995.  Let's move further discussion to one of those.

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

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

From report at bugs.python.org  Sat Feb  4 17:28:02 2012
From: report at bugs.python.org (Roger Serwy)
Date: Sat, 04 Feb 2012 16:28:02 +0000
Subject: [issue13933] IDLE:not able to complete the hashlib module
In-Reply-To: <1328284806.31.0.442750340549.issue13933@psf.upfronthosting.co.za>
Message-ID: <1328372882.92.0.0357475680349.issue13933@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Attached is a patch against 3.3a0 to fix the problem. The cause of the bug is that a tuple can not be sorted and calling .sort was raising a silenced exception. The patch explicitly converts __all__ to a list.

----------
keywords: +patch
Added file: http://bugs.python.org/file24419/issue13933.patch

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

From report at bugs.python.org  Sat Feb  4 17:49:36 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 04 Feb 2012 16:49:36 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1328374176.62.0.0262442410006.issue13241@psf.upfronthosting.co.za>


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

While the full regression testing of all active branches against all of the current compiler versions is in progress, my current (and preliminary) recommendations (despite some test failures):

- for OS X 10.7.x, use the latest released Xcode, currently Xcode 4.2.1, 
and build with clang and debug:

./configure --with-pydebug CC=clang MACOSX_DEPLOYMENT_TARGET=10.7

- for OS X 10.6.x, if possible, continue to use the last released Xcode 
3.2 (3.2.6), which includes Apple gcc-4.2 (/usr/bin/gcc-4.2 not 
llvm-gcc-4.2)

/usr/bin/gcc-4.2 --version
./configure MACOSX_DEPLOYMENT_TARGET=10.6
or
./configure --with-pydebug MACOSX_DEPLOYMENT_TARGET=10.6

- for OS X 10.6.x with Xcode 4 installed (which does not include Apple 
gcc-4.2), use the latest Xcode 4.2 for 10.6 and use clang and debug:

./configure --with-pydebug CC=clang MACOSX_DEPLOYMENT_TARGET=10.6


More results and fixes to follow ...

BTW, the current test failures with clang without pydebug include a 
number of ctypes test failures (in ctypes.test.test_cfuncs.CFunctions).  
If anyone has time to further investigate those, it would be very 
helpful (Issue13370).

----------
stage:  -> test needed

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

From report at bugs.python.org  Sat Feb  4 18:38:46 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 04 Feb 2012 17:38:46 +0000
Subject: [issue13933] IDLE:not able to complete the hashlib module
In-Reply-To: <1328284806.31.0.442750340549.issue13933@psf.upfronthosting.co.za>
Message-ID: <E1RtjZU-0007k4-Q9@dinsdale.python.org>


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

New changeset 741d4aaf7947 by Ned Deily in branch '2.7':
Issue #13933: IDLE auto-complete did not work with some imported
http://hg.python.org/cpython/rev/741d4aaf7947

New changeset 3e9a7fdf0498 by Ned Deily in branch '3.2':
Issue #13933: IDLE auto-complete did not work with some imported
http://hg.python.org/cpython/rev/3e9a7fdf0498

New changeset 443772a82dcd by Ned Deily in branch 'default':
Issue #13933: merge
http://hg.python.org/cpython/rev/443772a82dcd

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

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

From report at bugs.python.org  Sat Feb  4 18:40:12 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 04 Feb 2012 17:40:12 +0000
Subject: [issue13933] IDLE:not able to complete the hashlib module
In-Reply-To: <1328284806.31.0.442750340549.issue13933@psf.upfronthosting.co.za>
Message-ID: <1328377212.92.0.930662946736.issue13933@psf.upfronthosting.co.za>


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

Roger's patch solves the problem.  Thanks!  Applied to 2.7 (for 2.7.3), 3.2 (for 3.2.3), and default (for 3.3).

----------
nosy: +ned.deily
resolution:  -> fixed
stage:  -> committed/rejected

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

From report at bugs.python.org  Sat Feb  4 18:40:32 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 04 Feb 2012 17:40:32 +0000
Subject: [issue13933] IDLE:not able to complete the hashlib module
In-Reply-To: <1328284806.31.0.442750340549.issue13933@psf.upfronthosting.co.za>
Message-ID: <1328377232.91.0.215176396707.issue13933@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Feb  4 18:53:51 2012
From: report at bugs.python.org (Andrew Dalke)
Date: Sat, 04 Feb 2012 17:53:51 +0000
Subject: [issue7827] recv_into() argument 1 must be pinned buffer,
	not bytearray
In-Reply-To: <1264989221.02.0.754334241076.issue7827@psf.upfronthosting.co.za>
Message-ID: <1328378031.36.0.430578489279.issue7827@psf.upfronthosting.co.za>


Andrew Dalke <dalke at dalkescientific.com> added the comment:

It does look like #8104 resolved it. I tested on 2.7.2 and verified that it's no longer a problem, so I moved this to "closed/duplicate".

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

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

From report at bugs.python.org  Sat Feb  4 18:56:43 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Feb 2012 17:56:43 +0000
Subject: [issue13806] Audioop decompression frames size check fix
In-Reply-To: <1326813825.38.0.418557281447.issue13806@psf.upfronthosting.co.za>
Message-ID: <1328378203.44.0.0279015749896.issue13806@psf.upfronthosting.co.za>


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

The fix I committed seems ok. Unfortunately the buildbot doesn't compile 3.2 or 3.3, see #13843.

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

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

From report at bugs.python.org  Sat Feb  4 19:37:26 2012
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 04 Feb 2012 18:37:26 +0000
Subject: [issue13899] re pattern r"[\A]" should work like "A" but matches
	nothing. Ditto B and Z.
In-Reply-To: <1327789733.95.0.48339527102.issue13899@psf.upfronthosting.co.za>
Message-ID: <1328380646.34.0.0881770948178.issue13899@psf.upfronthosting.co.za>


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

In re, "\A" within a character set should be similar to "\C", but instead it's still interpreted as meaning the start of the string. That's definitely a bug.

If it doesn't do what it's supposed to do, then it's a bug.

regex tries to be backwards compatible with re but fix such bugs.

The only buggy behaviour which it retains in its version 0 (compatible) behaviour is not splitting on a zero-width match, and that's only because GvR believes that some existing code which uses re may rely on that behaviour. In its version 1 (extended) behaviour it does split on a zero-width match.

----------

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

From report at bugs.python.org  Sat Feb  4 19:51:51 2012
From: report at bugs.python.org (poq)
Date: Sat, 04 Feb 2012 18:51:51 +0000
Subject: [issue13773] Support sqlite3 uri filenames
In-Reply-To: <1326313998.63.0.583537561643.issue13773@psf.upfronthosting.co.za>
Message-ID: <1328381511.3.0.401064347581.issue13773@psf.upfronthosting.co.za>


poq <poq at gmx.com> added the comment:

> The Python docs should either list them (there aren?t much; pro: all the info is here, con: maintenance) or link to them.

They've already added a new option ('psow') since I opened this report, so linking is probably more future-proof.

I've added an updated patch which adds a link. I've also changed the exception when URIs are not supported to sqlite3.NotSupportedError.

> By the way, do you want to give us your full name so that we can credit you?

I prefer anonymity. :)

----------
Added file: http://bugs.python.org/file24420/sqlite-uri.v3.patch

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

From report at bugs.python.org  Sat Feb  4 20:28:42 2012
From: report at bugs.python.org (Roger Serwy)
Date: Sat, 04 Feb 2012 19:28:42 +0000
Subject: [issue964437] idle help is modal
Message-ID: <1328383722.8.0.501835532984.issue964437@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Attached is an updated version of Guilherme's patch against 3.3a0. It does make the help window non-modal.

----------
Added file: http://bugs.python.org/file24421/help_nonmodal_updated.patch

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

From report at bugs.python.org  Sat Feb  4 21:17:52 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Feb 2012 20:17:52 +0000
Subject: [issue13933] IDLE:not able to complete the hashlib module
In-Reply-To: <1328284806.31.0.442750340549.issue13933@psf.upfronthosting.co.za>
Message-ID: <1328386672.34.0.663344637834.issue13933@psf.upfronthosting.co.za>


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

Thank you both. I saw the answer (hashlib.__all__ is, unusally, a tuple) but did not see how it was the answer.

----------

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

From report at bugs.python.org  Sat Feb  4 21:41:08 2012
From: report at bugs.python.org (Patrick Andrew)
Date: Sat, 04 Feb 2012 20:41:08 +0000
Subject: [issue13943] Lib/distutils/command/build_py fails when package string
	is unicode
Message-ID: <1328388068.27.0.743003863578.issue13943@psf.upfronthosting.co.za>


New submission from Patrick Andrew <pandrew at isilon.com>:

When a package list is built using Unicode strings, distutils fails to build the package with a TypeError.

This patch alternatively checks for 'unicode' as the instance type and also prints the type in the type error for easier debugging.

----------
assignee: tarek
components: Distutils
files: patch-Lib-distutils-command-build_py.py
messages: 152643
nosy: eric.araujo, patrick.andrew, tarek
priority: normal
severity: normal
status: open
title: Lib/distutils/command/build_py fails when package string is unicode
versions: Python 2.7
Added file: http://bugs.python.org/file24422/patch-Lib-distutils-command-build_py.py

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

From report at bugs.python.org  Sat Feb  4 22:24:53 2012
From: report at bugs.python.org (Warren Turkal)
Date: Sat, 04 Feb 2012 21:24:53 +0000
Subject: [issue13922] argparse handling multiple "--" in args improperly
In-Reply-To: <1328132556.72.0.92385645061.issue13922@psf.upfronthosting.co.za>
Message-ID: <1328390693.33.0.140412591197.issue13922@psf.upfronthosting.co.za>


Warren Turkal <wt at penguintechs.org> added the comment:

I wanted to include a minimal example script, so here it is. If you run this like so:
$ ./test.py -- blah -- blah2

you will get the the following output:
Namespace(args=['blah2'], target=['blah'])

I would have expected the following instead:
Namespace(args=['--', 'blah2'], target=['blah'])

----------

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

From report at bugs.python.org  Sat Feb  4 22:46:56 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 04 Feb 2012 21:46:56 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <E1RtnRe-0001sT-4K@dinsdale.python.org>


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

New changeset e73d549b7458 by Nadeem Vawda in branch '2.7':
Issue #1625: Document BZ2File's lack of support for multi-stream inputs.
http://hg.python.org/cpython/rev/e73d549b7458

New changeset 190826ee0450 by Nadeem Vawda in branch '3.2':
Issue #1625: Document BZ2File's lack of support for multi-stream inputs.
http://hg.python.org/cpython/rev/190826ee0450

----------

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

From report at bugs.python.org  Sat Feb  4 23:16:52 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 04 Feb 2012 22:16:52 +0000
Subject: [issue964437] idle help is modal
Message-ID: <1328393812.43.0.986973356135.issue964437@psf.upfronthosting.co.za>


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

Thanks, Roger.  I did a quick smoke test of the patch on OS X 10.7 with Cocoa Tk.  I didn't see any obvious problems.  Of course, it needs to be tested on Windows and with X11 on a Unix platform.  Note, that there are some spurious spaces at a few ends-of-lines.  The main repositories on hg.python.org have whitespace prehooks that check for and reject patches with extra whitespace.  There's a script (reindent.py) included in Tools/scripts that will check for this and other problems.
    http://docs.python.org/devguide/committing.html

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

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

From report at bugs.python.org  Sat Feb  4 23:39:48 2012
From: report at bugs.python.org (Roger Serwy)
Date: Sat, 04 Feb 2012 22:39:48 +0000
Subject: [issue964437] idle help is modal
Message-ID: <1328395188.61.0.0623598378313.issue964437@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I ran reindent and resubmitted the patch.

The patch works fine on Ubuntu 11.04. One very subtle design issue with the patch is that the help window is tied to the calling EditorWindow instance. If the editor (or shell) closes, so does the help window, even if other editors are open.

----------
Added file: http://bugs.python.org/file24423/help_nonmodal_updated2.patch

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

From report at bugs.python.org  Sun Feb  5 00:44:27 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Feb 2012 23:44:27 +0000
Subject: [issue13843] Python doesn't compile anymore on our Solaris buildbot:
	undefined libintl_* symbols
In-Reply-To: <1327354335.3.0.0960870172041.issue13843@psf.upfronthosting.co.za>
Message-ID: <1328399067.54.0.0786648491966.issue13843@psf.upfronthosting.co.za>


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

Martin, do you have any idea? There doesn't seem to be any recent commits that could have caused this problem.

----------

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

From report at bugs.python.org  Sun Feb  5 01:12:27 2012
From: report at bugs.python.org (Jack Jansen)
Date: Sun, 05 Feb 2012 00:12:27 +0000
Subject: [issue13892] distutils handling of windows manifest isn't optimal
In-Reply-To: <1327698565.84.0.667656042788.issue13892@psf.upfronthosting.co.za>
Message-ID: <1328400747.14.0.792526892564.issue13892@psf.upfronthosting.co.za>


Jack Jansen <jackjansen at users.sourceforge.net> added the comment:

Hmm, the cscript.exe point is a valid one. I can think of two things that make my situation different, I will investigate (and post here):

- I started getting the problem when the hosting application (Ambulant multimedia player) switched from VS2008 to VS2010. So maybe cscript.exe is built with 2008, and there the problem is masked?

- My outer plugin (the one for Ambulant) also links against the .pyd (actually, to the .lib corresponding to the .pyd, which results in the .dll having a reference to the .pyd) because I need the various _New and _Convert routines when I call out to Python. I think this is a situation that wouldn't occur in the cscript.exe case.

----------

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

From report at bugs.python.org  Sun Feb  5 01:42:03 2012
From: report at bugs.python.org (Warren Turkal)
Date: Sun, 05 Feb 2012 00:42:03 +0000
Subject: [issue13922] argparse handling multiple "--" in args improperly
In-Reply-To: <1328132556.72.0.92385645061.issue13922@psf.upfronthosting.co.za>
Message-ID: <1328402523.3.0.644048122116.issue13922@psf.upfronthosting.co.za>


Warren Turkal <wt at penguintechs.org> added the comment:

It doesn't look like that file got included last time, so here's a second try.

----------
Added file: http://bugs.python.org/file24424/test.py

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

From report at bugs.python.org  Sun Feb  5 02:06:52 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 05 Feb 2012 01:06:52 +0000
Subject: [issue964437] idle help is modal
Message-ID: <1328404012.95.0.280255904223.issue964437@psf.upfronthosting.co.za>


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

Download, tested on W7, 3.2.2. Started help, brought to front, stopped, restarted, in both shell and edit window and all fine *except* when I closed edit window with help attached, which closes help also, and tried to open help in shell, idle 'silently' crashes. Reproduced same after restart idle. If I reopen an edit window, and reopen help from an edit window, it works ok. So the side-effect close seems to leave something behind that is a problem for reopening from shell but not from another edit window.

I am also still curious why window opens too narrow and if that can be fixed.

----------

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

From report at bugs.python.org  Sun Feb  5 02:10:04 2012
From: report at bugs.python.org (Michael Foord)
Date: Sun, 05 Feb 2012 01:10:04 +0000
Subject: [issue13932] If some test module fails to import another module
	unittest reports a very misleading message
In-Reply-To: <1328284244.56.0.791299564661.issue13932@psf.upfronthosting.co.za>
Message-ID: <1328404204.63.0.518892351862.issue13932@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

This is a duplicate of issue 7559. See the discussion there.

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

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

From report at bugs.python.org  Sun Feb  5 02:13:23 2012
From: report at bugs.python.org (Michael Mulich)
Date: Sun, 05 Feb 2012 01:13:23 +0000
Subject: [issue13771] HTTPSConnection __init__ super implementation causes
	recursion error
In-Reply-To: <1328280078.83.0.426348131078.issue13771@psf.upfronthosting.co.za>
Message-ID: <CACvZ6pxZ7kF7tYiABvbKsjS=bCy=qZnkEhWVHTkjzDMbLbVpUQ@mail.gmail.com>


Michael Mulich <michael.mulich at gmail.com> added the comment:

Sure does. But that's the point of the package.

Why is this super usage without arguments considered a hack?

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

----------

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

From report at bugs.python.org  Sun Feb  5 02:27:04 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 05 Feb 2012 01:27:04 +0000
Subject: [issue13893] Make CGIHTTPServer capable of redirects (and status
	other than 200)
In-Reply-To: <1327705936.4.0.817960222769.issue13893@psf.upfronthosting.co.za>
Message-ID: <1328405224.36.0.791491071782.issue13893@psf.upfronthosting.co.za>


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

Add version of server.py source.  This was originally revised from Python 3.1, I just now merged the Python 3.2 changes.  I've been running it for months in 3.2, but without the 3.2 changes. Will be running it now in this form, so if something goes wrong in my environment, I'll be back to correct it.

This code includes fixes for a number of open issues that I opened, including issue 10487.

Giovanni -- if you have time to work on this, and separate out the patches for the individual issues address, and cause progress, that would be great.  Maybe use this issue as a staging area, tease apart the patches and submit them to the other bugs, and then just close this one down as a dup of the others?  I'm not sure of the best process.

----------
Added file: http://bugs.python.org/file24425/server.py

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

From report at bugs.python.org  Sun Feb  5 02:31:36 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 05 Feb 2012 01:31:36 +0000
Subject: [issue13893] Make CGIHTTPServer capable of redirects (and status
	other than 200)
In-Reply-To: <1327705936.4.0.817960222769.issue13893@psf.upfronthosting.co.za>
Message-ID: <1328405496.16.0.714113948707.issue13893@psf.upfronthosting.co.za>


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

Uploaded version of CGIHTTPServer.py that is based on Python 2.6 runs well there on Windows, but which also works under Python 2.4 on Linux.

I should mention that the server.py I upload moments ago has mostly run on Windows, and I might not have fixed all the problems in the Linux/Unix path, because I don't have a test environment for that path.

----------
Added file: http://bugs.python.org/file24426/CGIHTTPServer.py

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

From report at bugs.python.org  Sun Feb  5 02:33:38 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 05 Feb 2012 01:33:38 +0000
Subject: [issue13893] Make CGIHTTPServer capable of redirects (and status
	other than 200)
In-Reply-To: <1327705936.4.0.817960222769.issue13893@psf.upfronthosting.co.za>
Message-ID: <1328405618.07.0.610754936488.issue13893@psf.upfronthosting.co.za>


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

Oh, and I submit all my changes to the public domain to be re-licensed as needed by anyone that works with it. Not sure if these few changes need a contributor agreement, I'd be glad to sign one if it is.

----------

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

From report at bugs.python.org  Sun Feb  5 04:04:40 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 05 Feb 2012 03:04:40 +0000
Subject: [issue13944] HMAC object called hmac
Message-ID: <1328411080.71.0.906401120074.issue13944@psf.upfronthosting.co.za>


New submission from Ramchandra Apte <maniandram01 at gmail.com>:

When the documentation for hashlib says "An HMAC object has the following methods:" the list of methods says hmac.xxx which is wrong and should be HMAC.xxx.
Thanks

----------
assignee: docs at python
components: Documentation
messages: 152657
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: HMAC object called hmac
type: enhancement
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Feb  5 04:12:22 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 05 Feb 2012 03:12:22 +0000
Subject: [issue13945] Mistake in the text for PEP-383
Message-ID: <1328411542.41.0.837889864027.issue13945@psf.upfronthosting.co.za>


New submission from Ramchandra Apte <maniandram01 at gmail.com>:

"chosers" should be "choosers" in 'External libraries that operate on file names (such as GUI file chosers) should also encode them according to the PEP.' in text for PEP-383 (http://www.python.org/dev/peps/pep-0383/)

----------
messages: 152658
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: Mistake in the text for PEP-383
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Sun Feb  5 05:24:02 2012
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 05 Feb 2012 04:24:02 +0000
Subject: [issue964437] idle help is modal
Message-ID: <1328415842.51.0.951099805605.issue964437@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Attached is a reworked patch to handle the nonmodal help dialog.

It replaces the decorator _singledialog with a call to a singleton HelpDialog class. The class creates the textView widget using as its parent the root Tk window instance instead of the EditorWindow's Toplevel.
Any EditorWindow instance calling "help_dialog" will cause the existing help dialog to be repositioned on top of it.

----------
Added file: http://bugs.python.org/file24427/help_nonmodal_revision.patch

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

From report at bugs.python.org  Sun Feb  5 05:28:17 2012
From: report at bugs.python.org (Nasos Dousis)
Date: Sun, 05 Feb 2012 04:28:17 +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: <1328416097.48.0.766219971741.issue10910@psf.upfronthosting.co.za>


Nasos Dousis <ndousis at gmail.com> added the comment:

Per Chen Huang's comment, I retested my test case code using several versions of boost and Python 2.7:

boost 1.45: build fails, errors as reported.
boost 1.46: success.
boost 1.47: success.

I've attached a revised test case that automatically downloads and builds boost 1.45.

----------
Added file: http://bugs.python.org/file24428/test-boost-python.revised.tar.gz

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

From report at bugs.python.org  Sun Feb  5 07:31:42 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 05 Feb 2012 06:31:42 +0000
Subject: [issue12142] Reference cycle when importing ctypes
In-Reply-To: <1306017588.73.0.650837416325.issue12142@psf.upfronthosting.co.za>
Message-ID: <E1Rtvb2-0004WF-Sq@dinsdale.python.org>


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

New changeset 205da7a19a78 by Meador Inge in branch '3.2':
Issue #12142: Fixed reference cycle when importing ctypes
http://hg.python.org/cpython/rev/205da7a19a78

New changeset b228d9da8bd3 by Meador Inge in branch 'default':
Issue #12142: Fixed reference cycle when importing ctypes
http://hg.python.org/cpython/rev/b228d9da8bd3

New changeset 7cdbf627f958 by Meador Inge in branch '2.7':
Issue #12142: Fixed reference cycle when importing ctypes
http://hg.python.org/cpython/rev/7cdbf627f958

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

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

From report at bugs.python.org  Sun Feb  5 07:46:55 2012
From: report at bugs.python.org (Meador Inge)
Date: Sun, 05 Feb 2012 06:46:55 +0000
Subject: [issue13370] test_ctypes fails on osx 10.7
In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za>
Message-ID: <1328424415.22.0.912398838431.issue13370@psf.upfronthosting.co.za>


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

I can't reproduce this on Lion using the 2.7 or default branches.  I can't build with GCC at the moment because of issue13241.  I am using the clang that ships with Lion:

motherbrain:cpython meadori$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.7.2
BuildVersion:	11C74
motherbrain:cpython meadori$ clang --version
Apple clang version 3.0 (tags/Apple/clang-211.12) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.2.0
Thread model: posix

----------

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

From report at bugs.python.org  Sun Feb  5 08:04:53 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 05 Feb 2012 07:04:53 +0000
Subject: [issue964437] idle help is modal
Message-ID: <1328425493.8.0.620693127396.issue964437@psf.upfronthosting.co.za>


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

I retried and get same behavior: help closes with closing of edit window and trying to reopen from shell closes idle with about 2 second delay.
Does this
+        if self.root:
+            parent = self.root
+        else:
+            parent = self.top
really do what you claimed? (always attach to root rather than toplevel)?

----------

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

From report at bugs.python.org  Sun Feb  5 09:28:41 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 05 Feb 2012 08:28:41 +0000
Subject: [issue13944] HMAC object called hmac
In-Reply-To: <1328411080.71.0.906401120074.issue13944@psf.upfronthosting.co.za>
Message-ID: <E1RtxSi-0003OX-4j@dinsdale.python.org>


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

New changeset 7c263bfc92f5 by Georg Brandl in branch '2.7':
Closes #13944: fix capitalization of class name.
http://hg.python.org/cpython/rev/7c263bfc92f5

New changeset cd748bab3cdd by Georg Brandl in branch '3.2':
Closes #13944: fix capitalization of class name.
http://hg.python.org/cpython/rev/cd748bab3cdd

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

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

From report at bugs.python.org  Sun Feb  5 09:29:21 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Feb 2012 08:29:21 +0000
Subject: [issue13945] Mistake in the text for PEP-383
In-Reply-To: <1328411542.41.0.837889864027.issue13945@psf.upfronthosting.co.za>
Message-ID: <1328430561.31.0.189369894675.issue13945@psf.upfronthosting.co.za>


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

Done in 5748c9cf7628.

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

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

From report at bugs.python.org  Sun Feb  5 10:49:21 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 05 Feb 2012 09:49:21 +0000
Subject: [issue11805] package_data only allows one glob per-package
In-Reply-To: <1302301429.27.0.797210396018.issue11805@psf.upfronthosting.co.za>
Message-ID: <E1Rtyim-0008L8-7z@dinsdale.python.org>


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

New changeset 2c08bf9aca22 by ?ric Araujo in branch 'default':
Allow multiple values for package_data in setup.cfg (#11805).
http://hg.python.org/cpython/rev/2c08bf9aca22

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

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

From report at bugs.python.org  Sun Feb  5 10:49:21 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 05 Feb 2012 09:49:21 +0000
Subject: [issue13712] pysetup create should not convert package_data to
	extra_files
In-Reply-To: <1325689084.75.0.043764224634.issue13712@psf.upfronthosting.co.za>
Message-ID: <E1Rtyim-0008L8-7q@dinsdale.python.org>


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

New changeset edb6f9fb54ac by ?ric Araujo in branch 'default':
Stop converting package_data to extra_files in pysetup create (#13712).
http://hg.python.org/cpython/rev/edb6f9fb54ac

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

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

From report at bugs.python.org  Sun Feb  5 10:57:55 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Feb 2012 09:57:55 +0000
Subject: [issue13771] HTTPSConnection __init__ super implementation causes
	recursion error
In-Reply-To: <1326304391.56.0.972578337686.issue13771@psf.upfronthosting.co.za>
Message-ID: <1328435875.52.0.803072236028.issue13771@psf.upfronthosting.co.za>


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

super without arguments literally relies on a compiler hack.

----------

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

From report at bugs.python.org  Sun Feb  5 11:04:46 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 05 Feb 2012 10:04:46 +0000
Subject: [issue6617] During compiling python 3.1 getting error Undefined
	symbol libintl_bind_textdomain_codeset
In-Reply-To: <1249162677.96.0.181878890277.issue6617@psf.upfronthosting.co.za>
Message-ID: <1328436286.75.0.390551718761.issue6617@psf.upfronthosting.co.za>


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

I'm tagging this as a duplicate of #13843, since I expect more activity
on the newer issue.

----------
nosy: +skrah
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Python doesn't compile anymore on our Solaris buildbot: undefined libintl_* symbols

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

From report at bugs.python.org  Sun Feb  5 11:04:53 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 05 Feb 2012 10:04:53 +0000
Subject: [issue13843] Python doesn't compile anymore on our Solaris buildbot:
	undefined libintl_* symbols
In-Reply-To: <1327354335.3.0.0960870172041.issue13843@psf.upfronthosting.co.za>
Message-ID: <1328436293.93.0.149229699562.issue13843@psf.upfronthosting.co.za>


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

See also #6617 (which I marked as a duplicate).

----------
nosy: +amaury.forgeotdarc, skrah, thoratsandip

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

From report at bugs.python.org  Sun Feb  5 11:11:17 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Feb 2012 10:11:17 +0000
Subject: =?utf-8?q?=5Bissue13943=5D_distutils=E2=80=99_build=5Fpy_fails_when_packa?=
	=?utf-8?q?ge_string_is_unicode?=
In-Reply-To: <1328388068.27.0.743003863578.issue13943@psf.upfronthosting.co.za>
Message-ID: <1328436677.77.0.161670348656.issue13943@psf.upfronthosting.co.za>


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

Thanks for the report and patch.  I think distutils was not written with Unicode in mind, or maybe even before Python had a unicode type.  Technically, http://docs.python.org/distutils/setupscript#additional-meta-data says that unicode is not allowed for metadata fields (nothing is said about py_modules, packages and the like), but we?ve fixed a couple of bugs related to unicode, so I think this is a reasonable request.  Can you post (part of) your failing setup script?

----------
assignee: tarek -> eric.araujo
keywords: +easy
title: Lib/distutils/command/build_py fails when package string is unicode -> distutils? build_py fails when package string is unicode

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

From report at bugs.python.org  Sun Feb  5 11:15:06 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Feb 2012 10:15:06 +0000
Subject: [issue13773] Support sqlite3 uri filenames
In-Reply-To: <1326313998.63.0.583537561643.issue13773@psf.upfronthosting.co.za>
Message-ID: <1328436906.07.0.231811103332.issue13773@psf.upfronthosting.co.za>


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

> I've added an updated patch which adds a link. I've also changed the exception when URIs
> are not supported to sqlite3.NotSupportedError.
Sounds good.  Note to the person who will commit: :const:`True` should be marked up as ``True.``

> I prefer anonymity. :)
OK.  I?m still not sure if a contributor agreement is needed for this patch.

----------

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

From report at bugs.python.org  Sun Feb  5 11:15:18 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Feb 2012 10:15:18 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1328436918.4.0.046235918871.issue7559@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Feb  5 11:17:58 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Feb 2012 10:17:58 +0000
Subject: [issue13933] IDLE:not able to complete the hashlib module
In-Reply-To: <1328284806.31.0.442750340549.issue13933@psf.upfronthosting.co.za>
Message-ID: <1328437078.67.0.352647955632.issue13933@psf.upfronthosting.co.za>


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

BTW I wonder if setting __all__ to something but a list is valid.  I think I ran into a similar bug once and fixing __all__ fixed it.  The IDLE robustness fix is probably a good thing, but maybe we should also check the stdlib?s __all__s and the docs.

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

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

From report at bugs.python.org  Sun Feb  5 11:19:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Feb 2012 10:19:07 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1328437147.17.0.657840108674.issue1625@psf.upfronthosting.co.za>


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

Just a thought: maybe the doc note should mention that bz2file is a backport of 3.3?s improved class, so that people know that 1) it?s well-supported code 2) a future Python version will remove the need for the external dependency.

----------

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

From report at bugs.python.org  Sun Feb  5 11:56:49 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Feb 2012 10:56:49 +0000
Subject: [issue11805] package_data only allows one glob per-package
In-Reply-To: <1302301429.27.0.797210396018.issue11805@psf.upfronthosting.co.za>
Message-ID: <1328439409.46.0.632185968459.issue11805@psf.upfronthosting.co.za>


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

> Note that my proposed syntax does not allow something equivalent to {'': [etc.]} in
> distutils, i.e. package data for top-level modules.  I think this is okay: modules should
> not install data in their installation dir.  I don?t think it was widely used

I tested: This construct was allowed but did not actually cause any file to be installed (i.e. no crash, no-op), so we?re not removing any functionality here.

----------

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

From report at bugs.python.org  Sun Feb  5 12:08:50 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Feb 2012 11:08:50 +0000
Subject: [issue13893] Make CGIHTTPServer capable of redirects (and status
	other than 200)
In-Reply-To: <1327705936.4.0.817960222769.issue13893@psf.upfronthosting.co.za>
Message-ID: <1328440130.78.0.148174880909.issue13893@psf.upfronthosting.co.za>


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


----------
stage: test needed -> committed/rejected
status: open -> closed
superseder:  -> http.server doesn't process Status header from CGI scripts
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Feb  5 12:23:58 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 05 Feb 2012 11:23:58 +0000
Subject: [issue13712] pysetup create should not convert package_data to
	extra_files
In-Reply-To: <1325689084.75.0.043764224634.issue13712@psf.upfronthosting.co.za>
Message-ID: <E1Ru0CK-0002TH-VT@dinsdale.python.org>


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

New changeset 730c2e4aaf9c by ?ric Araujo in branch 'default':
Stop converting package_data to extra_files in pysetup create (#13712).
http://hg.python.org/distutils2/rev/730c2e4aaf9c

New changeset ea717d8e71d0 by ?ric Araujo in branch 'python3':
Merge fixes for #13901, #11805, #13712 and other improvements
http://hg.python.org/distutils2/rev/ea717d8e71d0

----------

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

From report at bugs.python.org  Sun Feb  5 12:23:58 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 05 Feb 2012 11:23:58 +0000
Subject: [issue13901] test_get_outputs (test_distutils) failure with
	--enable-shared on Mac OS X
In-Reply-To: <1327826805.0.0.304314009246.issue13901@psf.upfronthosting.co.za>
Message-ID: <E1Ru0CK-0002TH-Va@dinsdale.python.org>


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

New changeset e6a28ae0dfd6 by ?ric Araujo in branch 'default':
Port OS X --enable-shared fix from packaging (#13901; untested)
http://hg.python.org/distutils2/rev/e6a28ae0dfd6

New changeset ea717d8e71d0 by ?ric Araujo in branch 'python3':
Merge fixes for #13901, #11805, #13712 and other improvements
http://hg.python.org/distutils2/rev/ea717d8e71d0

----------

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

From report at bugs.python.org  Sun Feb  5 12:23:59 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 05 Feb 2012 11:23:59 +0000
Subject: [issue11805] package_data only allows one glob per-package
In-Reply-To: <1302301429.27.0.797210396018.issue11805@psf.upfronthosting.co.za>
Message-ID: <E1Ru0CK-0002TH-Vg@dinsdale.python.org>


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

New changeset 83a0985c7aad by ?ric Araujo in branch 'default':
Allow multiple values for package_data in setup.cfg (#11805).
http://hg.python.org/distutils2/rev/83a0985c7aad

New changeset ea717d8e71d0 by ?ric Araujo in branch 'python3':
Merge fixes for #13901, #11805, #13712 and other improvements
http://hg.python.org/distutils2/rev/ea717d8e71d0

----------

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

From report at bugs.python.org  Sun Feb  5 12:26:18 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Feb 2012 11:26:18 +0000
Subject: [issue11805] package_data only allows one glob per-package
In-Reply-To: <1302301429.27.0.797210396018.issue11805@psf.upfronthosting.co.za>
Message-ID: <1328441178.92.0.212153418762.issue11805@psf.upfronthosting.co.za>


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

Thanks for the help Erik.

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

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

From report at bugs.python.org  Sun Feb  5 12:30:54 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Feb 2012 11:30:54 +0000
Subject: [issue13712] pysetup create should not convert package_data to
	extra_files
In-Reply-To: <1325689084.75.0.043764224634.issue13712@psf.upfronthosting.co.za>
Message-ID: <1328441454.59.0.0253680369978.issue13712@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Feb  5 12:47:59 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 05 Feb 2012 11:47:59 +0000
Subject: [issue13843] Python doesn't compile anymore on our Solaris buildbot:
	undefined libintl_* symbols
In-Reply-To: <1327354335.3.0.0960870172041.issue13843@psf.upfronthosting.co.za>
Message-ID: <1328442479.11.0.414606823313.issue13843@psf.upfronthosting.co.za>


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

> See also #6617 (which I marked as a duplicate).

This issue contains an interesting message (msg91758):
"I dont know Solaris, but googling for "libintl_textdomain solaris" shows 
that many other projects have the same issue.
The solution seems to set LDFLAGS=-lintl"

But I don't think that it would fix the issue because the failing command is "gcc -o python Modules/python.o libpython3.3dm.a -lintl ...".

----------

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

From report at bugs.python.org  Sun Feb  5 13:30:39 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 05 Feb 2012 12:30:39 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <E1Ru1Er-0005lt-VX@dinsdale.python.org>


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

New changeset ad20324229f4 by Nadeem Vawda in branch '2.7':
Clarify note in BZ2File docs about lack of multi-stream support (issue #1625).
http://hg.python.org/cpython/rev/ad20324229f4

New changeset e4c4595033ad by Nadeem Vawda in branch '3.2':
Clarify note in BZ2File docs about lack of multi-stream support (issue #1625).
http://hg.python.org/cpython/rev/e4c4595033ad

----------

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

From report at bugs.python.org  Sun Feb  5 13:34:16 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Feb 2012 12:34:16 +0000
Subject: [issue13839] -m pstats should combine all the profiles given as
	arguments
In-Reply-To: <1327289897.02.0.607924329906.issue13839@psf.upfronthosting.co.za>
Message-ID: <1328445256.18.0.0526591544156.issue13839@psf.upfronthosting.co.za>


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

This sounds like a reasonable request.  The patch needs tests, probably using test.script_helper.assert_python_ok.

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

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

From report at bugs.python.org  Sun Feb  5 13:50:12 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 05 Feb 2012 12:50:12 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <E1Ru1Xm-0007BK-Vk@dinsdale.python.org>


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

New changeset 11bd2d32b4e8 by ?ric Araujo in branch '3.2':
Improve interlinking of archiving/compression modules docs.
http://hg.python.org/cpython/rev/11bd2d32b4e8

New changeset 1cb9b8126534 by ?ric Araujo in branch 'default':
Merge edits from 3.2 (#13716, #1040439, #2945, #13770, #6715)
http://hg.python.org/cpython/rev/1cb9b8126534

----------

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

From report at bugs.python.org  Sun Feb  5 13:50:12 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 05 Feb 2012 12:50:12 +0000
Subject: [issue13770] python3 & json: add ensure_ascii documentation
In-Reply-To: <1326300131.17.0.750918490995.issue13770@psf.upfronthosting.co.za>
Message-ID: <E1Ru1Xm-0007BK-Ve@dinsdale.python.org>


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

New changeset 33d6da1b1c71 by ?ric Araujo in branch '3.2':
Document json.dump ensure_ascii parameter (#13770)
http://hg.python.org/cpython/rev/33d6da1b1c71

New changeset 1cb9b8126534 by ?ric Araujo in branch 'default':
Merge edits from 3.2 (#13716, #1040439, #2945, #13770, #6715)
http://hg.python.org/cpython/rev/1cb9b8126534

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

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

From report at bugs.python.org  Sun Feb  5 13:50:13 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 05 Feb 2012 12:50:13 +0000
Subject: [issue2945] bdist_rpm does not list dist files (should effect upload)
In-Reply-To: <1211466871.95.0.658180804984.issue2945@psf.upfronthosting.co.za>
Message-ID: <E1Ru1Xm-0007BK-V8@dinsdale.python.org>


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

New changeset 26aea1825418 by ?ric Araujo in branch '3.2':
Stop ignoring RPMs in distutils' upload command (#2945).
http://hg.python.org/cpython/rev/26aea1825418

New changeset 1cb9b8126534 by ?ric Araujo in branch 'default':
Merge edits from 3.2 (#13716, #1040439, #2945, #13770, #6715)
http://hg.python.org/cpython/rev/1cb9b8126534

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

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

From report at bugs.python.org  Sun Feb  5 13:50:14 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 05 Feb 2012 12:50:14 +0000
Subject: [issue13716] distutils doc contains lots of XXX
In-Reply-To: <1325790136.17.0.881224521536.issue13716@psf.upfronthosting.co.za>
Message-ID: <E1Ru1Xm-0007BK-Vu@dinsdale.python.org>


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

New changeset 3d25869fce0c by ?ric Araujo in branch '3.2':
Hide or remove user-visible XXX notes from distutils doc (#13716).
http://hg.python.org/cpython/rev/3d25869fce0c

New changeset 1cb9b8126534 by ?ric Araujo in branch 'default':
Merge edits from 3.2 (#13716, #1040439, #2945, #13770, #6715)
http://hg.python.org/cpython/rev/1cb9b8126534

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

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

From report at bugs.python.org  Sun Feb  5 13:50:15 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 05 Feb 2012 12:50:15 +0000
Subject: [issue1040439] Missing documentation on how to link with libpython
Message-ID: <E1Ru1Xm-0007BK-Vp@dinsdale.python.org>


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

New changeset 79e8de78abd0 by ?ric Araujo in branch '3.2':
Markup improvements for the embedding CPython doc patch from #1040439
http://hg.python.org/cpython/rev/79e8de78abd0

New changeset 1cb9b8126534 by ?ric Araujo in branch 'default':
Merge edits from 3.2 (#13716, #1040439, #2945, #13770, #6715)
http://hg.python.org/cpython/rev/1cb9b8126534

----------

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

From report at bugs.python.org  Sun Feb  5 14:53:24 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 05 Feb 2012 13:53:24 +0000
Subject: [issue13921] sqlite3: OptimizedUnicode obsolete in Py3k
In-Reply-To: <1328343565.44.0.550944986354.issue13921@psf.upfronthosting.co.za>
Message-ID: <20120205135319.GB1955@ihaa>


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

?ric Araujo wrote:
> I?m not sure the doc note is useful, but didn?t code search to
> confirm it.

Yeah. Perhaps it would be better as a comment in the code.

> Also, 3.2 may be out of bounds for this cleanup (I don?t know the
> rules for what can be committed in what branches these days).

My intention was to apply it to 3.3 only.

----------

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

From report at bugs.python.org  Sun Feb  5 15:16:01 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 05 Feb 2012 14:16:01 +0000
Subject: [issue13734] Add a generic directory walker method to avoid symlink
	attacks
In-Reply-To: <1325981643.51.0.923790442233.issue13734@psf.upfronthosting.co.za>
Message-ID: <E1Ru2sq-0004zs-BF@dinsdale.python.org>


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

New changeset 773a97b3927d by Charles-Fran?ois Natali in branch 'default':
Issue #13734: Add os.fwalk(), a directory walking function yielding file
http://hg.python.org/cpython/rev/773a97b3927d

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

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

From report at bugs.python.org  Sun Feb  5 15:56:15 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Sun, 05 Feb 2012 14:56:15 +0000
Subject: [issue10482] subprocess and deadlock avoidance
In-Reply-To: <1290320162.59.0.372707956205.issue10482@psf.upfronthosting.co.za>
Message-ID: <1328453775.05.0.814099312898.issue10482@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/issue10482>
_______________________________________

From report at bugs.python.org  Sun Feb  5 15:56:19 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Sun, 05 Feb 2012 14:56:19 +0000
Subject: [issue10487] http.server doesn't process Status header from CGI
	scripts
In-Reply-To: <1290325843.93.0.000870454658653.issue10487@psf.upfronthosting.co.za>
Message-ID: <1328453779.94.0.680456417469.issue10487@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/issue10487>
_______________________________________

From report at bugs.python.org  Sun Feb  5 16:17:37 2012
From: report at bugs.python.org (Ned Deily)
Date: Sun, 05 Feb 2012 15:17:37 +0000
Subject: [issue13370] test_ctypes fails on osx 10.7
In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za>
Message-ID: <1328455057.17.0.864522785905.issue13370@psf.upfronthosting.co.za>


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

It looks like the test failures do not show up with debug enabled (--with-pydebug).  I'm able to reproduce them with:

./configure MACOSX_DEPLOYMENT_TARGET=10.7 CC=clang

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

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

From report at bugs.python.org  Sun Feb  5 16:19:31 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 05 Feb 2012 15:19:31 +0000
Subject: [issue13734] Add a generic directory walker method to avoid symlink
	attacks
In-Reply-To: <1325981643.51.0.923790442233.issue13734@psf.upfronthosting.co.za>
Message-ID: <1328455171.45.0.939299812533.issue13734@psf.upfronthosting.co.za>


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

Committed, thanks for the comments.

Note to myself (and others that might be interested in the O(1)) version):
we can't simply call openat(dirfd, "..", O_RDONLY) to re-open the current directory's file descriptor after having walked a into one of its subdirectories because if this subdirectory is actually a link, we'll open the parent directory of the target directory, instead of the current (toppath) directory. OTOH, if the user passes followlinks=True, then we don't have to bother with openat() and friends in which case we don't have to bother passing FDs between calls to fwalk().

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

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

From report at bugs.python.org  Sun Feb  5 16:31:10 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 05 Feb 2012 15:31:10 +0000
Subject: [issue12410] Create a new helper function that enable to test that an
	operation don't hang more than a given timeout.
In-Reply-To: <1309013375.96.0.63412212065.issue12410@psf.upfronthosting.co.za>
Message-ID: <1328455870.91.0.056732354909.issue12410@psf.upfronthosting.co.za>


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

Closing, since it's hard to write correctly, and apparently not that useful.

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

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

From report at bugs.python.org  Sun Feb  5 17:09:11 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 05 Feb 2012 16:09:11 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1328458151.4.0.577343376835.issue1975@psf.upfronthosting.co.za>


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

Closing (see http://bugs.python.org/msg149904 and http://bugs.python.org/msg149909).

----------
assignee: docs at python -> 
resolution:  -> rejected
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Feb  5 17:15:51 2012
From: report at bugs.python.org (John Pye)
Date: Sun, 05 Feb 2012 16:15:51 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1328458551.14.0.0412304356281.issue4709@psf.upfronthosting.co.za>


John Pye <john at curioussymbols.com> added the comment:

Hi Martin

I have documented a build process for a Python package on MinGW-w64, including a requirement that this patch be applied. You might want to revisit it, given that your attempt to reproduce this bug earlier was unsuccessful.

http://ascend4.org/Building_ASCEND_for_64-bit_Windows

Please let me know if you're looking at it and if there's anything that needs to be clarified.

Cheers
JP

----------
nosy: +jdpipe

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

From report at bugs.python.org  Sun Feb  5 17:35:27 2012
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 05 Feb 2012 16:35:27 +0000
Subject: [issue964437] idle help is modal
Message-ID: <1328459727.44.0.827539116257.issue964437@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Those four lines are present just in case self.root is not initialized. 
Even if you short-circuit the behavior and set parent=self.top, the patch still works, only that closing the calling EditorWindow instance also closes the help dialog. 

I tested the patch against 3.3a0 on Ubuntu and 3.2.2 on Vista and it does attach to root, not self.top. 

It sounds like remnants of "_singledialog" are present in EditorWindow.py. Did you back out of the previous patch before applying help_nonmodal_revision.patch?

----------

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

From report at bugs.python.org  Sun Feb  5 17:45:25 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 05 Feb 2012 16:45:25 +0000
Subject: [issue10284] NNTP should accept bytestrings for username and password
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1328460325.52.0.986174616308.issue10284@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


----------
nosy: +hynek

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

From report at bugs.python.org  Sun Feb  5 17:55:02 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 05 Feb 2012 16:55:02 +0000
Subject: [issue8184] multiprocessing.managers will not fail if listening ocket
	already in use
In-Reply-To: <1325610269.85.0.498899743552.issue8184@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3eq87=BtaLTr02xh8JnOGt-WThMvd9tRfFt_K8yMPq7A@mail.gmail.com>


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

> However, let me point out the following sentence:
> ?Ports without SO_EXCLUSIVEADDRUSE set may be reused as soon as the socket on which bind was previously called is closed.?
>
> ...which seems to suggest we shouldn't use SO_REUSEADDR under Windows, since Windows sockets appear to have the Unix SO_REUSEADDR semantics by default.

Actually, it seems that even though the documentation doesn't mention
sockets in TIME_WAIT state, SO_REUSEADDR is actually required on
Windows:
http://twistedmatrix.com/trac/ticket/1151#comment:18

So the proper solution is the one adopted by support.bind_port(),
SO_REUSEADDR + SO_EXCLUSIVEADDRUSE.

Since Windows semantics is different (I'd rather say broken) and
SO_REUSEADDR is currently mis-used throughout the stdlib, what do you
think of adding a set_reuse() method to socket that would do the right
thing?

----------

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

From report at bugs.python.org  Sun Feb  5 18:16:39 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Feb 2012 17:16:39 +0000
Subject: [issue8184] multiprocessing.managers will not fail if listening ocket
	already in use
In-Reply-To: <CAH_1eM3eq87=BtaLTr02xh8JnOGt-WThMvd9tRfFt_K8yMPq7A@mail.gmail.com>
Message-ID: <1328462040.3420.7.camel@localhost.localdomain>


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

> Actually, it seems that even though the documentation doesn't mention
> sockets in TIME_WAIT state, SO_REUSEADDR is actually required on
> Windows:
> http://twistedmatrix.com/trac/ticket/1151#comment:18

According to that message, we would only need (or desire)
SO_EXCLUSIVEADDRUSE.

Note however what the MSDN doc says: ?Conversely, a socket with the
SO_EXCLUSIVEADDRUSE set cannot necessarily be reused immediately after
socket closure. For example, if a listening socket with
SO_EXCLUSIVEADDRUSE set accepts a connection and is then subsequently
closed, another socket (also with SO_EXCLUSIVEADDRUSE) cannot bind to
the same port as the first socket until the original connection becomes
inactive.?

... and goes on to discuss the virtues of shutdown() etc.

So I still think we need no option at all under Windows, and
SO_EXCLUSIVEADDR actually prevents the behaviour we are trying to avoid.

> So the proper solution is the one adopted by support.bind_port(),
> SO_REUSEADDR + SO_EXCLUSIVEADDRUSE.

I think you read it wrong. bind_port() only uses SO_EXCLUSIVEADDRUSE and
forbids SO_REUSEADDR.
Not surprising considering the commentor above, Trent, is the same that
wrote the bind_port() code :)

----------

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

From report at bugs.python.org  Sun Feb  5 18:56:19 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 05 Feb 2012 17:56:19 +0000
Subject: [issue8184] multiprocessing.managers will not fail if listening ocket
	already in use
In-Reply-To: <1269104932.24.0.802901286813.issue8184@psf.upfronthosting.co.za>
Message-ID: <1328464579.78.0.550184447543.issue8184@psf.upfronthosting.co.za>


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

> I think you read it wrong.

Duh, I managed to misread both the comment and the code :-)

What my subconscious refused to admit is the fact that on Windows, SO_REUSEADDR allows you to bind to any port - even though the other application didn't set SO_REUSEADDR on its socket - which is a security nightmare.

Anyway, in that case, my last patch should be correct (tested on one of the Win7 buildbots).

----------
keywords: +needs review

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

From report at bugs.python.org  Sun Feb  5 20:22:38 2012
From: report at bugs.python.org (Meador Inge)
Date: Sun, 05 Feb 2012 19:22:38 +0000
Subject: [issue13370] test_ctypes fails on osx 10.7
In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za>
Message-ID: <1328469758.16.0.907143013603.issue13370@psf.upfronthosting.co.za>


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

I can reproduce it without --with-pydebug.  Thanks.  I will investigate.

----------

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

From report at bugs.python.org  Sun Feb  5 20:33:26 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 05 Feb 2012 19:33:26 +0000
Subject: [issue13933] IDLE:not able to complete the hashlib module
In-Reply-To: <1328284806.31.0.442750340549.issue13933@psf.upfronthosting.co.za>
Message-ID: <E1Ru7q0-0002N0-G7@dinsdale.python.org>


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

New changeset 2b93ee675ec4 by Terry Jan Reedy in branch '2.7':
#13933 refine patch using 'new' builtin
http://hg.python.org/cpython/rev/2b93ee675ec4

New changeset d8f988b0c959 by Terry Jan Reedy in branch '3.2':
#13933 refine patch using 'new' builtin
http://hg.python.org/cpython/rev/d8f988b0c959

New changeset 60beb14636b7 by Terry Jan Reedy in branch 'default':
Merge with 3.2
http://hg.python.org/cpython/rev/60beb14636b7

----------

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

From report at bugs.python.org  Sun Feb  5 20:34:11 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 05 Feb 2012 19:34:11 +0000
Subject: [issue13933] IDLE:not able to complete the hashlib module
In-Reply-To: <1328284806.31.0.442750340549.issue13933@psf.upfronthosting.co.za>
Message-ID: <1328470451.19.0.56815878466.issue13933@psf.upfronthosting.co.za>


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

6.11 Import statement says " __all__; if defined, it must be a sequence of strings which are names defined or imported by that module."

I am tempted to open an issue to change 'sequence' to 'list', or even 'sorted sequence', but that is difficult to enforce.

----------

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

From report at bugs.python.org  Sun Feb  5 20:42:29 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 05 Feb 2012 19:42:29 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1328470949.85.0.312302210702.issue4709@psf.upfronthosting.co.za>


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

John: in the current versions of the toolchain, Python's configure fails for me. I follow steps 1..3 of "Steps to date". Then running ./configure fails saying that it does not work. I then tried alternatively these three approaches:

1. set PATH to include /mingw/mingw/bin
2. set CC to /mingw/mingw/bin/gcc.exe
3. set CC to /c/mingw/mingw/bin/gcc.exe

Even though I can run gcc -v just fine, configure fails with

configure:3593: checking whether the C compiler works
configure:3615: /mingw/mingw/bin/gcc    conftest.c  >&5
gcc.exe: error: CreateProcess: No such file or directory^
configure:3619: $? = 1
configure:3657: result: no

So apparently, mingw has some problem mapping the file name back to a Win32 path.

----------

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

From report at bugs.python.org  Sun Feb  5 20:48:01 2012
From: report at bugs.python.org (Nicolas)
Date: Sun, 05 Feb 2012 19:48:01 +0000
Subject: [issue13946] readline completer could return an iterable
Message-ID: <1328471281.77.0.152059916947.issue13946@psf.upfronthosting.co.za>


New submission from Nicolas <nicolas-gaudin at laposte.net>:

The function set by readline.set_completer must return one completion per call.  This should be great if we can return an iterable, because with current implementation I have to write a wrapper:

cache = None
def completer(text, state):
  if cache:
    if len(cache) > 0:
      return cache.pop(0)
    else:
      cache = None
      return None
  res = completer_returning_iterable(text)
  if isinstance(res, str) or res == None:
    return res
  cache = res
  return completer(text, state)
readline.set_completer(completer)

And completer_returning_list, the true completer, returns a pythonic iterable for all possible completion.

----------
components: Library (Lib)
messages: 152703
nosy: nicolas_49
priority: normal
severity: normal
status: open
title: readline completer could return an iterable
type: enhancement
versions: Python 3.1

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

From report at bugs.python.org  Sun Feb  5 21:25:58 2012
From: report at bugs.python.org (Jon Brandvein)
Date: Sun, 05 Feb 2012 20:25:58 +0000
Subject: [issue10482] subprocess and deadlock avoidance
In-Reply-To: <1290320162.59.0.372707956205.issue10482@psf.upfronthosting.co.za>
Message-ID: <1328473558.85.0.555951015041.issue10482@psf.upfronthosting.co.za>


Changes by Jon Brandvein <jon.brandvein at gmail.com>:


----------
nosy: +brandj

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

From report at bugs.python.org  Sun Feb  5 21:25:59 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 05 Feb 2012 20:25:59 +0000
Subject: [issue964437] idle help is modal
Message-ID: <E1Ru8eq-0007iI-Jb@dinsdale.python.org>


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

New changeset 5452c881bd2d by Terry Jan Reedy in branch '2.7':
Issue 964437 Make IDLE help window non-modal.
http://hg.python.org/cpython/rev/5452c881bd2d

New changeset a949956a80cc by Terry Jan Reedy in branch '3.2':
Issue 964437 Make IDLE help window non-modal.
http://hg.python.org/cpython/rev/a949956a80cc

New changeset 2b841adbae81 by Terry Jan Reedy in branch 'default':
Merge with 3.2 #964437
http://hg.python.org/cpython/rev/2b841adbae81

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

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

From report at bugs.python.org  Sun Feb  5 21:33:50 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 05 Feb 2012 20:33:50 +0000
Subject: [issue964437] idle help is modal
Message-ID: <1328474030.17.0.952904006693.issue964437@psf.upfronthosting.co.za>


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

I was sure I had reverted, but did again, redownloaded, applied, and tested, and all well, so committed and pushed. 2.7 required hand-patching of ', modal' for chunk 5 due to 3rd argument being 'textFile.read()' instead of 'contents'. I presume I got it right, though could not test.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Feb  5 21:40:42 2012
From: report at bugs.python.org (=?utf-8?q?Helder_Magalh=C3=A3es?=)
Date: Sun, 05 Feb 2012 20:40:42 +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: <1328474442.09.0.604751558848.issue3561@psf.upfronthosting.co.za>


Helder Magalh?es <helder.magalhaes at gmail.com> added the comment:

See tightly related ActivePython issue [1] regarding the way directories are added to the PATH environment variable.

Also, here's qooxdoo (a well-known JavaScript framework) giving out instructions [2] on how to use the official python distribution due to the missing path and file association treatment (and also redirecting the preference to ActivePython for that).

(Setting to all versions as I believe this isn't addressed in any previous or current release.)

[1] http://bugs.activestate.com/show_bug.cgi?id=92615
[2] http://manual.qooxdoo.org/current/pages/getting_started/troubleshooting.html#windows

----------
nosy: +helder-magalhaes
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4

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

From report at bugs.python.org  Sun Feb  5 21:43:46 2012
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 05 Feb 2012 20:43:46 +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: <1328474626.41.0.47488356439.issue3561@psf.upfronthosting.co.za>


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

FWIW I have an installer built which optionally adds to the path. It's not complete - still needs some GUI work to hook it all up, but I'll be proposing it shortly.

----------

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

From report at bugs.python.org  Sun Feb  5 21:48:44 2012
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 05 Feb 2012 20:48:44 +0000
Subject: [issue964437] idle help is modal
Message-ID: <1328474924.95.0.413632530441.issue964437@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I pulled the latest repo with the patch for 2.7. It works.

----------

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

From report at bugs.python.org  Sun Feb  5 22:11:39 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 05 Feb 2012 21:11:39 +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: <1328476299.32.0.869278697077.issue3561@psf.upfronthosting.co.za>


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

Helder: please don't change tracker settings unless you know what they are for. Python 2.6 and 3.1 can't possibly see any change here since they are in security fix mode, and can't see any fixes affecting this issue. Likewise, 2.7 and 3.2 will only see bug fixes. As the lack of supporting changes to Path isn't a bug (but possibly a missing feature), these versions can't see the bug, either. Putting 3.4 and 3.3 into an issue is just nonsense at this point: if the issue gets resolved for 3.3 before 3.4 is released, it will never be an issue for 3.4.

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

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

From report at bugs.python.org  Sun Feb  5 22:33:26 2012
From: report at bugs.python.org (Marko Kohtala)
Date: Sun, 05 Feb 2012 21:33:26 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1328477606.32.0.639606712378.issue9750@psf.upfronthosting.co.za>


Marko Kohtala <marko.kohtala at gmail.com> added the comment:

Here is finally an update to my patch modified according to comments received. It should apply on 2.7 and 3.3 branches.

----------
Added file: http://bugs.python.org/file24429/sqlite3dump.patch

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

From report at bugs.python.org  Sun Feb  5 22:34:06 2012
From: report at bugs.python.org (Marko Kohtala)
Date: Sun, 05 Feb 2012 21:34:06 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1328477646.93.0.587363112643.issue9750@psf.upfronthosting.co.za>


Changes by Marko Kohtala <marko.kohtala at gmail.com>:


Removed file: http://bugs.python.org/file18726/sqlite3dump.patch

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

From report at bugs.python.org  Sun Feb  5 22:34:30 2012
From: report at bugs.python.org (Marko Kohtala)
Date: Sun, 05 Feb 2012 21:34:30 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1328477670.5.0.729780606766.issue9750@psf.upfronthosting.co.za>


Changes by Marko Kohtala <marko.kohtala at gmail.com>:


Removed file: http://bugs.python.org/file18725/sqlite3bug2.py

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

From report at bugs.python.org  Sun Feb  5 22:34:35 2012
From: report at bugs.python.org (Marko Kohtala)
Date: Sun, 05 Feb 2012 21:34:35 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1328477675.92.0.660968528093.issue9750@psf.upfronthosting.co.za>


Changes by Marko Kohtala <marko.kohtala at gmail.com>:


Removed file: http://bugs.python.org/file18720/sqlite3bug.py

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

From report at bugs.python.org  Sun Feb  5 23:02:58 2012
From: report at bugs.python.org (=?utf-8?q?Helder_Magalh=C3=A3es?=)
Date: Sun, 05 Feb 2012 22:02:58 +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: <1328479378.8.0.701904519426.issue3561@psf.upfronthosting.co.za>


Helder Magalh?es <helder.magalhaes at gmail.com> added the comment:

@Brian: glad to know about it. It will surely help, as many Windows users aren't much comfortable with the console already, and even less comfortable for tweaking the system at this level (apart from permission issues, etc.). ;-)

@Martin: you're right, sorry. I'd swear I several versions selected and only a couple missing, but probably I was tricked by a related/duplicate issue. Better read the manual next time... :-)

----------

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

From report at bugs.python.org  Mon Feb  6 01:00:45 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 06 Feb 2012 00:00:45 +0000
Subject: [issue10881] test_site and macframework builds fails
In-Reply-To: <1294689247.64.0.100970558273.issue10881@psf.upfronthosting.co.za>
Message-ID: <E1RuC0h-0008OB-QX@dinsdale.python.org>


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

New changeset 82c4f094f811 by Ned Deily in branch '2.7':
Issue #10881: Fix test_site failures with OS X framework builds.
http://hg.python.org/cpython/rev/82c4f094f811

New changeset 013cba2eb008 by Ned Deily in branch '3.2':
Issue #10881: Fix test_site failure with OS X framework builds.
http://hg.python.org/cpython/rev/013cba2eb008

New changeset c88606bd5287 by Ned Deily in branch 'default':
Issue #10881: merge
http://hg.python.org/cpython/rev/c88606bd5287

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

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

From report at bugs.python.org  Mon Feb  6 01:06:21 2012
From: report at bugs.python.org (Ned Deily)
Date: Mon, 06 Feb 2012 00:06:21 +0000
Subject: [issue10881] test_site and macframework builds fails
In-Reply-To: <1294689247.64.0.100970558273.issue10881@psf.upfronthosting.co.za>
Message-ID: <1328486781.77.0.770285071323.issue10881@psf.upfronthosting.co.za>


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

Thanks, Vinay, for your analysis.  I adapted it for the applied fix.  For 2.7, there were two additional test_site failures that are fixed by back porting minor fixes to site.py and sysconfig.py from 3.x.  Applied in 2.7 (for 2.7.3), 3.2 (for 3.2.3), and default (for 3.3).

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

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

From report at bugs.python.org  Mon Feb  6 01:12:18 2012
From: report at bugs.python.org (Ned Deily)
Date: Mon, 06 Feb 2012 00:12:18 +0000
Subject: [issue13590] exension module builds fail with python.org OS X
	installers on OS X 10.7 and 10.6 with Xcode 4.2
In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za>
Message-ID: <1328487138.09.0.618120497868.issue13590@psf.upfronthosting.co.za>


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


----------
nosy: +benjamin.peterson, georg.brandl
priority: normal -> release blocker
title: Prebuilt python-2.7.2 binaries for macosx can not compile c extensions -> exension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Feb  6 01:32:13 2012
From: report at bugs.python.org (Ezra Berch)
Date: Mon, 06 Feb 2012 00:32:13 +0000
Subject: [issue13370] test_ctypes fails on osx 10.7
In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za>
Message-ID: <1328488333.37.0.262833546971.issue13370@psf.upfronthosting.co.za>


Ezra Berch <ezraberch at mac.com> added the comment:

The reason for this issue appears to be a bug in the clang optimizer. This is why it only shows up with debug disabled. When I compile with -O0 instead of -O3, the test passes.

This issue from the clang tracker may be the same issue:
http://llvm.org/bugs/show_bug.cgi?id=9524

----------
nosy: +ezberch

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

From report at bugs.python.org  Mon Feb  6 01:56:07 2012
From: report at bugs.python.org (Patrick Andrew)
Date: Mon, 06 Feb 2012 00:56:07 +0000
Subject: =?utf-8?q?=5Bissue13943=5D_distutils=E2=80=99_build=5Fpy_fails_when_packa?=
	=?utf-8?q?ge_string_is_unicode?=
In-Reply-To: <1328388068.27.0.743003863578.issue13943@psf.upfronthosting.co.za>
Message-ID: <1328489767.17.0.54463855625.issue13943@psf.upfronthosting.co.za>


Patrick Andrew <pandrew at isilon.com> added the comment:

>From py-logilab-common 0.57.1 port for FreeBSD. No patches applied:


package init file './test/__init__.py' not found (or not a regular file)
Traceback (most recent call last):
  File "setup.py", line 170, in <module>
    install()
  File "setup.py", line 166, in install
    **kwargs
  File "/usr/local/lib/python2.7/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/usr/local/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/local/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python2.7/distutils/command/build.py", line 127, in run
    self.run_command(cmd_name)
  File "/usr/local/lib/python2.7/distutils/cmd.py", line 326, in run_command
    self.distribution.run_command(command)
  File "/usr/local/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python2.7/distutils/command/build_py.py", line 93, in run
    self.build_packages()
  File "/usr/local/lib/python2.7/distutils/command/build_py.py", line 372, in build_packages
    self.build_module(module, module_file, package)
  File "/usr/local/lib/python2.7/distutils/command/build_py.py", line 333, in build_module
    "'package' must be a string (dot-separated), list, or tuple")
TypeError: 'package' must be a string (dot-separated), list, or tuple
*** Error code 1

Stop in /usr/src/ports/devel/py-logilab-common.


This package's setup.py is auto-generating the packages list with the current working directory.


def get_packages(directory, prefix):
    """return a list of subpackages for the given directory"""
    result = []
    for package in os.listdir(directory):
        absfile = join(directory, package)
        if isdir(absfile):
            if exists(join(absfile, '__init__.py')) or \
                   package in ('test', 'tests'):
                if prefix:
                    result.append('%s.%s' % (prefix, package))
                else:
                    result.append(package)
                result += get_packages(absfile, result[-1])
    return result

...

packages = [modname] + get_packages(os.getcwd(), modname)

kwargs['packages'] = packages

setup(...
    **kwargs)

where modname is imported from __pkginfo__.py:
distname = 'logilab-common'
modname = 'common'


What's interesting is there is no explicit unicode string definition within this package list gerneration, yet the final packages list looks like:

['logilab.common', u'logilab.common.test', u'logilab.common.test.data', u'logilab.common.test.data.find_test', u'logilab.common.ureports']

----------

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

From report at bugs.python.org  Mon Feb  6 01:57:39 2012
From: report at bugs.python.org (Ned Deily)
Date: Mon, 06 Feb 2012 00:57:39 +0000
Subject: [issue10881] test_site and macframework builds fails
In-Reply-To: <1294689247.64.0.100970558273.issue10881@psf.upfronthosting.co.za>
Message-ID: <1328489859.31.0.138303075059.issue10881@psf.upfronthosting.co.za>


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

P.S. I forgot to mention that one of the 2.7 test_site failures was due to the PYTHONUSERBASE env variable having no effect with OS X framework builds.  That had been fixed in 3.x; it's now back ported.

----------

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

From report at bugs.python.org  Mon Feb  6 02:29:21 2012
From: report at bugs.python.org (Meador Inge)
Date: Mon, 06 Feb 2012 01:29:21 +0000
Subject: [issue13370] test_ctypes fails on osx 10.7
In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za>
Message-ID: <1328491761.54.0.522141769908.issue13370@psf.upfronthosting.co.za>


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

So I have debugged the first failure and it has to do with the sign extending of 'signed char' parameters.  The first test case basically does this:

   _dll = CDLL(_ctypes_test.__file__)
   _dll.tf_b.restype = c_byte
   _dll.tf_b.argtypes = (c_byte,)
   _dll.tf_b(-126)

where 'tf_b' is defined in C code like:

   signed char tf_b(signed char c) { return c/3; }

Clang with -O3 generates code for 'tf_b' like:

0x0000000100000ed0 <tf_b+0>:	push   %rbp
0x0000000100000ed1 <tf_b+1>:	mov    %rsp,%rbp
0x0000000100000ed4 <tf_b+4>:	movslq %edi,%rax
0x0000000100000ed7 <tf_b+7>:	imul   $0x55555556,%rax,%rax
0x0000000100000ede <tf_b+14>:	mov    %rax,%rcx
0x0000000100000ee1 <tf_b+17>:	shr    $0x3f,%rcx
0x0000000100000ee5 <tf_b+21>:	shr    $0x20,%rax
0x0000000100000ee9 <tf_b+25>:	add    %ecx,%eax
0x0000000100000eeb <tf_b+27>:	movsbl %al,%eax
0x0000000100000eee <tf_b+30>:	pop    %rbp
0x0000000100000eef <tf_b+31>:	retq   

See how 'movslq' is used to sign extend the first argument?  Since the first argument is a 'signed char', that should be 'movsbq'.  I am pretty sure this is a clang bug.

I am going to see if this is fixed in later versions of clang.  I will also search the clang tracker to see if this has been reported.

----------

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

From report at bugs.python.org  Mon Feb  6 02:40:21 2012
From: report at bugs.python.org (Meador Inge)
Date: Mon, 06 Feb 2012 01:40:21 +0000
Subject: [issue13370] test_ctypes fails on osx 10.7
In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za>
Message-ID: <1328492421.65.0.907169062924.issue13370@psf.upfronthosting.co.za>


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

> Since the first argument is a 'signed char', that should be 'movsbq'.

Hmmm, on second thought I am not 100% sure about that exact statement, but I still think this is most likely a clang bug having something to do with sign extension.

----------

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

From report at bugs.python.org  Mon Feb  6 05:13:36 2012
From: report at bugs.python.org (Jack Miller)
Date: Mon, 06 Feb 2012 04:13:36 +0000
Subject: [issue13947] gdbm reorganize() leaves hanging file descriptor
Message-ID: <1328501616.08.0.882414908885.issue13947@psf.upfronthosting.co.za>


New submission from Jack Miller <jack at codezen.org>:

I've discovered that using either 2.7.2 or 3.2.2 (from Arch) reorganizing gdbm databases leave hanging file descriptors that will cause EAGAIN errors trying to reopen it until the process is killed. For example:

Python 2.7.2 (default, Jan 31 2012, 13:19:49) 
[GCC 4.6.2 20120120 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gdbm
>>> o = gdbm.open("test27", "c")
>>> o.reorganize()
>>> o.close()
>>> o = gdbm.open("test27", "w")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
gdbm.error: (11, 'Resource temporarily unavailable')
>>>

By using lsof you can see that after reorganize() test27 has two open file descriptors, and after close() one is still open with no (obvious) way to close it. This happens with freshly created and populated databases and regardless of open mode flags.

I also tested this on 3.2.2 with dbm.gnu and got identical behavior.

----------
messages: 152719
nosy: themoken
priority: normal
severity: normal
status: open
title: gdbm reorganize() leaves hanging file descriptor
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Feb  6 05:48:24 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 06 Feb 2012 04:48:24 +0000
Subject: [issue13947] gdbm reorganize() leaves hanging file descriptor
In-Reply-To: <1328501616.08.0.882414908885.issue13947@psf.upfronthosting.co.za>
Message-ID: <1328503704.67.0.844583438444.issue13947@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I can not reproduce the issue with GDBM 1.9.1, neither GDBM 1.8.3, neither GDBM 1.10, under Solaris.

I don't see the file descriptor leak either.

According to http://sunsite.ualberta.ca/Documentation/Gnu/gdbm-1.8.0/html_node/gdbm_10.html, all file descriptor management is done inside GDBM.

What GDBM are you using?. Could you possibly upgrade?. Beware, 1.8 and 1.9/1.10 fileformats are *NOT* compatible.

----------
nosy: +jcea
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Mon Feb  6 05:52:04 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 06 Feb 2012 04:52:04 +0000
Subject: [issue13947] gdbm reorganize() leaves hanging file descriptor
In-Reply-To: <1328501616.08.0.882414908885.issue13947@psf.upfronthosting.co.za>
Message-ID: <1328503924.19.0.795129411197.issue13947@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Can't reproduce either in Ubuntu 10.04, 64 bits, with GDBM 1.8.3.

Closing bug.

Reporter, please indicate your GDBM version. Can you possibly upgrade it?.

----------
stage:  -> committed/rejected

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

From report at bugs.python.org  Mon Feb  6 06:22:14 2012
From: report at bugs.python.org (Jack Miller)
Date: Mon, 06 Feb 2012 05:22:14 +0000
Subject: [issue13947] gdbm reorganize() leaves hanging file descriptor
In-Reply-To: <1328501616.08.0.882414908885.issue13947@psf.upfronthosting.co.za>
Message-ID: <1328505734.13.0.310148693836.issue13947@psf.upfronthosting.co.za>


Jack Miller <jack at codezen.org> added the comment:

I am using gdbm 1.10, the latest available.

pacman says:
core/gdbm 1.10-1 [installed]
    GNU database library

Which also contains the file (libgdbm.so.4) that Python's gdbm.so is linked to (just in case there was some version trickery going on here).

I guess it's possible this is Arch brokenness, but the only patch applied to the 1.10 code in the PKGBUILD is malloc -> calloc for a known bug.

----------

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

From report at bugs.python.org  Mon Feb  6 07:11:14 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 06 Feb 2012 06:11:14 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1328508674.15.0.948121616701.issue13703@psf.upfronthosting.co.za>


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

IIUC, Win9x and NT4 are not supported anymore in any of the target releases of the patch, so calling CryptGenRandom should be fine.

In a security fix release, we shouldn't change the linkage procedures, so I recommend that the LoadLibrary dance remains.

----------

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

From report at bugs.python.org  Mon Feb  6 07:40:53 2012
From: report at bugs.python.org (Samuel Iseli)
Date: Mon, 06 Feb 2012 06:40:53 +0000
Subject: [issue13889] str(float) and round(float) issues with FPU precision
In-Reply-To: <1327676303.66.0.487112802864.issue13889@psf.upfronthosting.co.za>
Message-ID: <1328510453.58.0.178571282176.issue13889@psf.upfronthosting.co.za>


Samuel Iseli <samuel.iseli at gmail.com> added the comment:

I can run the tests on 32bit. Would be nice if somebody else could do this on 64bit (my VS2008 machine is currently on 32bit-Windows).

----------

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

From report at bugs.python.org  Mon Feb  6 09:28:08 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 06 Feb 2012 08:28:08 +0000
Subject: [issue13948] rm needless use of set function
Message-ID: <1328516888.02.0.726524948471.issue13948@psf.upfronthosting.co.za>


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

I assume that the set() function was used to get rid of duplicates from self.versions, but there aren't any and the test would pass even if there were.

----------
assignee: tarek
components: Distutils2
files: rm-needless-use-of-set-function.patch
keywords: patch
messages: 152725
nosy: alexis, eric.araujo, tarek, tshepang
priority: normal
severity: normal
status: open
title: rm needless use of set function
type: behavior
Added file: http://bugs.python.org/file24430/rm-needless-use-of-set-function.patch

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

From report at bugs.python.org  Mon Feb  6 09:30:20 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 06 Feb 2012 08:30:20 +0000
Subject: [issue13949] rm needless use of pass statement
Message-ID: <1328517020.67.0.388528127173.issue13949@psf.upfronthosting.co.za>


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

I found the use of the pass statement redundant.

----------
assignee: tarek
components: Distutils2
files: rm-needless-use-of-pass-keyword.patch
keywords: patch
messages: 152726
nosy: alexis, eric.araujo, tarek, tshepang
priority: normal
severity: normal
status: open
title: rm needless use of pass statement
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24431/rm-needless-use-of-pass-keyword.patch

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

From report at bugs.python.org  Mon Feb  6 09:32:27 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 06 Feb 2012 08:32:27 +0000
Subject: [issue13950] rm commented-out code
Message-ID: <1328517147.42.0.318507953737.issue13950@psf.upfronthosting.co.za>


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

It does not appear that the commented-out code adds any value. If anything, it's maybe just a distraction.

----------
assignee: tarek
components: Distutils2
files: rm-commented-out-code.patch
keywords: patch
messages: 152727
nosy: alexis, eric.araujo, tarek, tshepang
priority: normal
severity: normal
status: open
title: rm commented-out code
versions: Python 3.3
Added file: http://bugs.python.org/file24432/rm-commented-out-code.patch

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

From report at bugs.python.org  Mon Feb  6 09:35:21 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 06 Feb 2012 08:35:21 +0000
Subject: [issue13889] str(float) and round(float) issues with FPU precision
In-Reply-To: <1327676303.66.0.487112802864.issue13889@psf.upfronthosting.co.za>
Message-ID: <1328517321.62.0.115719120388.issue13889@psf.upfronthosting.co.za>


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

I can run the tests on win64, but it I think it would be nice to
have a patch with exactly the same logic as the gcc-asm version
(Mark already mentioned _MCW_PC | _MCW_RC).

Another thing: _WIN32 might be defined on MinGW, but I'm not sure.
If that's the case, it would be nice to guard the VS specific
passage with _MSC_VER.

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

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

From report at bugs.python.org  Mon Feb  6 09:50:00 2012
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 06 Feb 2012 08:50:00 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1328518200.96.0.59988530925.issue4709@psf.upfronthosting.co.za>


Ralf Schmitt <python-bugs at systemexit.de> added the comment:

Marting, this issue is about building python extensions with mingw-w64 not about building python itself.

----------

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

From report at bugs.python.org  Mon Feb  6 10:53:02 2012
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Feb 2012 09:53:02 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1328508674.15.0.948121616701.issue13703@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbiSr2kzQU+bMrnrvdNN_1Q0Hcf-T3dW_5SE6+-jQGXhQ@mail.gmail.com>


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

> In a security fix release, we shouldn't change the linkage procedures,
> so I recommend that the LoadLibrary dance remains.

So the overhead in startup time is not an issue?

----------

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

From report at bugs.python.org  Mon Feb  6 11:20:35 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 06 Feb 2012 10:20:35 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <CAMpsgwbiSr2kzQU+bMrnrvdNN_1Q0Hcf-T3dW_5SE6+-jQGXhQ@mail.gmail.com>
Message-ID: <4F2FA96D.1080600@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:
> 
>> In a security fix release, we shouldn't change the linkage procedures,
>> so I recommend that the LoadLibrary dance remains.
> 
> So the overhead in startup time is not an issue?

It is an issue. Not only in terms of startup time, but also
because randomization per default makes Python behave in
non-deterministc ways - which is not what you want from a
programming language or interpreter (unless you explicitly
tell it to behave like that).

I think it would be much better to just let the user
define a hash seed using environment variables for Python
to use and then forget about how this variable value is
determined. If it's not set, Python uses 0 as seed, thereby
disabling the seeding logic.

This approach would have Python behave in a deterministic way
per default and still allow users who wish to use a different
seed, set this to a different value - even on a case by case
basis.

If you absolutely want to add a feature to have the seed set
randomly, you could make a seed value of -1 trigger the use
of a random number source as seed.

I also still firmly believe that the collision counting scheme
should be made available via an environment variable as well.
The user could then set the variable to e.g. 1000 to have it
enabled with limit 1000, or leave it undefined to disable the
collision counting.

With those two tools, users could then choose the method they
find most attractive for their purposes.

By default, they would be disabled, but applications which are
exposed to untrusted user data and use dictionaries for managing
such data could check whether the protections are enabled and
trigger a startup error if needed.

----------

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

From report at bugs.python.org  Mon Feb  6 12:18:53 2012
From: report at bugs.python.org (Ned Deily)
Date: Mon, 06 Feb 2012 11:18:53 +0000
Subject: [issue13590] exension module builds fail with python.org OS X
	installers on OS X 10.7 and 10.6 with Xcode 4.2
In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za>
Message-ID: <1328527133.1.0.363905440393.issue13590@psf.upfronthosting.co.za>


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


----------
assignee: ronaldoussoren -> ned.deily

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

From report at bugs.python.org  Mon Feb  6 13:22:28 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Feb 2012 12:22:28 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <4F2FA96D.1080600@egenix.com>
Message-ID: <1328530786.3478.7.camel@localhost.localdomain>


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

> It is an issue. Not only in terms of startup time, but also
> because randomization per default makes Python behave in
> non-deterministc ways - which is not what you want from a
> programming language or interpreter (unless you explicitly
> tell it to behave like that).

That's debatable. For example id() is fairly unpredictable accross runs
(except for statically-allocated instances).

> I think it would be much better to just let the user
> define a hash seed using environment variables for Python
> to use and then forget about how this variable value is
> determined. If it's not set, Python uses 0 as seed, thereby
> disabling the seeding logic.
> 
> This approach would have Python behave in a deterministic way
> per default and still allow users who wish to use a different
> seed, set this to a different value - even on a case by case
> basis.
> 
> If you absolutely want to add a feature to have the seed set
> randomly, you could make a seed value of -1 trigger the use
> of a random number source as seed.

Having both may indeed be a good idea.

> I also still firmly believe that the collision counting scheme
> should be made available via an environment variable as well.
> The user could then set the variable to e.g. 1000 to have it
> enabled with limit 1000, or leave it undefined to disable the
> collision counting.
> 
> With those two tools, users could then choose the method they
> find most attractive for their purposes.

It's not about being attractive, it's about fixing the security problem.
The simple collision counting approach leaves a gaping hole open, as
demonstrated by Frank.

----------

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

From report at bugs.python.org  Mon Feb  6 13:46:58 2012
From: report at bugs.python.org (zxw)
Date: Mon, 06 Feb 2012 12:46:58 +0000
Subject: [issue13931] os.path.exists inconsistent between 32 bit and 64 bit
In-Reply-To: <1328283896.91.0.836013924946.issue13931@psf.upfronthosting.co.za>
Message-ID: <1328532418.06.0.280973385826.issue13931@psf.upfronthosting.co.za>


zxw <eeyore.tkc at gmail.com> added the comment:

I've posted the code to http://code.activestate.com/recipes/578035-disable-file-system-redirector/

----------

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

From report at bugs.python.org  Mon Feb  6 14:12:41 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 06 Feb 2012 13:12:41 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1328530786.3478.7.camel@localhost.localdomain>
Message-ID: <4F2FD1C4.1000104@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> The simple collision counting approach leaves a gaping hole open, as
> demonstrated by Frank.

Could you elaborate on this ?

Note that I've updated the collision counting patch to cover both
possible attack cases I mentioned in http://bugs.python.org/issue13703#msg150724.
If there's another case I'm unaware of, please let me know.

----------

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

From report at bugs.python.org  Mon Feb  6 14:30:30 2012
From: report at bugs.python.org (Graeme Glass)
Date: Mon, 06 Feb 2012 13:30:30 +0000
Subject: [issue13951] Seg Fault in .so called by ctypes causes the interpreter
	to Seg Fault
Message-ID: <1328535030.63.0.73417525944.issue13951@psf.upfronthosting.co.za>


New submission from Graeme Glass <graemeglass at gmail.com>:

When doing something obviously incorrect (read, wrong/stupid) while calling libX11.so.6 via ctypes, it causes a Segmentation fault, which in turn cause the python interpreter to fall over with a Segmentation fault.  

My question is, is this the correct behaviour? Should it seg fault or just throw an exception? 

Details below.

graeme at roger:~$ uname -a
Linux roger 3.0.0-15-generic-pae #26-Ubuntu SMP Fri Jan 20 17:07:31 UTC 2012 i686 i686 i386 GNU/Linux

graeme at roger:~$ python 
Python 2.7.2+ (default, Oct  4 2011, 20:03:08) 
[GCC 4.6.1] on linux2

graeme at roger:~$ python2.6
Python 2.6.7 (r267:88850, Aug 11 2011, 12:16:10) 
[GCC 4.6.1] on linux2

## The example code
graeme at roger:~$ cat xtest.py 

from ctypes import cdll
dll = cdll.LoadLibrary('libX11.so.6')
d = dll.XOpenDisplay(None)
root = dll.XDefaultRootWindow(d)
dll.XWarpPointer(d,None,root,0,0,0,0,20,39)
dll.XCloseDisplay(d)
dll.XCloseDisplay(d) #2nd call, should not be called, is not needed. Causes seg fault.

##The results
graeme at roger:~$ pdb2.7 xtest.py 
> /home/graeme/xtest.py(1)<module>()
-> from ctypes import cdll
(Pdb) c
Segmentation fault

graeme at roger:~$ python2.7 xtest.py 
Segmentation fault

graeme at roger:~$ ipython-2.7 xtest.py 
Segmentation fault

graeme at roger:~$ ipython-2.6 xtest.py 
Segmentation fault

graeme at roger:~$ gdb python2.7
(gdb) set args xtest.py
(gdb) run
Starting program: /usr/bin/python xtest.py
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x151) at malloc.c:3709
3709	malloc.c: No such file or directory.
	in malloc.c


graeme at roger:~$ python2.6 xtest.py 
*** glibc detected *** python2.6: double free or corruption (!prev): 0x083533a0 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x6ebc2)[0xb7402bc2]
/lib/i386-linux-gnu/libc.so.6(+0x6f862)[0xb7403862]
/lib/i386-linux-gnu/libc.so.6(cfree+0x6d)[0xb740694d]
/usr/lib/i386-linux-gnu/libX11.so.6(+0x9232b)[0xb6ff732b]
/usr/lib/i386-linux-gnu/libX11.so.6(_XFreeDisplayStructure+0x16f)[0xb6f8bddf]
/usr/lib/i386-linux-gnu/libX11.so.6(XCloseDisplay+0xd9)[0xb6f78179]
/usr/lib/python2.6/lib-dynload/_ctypes.so(ffi_call_SYSV+0x1a)[0xb70c548a]
/usr/lib/python2.6/lib-dynload/_ctypes.so(ffi_call+0x6f)[0xb70c51bf]
/usr/lib/python2.6/lib-dynload/_ctypes.so(_CallProc+0x2c2)[0xb70bfd12]
/usr/lib/python2.6/lib-dynload/_ctypes.so(+0x61ed)[0xb70b71ed]
python2.6(PyObject_Call+0x4d)[0x80648cd]
python2.6(PyEval_EvalFrameEx+0x3984)[0x80d6514]
python2.6(PyEval_EvalCodeEx+0x882)[0x80d96e2]
python2.6(PyEval_EvalCode+0x57)[0x80d97e7]
python2.6(PyRun_FileExFlags+0xa6)[0x80f8b26]
python2.6(PyRun_SimpleFileExFlags+0xc6)[0x80f98b6]
python2.6(Py_Main+0xa49)[0x805be59]
python2.6(main+0x1b)[0x805affb]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb73ad113]
python2.6[0x805b021]
======= Memory map: ========
08048000-08255000 r-xp 00000000 08:06 4459238    /usr/bin/python2.6
08255000-08256000 r--p 0020c000 08:06 4459238    /usr/bin/python2.6
08256000-082a5000 rw-p 0020d000 08:06 4459238    /usr/bin/python2.6
082a5000-082ae000 rw-p 00000000 00:00 0 
082d2000-08374000 rw-p 00000000 00:00 0          [heap]
b6e00000-b6e21000 rw-p 00000000 00:00 0 
b6e21000-b6f00000 ---p 00000000 00:00 0 
b6f28000-b6f44000 r-xp 00000000 08:06 2097174    /lib/i386-linux-gnu/libgcc_s.so.1
b6f44000-b6f45000 r--p 0001b000 08:06 2097174    /lib/i386-linux-gnu/libgcc_s.so.1
b6f45000-b6f46000 rw-p 0001c000 08:06 2097174    /lib/i386-linux-gnu/libgcc_s.so.1
b6f46000-b6f63000 r-xp 00000000 08:06 4458588    /usr/lib/i386-linux-gnu/libxcb.so.1.1.0
b6f63000-b6f64000 r--p 0001c000 08:06 4458588    /usr/lib/i386-linux-gnu/libxcb.so.1.1.0
b6f64000-b6f65000 rw-p 0001d000 08:06 4458588    /usr/lib/i386-linux-gnu/libxcb.so.1.1.0
b6f65000-b7096000 r-xp 00000000 08:06 4458582    /usr/lib/i386-linux-gnu/libX11.so.6.3.0
b7096000-b7097000 ---p 00131000 08:06 4458582    /usr/lib/i386-linux-gnu/libX11.so.6.3.0
b7097000-b7098000 r--p 00131000 08:06 4458582    /usr/lib/i386-linux-gnu/libX11.so.6.3.0
b7098000-b709a000 rw-p 00132000 08:06 4458582    /usr/lib/i386-linux-gnu/libX11.so.6.3.0
b709a000-b709b000 rw-p 00000000 00:00 0 
b70b1000-b70c8000 r-xp 00000000 08:06 3634       /usr/lib/python2.6/lib-dynload/_ctypes.so
b70c8000-b70cb000 r--p 00017000 08:06 3634       /usr/lib/python2.6/lib-dynload/_ctypes.so
b70cb000-b70ce000 rw-p 0001a000 08:06 3634       /usr/lib/python2.6/lib-dynload/_ctypes.so
b70ce000-b710f000 rw-p 00000000 00:00 0 
b7110000-b7111000 r--p 00299000 08:06 4464349    /usr/lib/locale/locale-archive
b7111000-b7311000 r--p 00000000 08:06 4464349    /usr/lib/locale/locale-archive
b7311000-b7394000 rw-p 00000000 00:00 0 
b7394000-b750a000 r-xp 00000000 08:06 2097561    /lib/i386-linux-gnu/libc-2.13.so
b750a000-b750c000 r--p 00176000 08:06 2097561    /lib/i386-linux-gnu/libc-2.13.so
b750c000-b750d000 rw-p 00178000 08:06 2097561    /lib/i386-linux-gnu/libc-2.13.so
b750d000-b7511000 rw-p 00000000 00:00 0 
b7511000-b7539000 r-xp 00000000 08:06 2097567    /lib/i386-linux-gnu/libm-2.13.so
b7539000-b753a000 r--p 00028000 08:06 2097567    /lib/i386-linux-gnu/libm-2.13.so
b753a000-b753b000 rw-p 00029000 08:06 2097567    /lib/i386-linux-gnu/libm-2.13.so
b753b000-b754e000 r-xp 00000000 08:06 2098068    /lib/i386-linux-gnu/libz.so.1.2.3.4
b754e000-b754f000 r--p 00012000 08:06 2098068    /lib/i386-linux-gnu/libz.so.1.2.3.4
b754f000-b7550000 rw-p 00013000 08:06 2098068    /lib/i386-linux-gnu/libz.so.1.2.3.4
b7550000-b76dd000 r-xp 00000000 08:06 2097531    /lib/i386-linux-gnu/libcrypto.so.1.0.0
b76dd000-b76eb000 r--p 0018c000 08:06 2097531    /lib/i386-linux-gnu/libcrypto.so.1.0.0
b76eb000-b76f1000 rw-p 0019a000 08:06 2097531    /lib/i386-linux-gnu/libcrypto.so.1.0.0
b76f1000-b76f4000 rw-p 00000000 00:00 0 
b76f4000-b773c000 r-xp 00000000 08:06 2097532    /lib/i386-linux-gnu/libssl.so.1.0.0
b773c000-b773e000 r--p 00047000 08:06 2097532    /lib/i386-linux-gnu/libssl.so.1.0.0
b773e000-b7741000 rw-p 00049000 08:06 2097532    /lib/i386-linux-gnu/libssl.so.1.0.0
b7741000-b7743000 r-xp 00000000 08:06 2099412    /lib/i386-linux-gnu/libutil-2.13.so
b7743000-b7744000 r--p 00001000 08:06 2099412    /lib/i386-linux-gnu/libutil-2.13.so
b7744000-b7745000 rw-p 00002000 08:06 2099412    /lib/i386-linux-gnu/libutil-2.13.so
b7745000-b7746000 rw-p 00000000 00:00 0 
b7746000-b7749000 r-xp 00000000 08:06 2097565    /lib/i386-linux-gnu/libdl-2.13.so
b7749000-b774a000 r--p 00002000 08:06 2097565    /lib/i386-linux-gnu/libdl-2.13.so
b774a000-b774b000 rw-p 00003000 08:06 2097565    /lib/i386-linux-gnu/libdl-2.13.so
b774b000-b7762000 r-xp 00000000 08:06 2099407    /lib/i386-linux-gnu/libpthread-2.13.so
b7762000-b7763000 r--p 00016000 08:06 2099407    /lib/i386-linux-gnu/libpthread-2.13.so
b7763000-b7764000 rw-p 00017000 08:06 2099407    /lib/i386-linux-gnu/libpthread-2.13.so
b7764000-b7766000 rw-p 00000000 00:00 0 
b7770000-b7775000 r-xp 00000000 08:06 4458586    /usr/lib/i386-linux-gnu/libXdmcp.so.6.0.0
b7775000-b7776000 r--p 00004000 08:06 4458586    /usr/lib/i386-linux-gnu/libXdmcp.so.6.0.0
b7776000-b7777000 rw-p 00005000 08:06 4458586    /usr/lib/i386-linux-gnu/libXdmcp.so.6.0.0
b7777000-b7779000 r-xp 00000000 08:06 4458584    /usr/lib/i386-linux-gnu/libXau.so.6.0.0
b7779000-b777a000 r--p 00001000 08:06 4458584    /usr/lib/i386-linux-gnu/libXau.so.6.0.0
b777a000-b777b000 rw-p 00002000 08:06 4458584    /usr/lib/i386-linux-gnu/libXau.so.6.0.0
b777b000-b777c000 rwxp 00000000 00:00 0 
b777c000-b777e000 rw-p 00000000 00:00 0 
b777e000-b777f000 r-xp 00000000 00:00 0          [vdso]
b777f000-b779d000 r-xp 00000000 08:06 2097504    /lib/i386-linux-gnu/ld-2.13.so
b779d000-b779e000 r--p 0001d000 08:06 2097504    /lib/i386-linux-gnu/ld-2.13.so
b779e000-b779f000 rw-p 0001e000 08:06 2097504    /lib/i386-linux-gnu/ld-2.13.so
bfb52000-bfb73000 rw-p 00000000 00:00 0          [stack]
Aborted

----------
components: ctypes
messages: 152735
nosy: graemeglass
priority: normal
severity: normal
status: open
title: Seg Fault in .so called by ctypes causes the interpreter to Seg Fault
type: crash
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Feb  6 15:11:28 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Feb 2012 14:11:28 +0000
Subject: [issue13590] extension module builds fail with python.org OS X
	installers on OS X 10.7 and 10.6 with Xcode 4.2
In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za>
Message-ID: <1328537488.58.0.268847835749.issue13590@psf.upfronthosting.co.za>


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


----------
title: exension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2 -> extension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2

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

From report at bugs.python.org  Mon Feb  6 15:34:21 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Feb 2012 14:34:21 +0000
Subject: [issue13950] rm commented-out code
In-Reply-To: <1328517147.42.0.318507953737.issue13950@psf.upfronthosting.co.za>
Message-ID: <1328538861.86.0.634332014892.issue13950@psf.upfronthosting.co.za>


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

Before Tarek started the distutils2 project, the version code lived standalone and its README file served as doctest.  Most of its text was moved to PEP 386 and the tests themselves to test_verlib (and now test_version): https://bitbucket.org/tarek/distutilsversion/changeset/140170ef3896#chg-README.txt

So you?re right, the lines that your patch removes are indeed unneeded, but I?d just like to check that all tests were moved into test_version before applying it.

----------
assignee: tarek -> eric.araujo
versions: +3rd party

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

From report at bugs.python.org  Mon Feb  6 15:35:48 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Feb 2012 14:35:48 +0000
Subject: [issue13949] rm needless use of pass statement
In-Reply-To: <1328517020.67.0.388528127173.issue13949@psf.upfronthosting.co.za>
Message-ID: <1328538948.48.0.604793441928.issue13949@psf.upfronthosting.co.za>


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

Sure, I?ll apply this.

----------
assignee: tarek -> eric.araujo
versions: +3rd party

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

From report at bugs.python.org  Mon Feb  6 16:01:22 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Feb 2012 15:01:22 +0000
Subject: [issue13948] rm needless use of set function
In-Reply-To: <1328516888.02.0.726524948471.issue13948@psf.upfronthosting.co.za>
Message-ID: <1328540482.25.0.433190544648.issue13948@psf.upfronthosting.co.za>


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

Yes, this test method could be a little clearer.  I?ll do this.

----------
assignee: tarek -> eric.araujo
versions: +3rd party

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

From report at bugs.python.org  Mon Feb  6 16:24:59 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 06 Feb 2012 15:24:59 +0000
Subject: [issue13951] Seg Fault in .so called by ctypes causes the interpreter
	to Seg Fault
In-Reply-To: <1328535030.63.0.73417525944.issue13951@psf.upfronthosting.co.za>
Message-ID: <1328541899.61.0.224204093059.issue13951@psf.upfronthosting.co.za>


Ramchandra Apte <maniandram01 at gmail.com> added the comment:

It is the correct behaviour for an invalid usage to segfault and is also mentioned in the documentation.
Can somebody close this bug as invalid?

----------
nosy: +ramchandra.apte

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

From report at bugs.python.org  Mon Feb  6 16:47:07 2012
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 06 Feb 2012 15:47:07 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <4F2FD1C4.1000104@egenix.com>
Message-ID: <CA+OGgf7zc0N1-5naq-0h78uPigbRdDE7_iwAEf8jTOLXqCFp_w@mail.gmail.com>


Jim Jewett <jimjjewett at gmail.com> added the comment:

On Mon, Feb 6, 2012 at 8:12 AM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
>
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>
> Antoine Pitrou wrote:
>>
>> The simple collision counting approach leaves a gaping hole open, as
>> demonstrated by Frank.

> Could you elaborate on this ?

> Note that I've updated the collision counting patch to cover both
> possible attack cases I mentioned in http://bugs.python.org/issue13703#msg150724.
> If there's another case I'm unaware of, please let me know.

The problematic case is, roughly,

(1)  Find out what N will trigger collision-counting countermeasures.
(2)  Insert N-1 colliding entries, to make it as slow as possible.
(3)  Keep looking up (or updating) the N-1th entry, so that the
slow-as-possible-without-countermeasures path keeps getting rerun.

----------

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

From report at bugs.python.org  Mon Feb  6 16:50:21 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Feb 2012 15:50:21 +0000
Subject: [issue13938] 2to3 fails to convert types.StringTypes appropriately
In-Reply-To: <1328333493.54.0.112859472866.issue13938@psf.upfronthosting.co.za>
Message-ID: <1328543421.19.0.426592066834.issue13938@psf.upfronthosting.co.za>


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


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson
versions: +Python 2.7 -Python 3.4

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

From report at bugs.python.org  Mon Feb  6 16:51:33 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Feb 2012 15:51:33 +0000
Subject: [issue1040439] Missing documentation on how to link with libpython
Message-ID: <1328543493.14.0.0255328761893.issue1040439@psf.upfronthosting.co.za>


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

Is there still work to do on this issue?

----------

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

From report at bugs.python.org  Mon Feb  6 17:10:12 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 06 Feb 2012 16:10:12 +0000
Subject: [issue13951] please close - Seg Fault in .so called by ctypes causes
	the interpreter to Seg Fault
In-Reply-To: <1328535030.63.0.73417525944.issue13951@psf.upfronthosting.co.za>
Message-ID: <1328544612.18.0.38742122184.issue13951@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
title: Seg Fault in .so called by ctypes causes the interpreter to Seg Fault -> please close - Seg Fault in .so called by ctypes causes the interpreter to Seg Fault

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

From report at bugs.python.org  Mon Feb  6 17:20:59 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Feb 2012 16:20:59 +0000
Subject: [issue1040439] Missing documentation on how to link with libpython
Message-ID: <1328545259.19.0.339436682557.issue1040439@psf.upfronthosting.co.za>


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

> Is there still work to do on this issue?

Not for Unix, no. I don't if it's applicable to Windows.

----------

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

From report at bugs.python.org  Mon Feb  6 17:25:04 2012
From: report at bugs.python.org (John Pye)
Date: Mon, 06 Feb 2012 16:25:04 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1328545504.04.0.435359911963.issue4709@psf.upfronthosting.co.za>


John Pye <john at curioussymbols.com> added the comment:

Martin, Ralf is right and my as previously linked is about building a python extension. I should have been more explicit about that.

FWIW I found that the configure scripts on MinGW-w64 generally work fine if you add a "--build=x86_64-w64-mingw32" argument on the ./configure command line. Then you should only add /mingw/bin to your path (and edit /etc/fstab to map c:/mingw64 to /mingw). Adding those subdirectories to the PATH doesn't seem to be successful; I suspect that those binaries are off the standard path for some reason, eg internal use by GCC only, or something (GCC seems to do some clever tricks with relative paths, so I'm sure it's important that you use the correct starting executable).

----------

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

From report at bugs.python.org  Mon Feb  6 17:36:20 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 06 Feb 2012 16:36:20 +0000
Subject: [issue13951] Seg Fault in .so called by ctypes causes the interpreter
	to Seg Fault
In-Reply-To: <1328535030.63.0.73417525944.issue13951@psf.upfronthosting.co.za>
Message-ID: <1328546180.74.0.860120423953.issue13951@psf.upfronthosting.co.za>


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

[Please do not change issue titles - your recommendation was enough]

Indeed, incorrect usage of ctypes can crash the program, and there is nothing Python can do.

But I could not find any warning about this in the documentation, except maybe this sentence: "There are, however, enough ways to crash Python with ctypes, so you should be careful anyway."
Let's turn this into a doc issue, then.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +amaury.forgeotdarc, docs at python
title: please close - Seg Fault in .so called by ctypes causes the interpreter to Seg Fault -> Seg Fault in .so called by ctypes causes the interpreter to Seg Fault

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

From report at bugs.python.org  Mon Feb  6 17:42:43 2012
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 06 Feb 2012 16:42:43 +0000
Subject: [issue13903] New shared-keys dictionary implementation
In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za>
Message-ID: <1328546563.42.0.0174479607823.issue13903@psf.upfronthosting.co.za>


Changes by Mark Shannon <mark at hotpy.org>:


----------
hgrepos:  -109

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

From report at bugs.python.org  Mon Feb  6 17:44:26 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Feb 2012 16:44:26 +0000
Subject: [issue11805] package_data only allows one glob per-package
In-Reply-To: <1302301429.27.0.797210396018.issue11805@psf.upfronthosting.co.za>
Message-ID: <1328546666.12.0.856486697858.issue11805@psf.upfronthosting.co.za>


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

(I forgot that distutils2?s setup.py has its own fork of the conversion functions, for bootstrapping reasons, so I need to port the fix there.)

----------

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

From report at bugs.python.org  Mon Feb  6 17:55:11 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Feb 2012 16:55:11 +0000
Subject: [issue5302] Allow package_data specs/globs to match directories
In-Reply-To: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za>
Message-ID: <1328547311.13.0.721161169751.issue5302@psf.upfronthosting.co.za>


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

One implementation by George Sakkis is found in this thread: http://bugs.python.org/issue2279#msg82213

There are subtle issues with this feature.  For example, a glob pattern could match both package data files and Python submodules, leading to the same .py files being included as modules and data.  I?ll see how far I want to specify the behavior in tests and docs.

----------

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

From report at bugs.python.org  Mon Feb  6 18:07:35 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 06 Feb 2012 17:07:35 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <CA+OGgf7zc0N1-5naq-0h78uPigbRdDE7_iwAEf8jTOLXqCFp_w@mail.gmail.com>
Message-ID: <4F3008D2.5060509@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Jim Jewett wrote:
> 
> Jim Jewett <jimjjewett at gmail.com> added the comment:
> 
> On Mon, Feb 6, 2012 at 8:12 AM, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
>>
>> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>>
>> Antoine Pitrou wrote:
>>>
>>> The simple collision counting approach leaves a gaping hole open, as
>>> demonstrated by Frank.
> 
>> Could you elaborate on this ?
> 
>> Note that I've updated the collision counting patch to cover both
>> possible attack cases I mentioned in http://bugs.python.org/issue13703#msg150724.
>> If there's another case I'm unaware of, please let me know.
> 
> The problematic case is, roughly,
> 
> (1)  Find out what N will trigger collision-counting countermeasures.
> (2)  Insert N-1 colliding entries, to make it as slow as possible.
> (3)  Keep looking up (or updating) the N-1th entry, so that the
> slow-as-possible-without-countermeasures path keeps getting rerun.

Since N is constant, I don't see how such an "attack" could be used
to trigger the O(n^2) worst-case behavior. Even if you can create n sets
of entries that each fill up N-1 positions, the overall performance
will still be O(n*N*(N-1)/2) = O(n).

So in the end, we're talking about a regular brute force DoS attack,
which requires different measures than dictionary implementation
tricks :-)

BTW: If you set the limit N to e.g. 100 (which is reasonable given
Victor's and my tests), the time it takes to process one of those
sets only takes 0.3 ms on my machine. That's hardly usable as basis
for an effective DoS attack.

----------

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

From report at bugs.python.org  Mon Feb  6 18:11:38 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Feb 2012 17:11:38 +0000
Subject: [issue5411] add xz compression support to shutil
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1328548298.83.0.922423702686.issue5411@psf.upfronthosting.co.za>


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

This not-so-bad patch adds lzma compression support to the shutil functions, under the 'xztar' name.  Please review.

----------
Added file: http://bugs.python.org/file24433/shutil-xz.diff

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

From report at bugs.python.org  Mon Feb  6 18:16:12 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Feb 2012 17:16:12 +0000
Subject: [issue5411] add xz compression support to shutil
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1328548572.41.0.116224225919.issue5411@psf.upfronthosting.co.za>


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

I should add that a doc update will be part of the next patch.

In parallel, I?ve also started updating packaging to add lzma support to the bdist command, but the situation is very disappointing: tarfile knows what format it supports, shutil has its own list, and packaging has a few duplicates too!  Ideally, tarfile should have an attribute to expose what compression formats are available, then shutil would reuse that, and packaging would just call shutil.  (I?m not even talking about the duplication in the doc.)  If you agree with the general idea, I?ll open reports to a) add the attribute to tarfile b) rework the (luckily internal) registries in shutil to stop being hard-coded c) remove packaging?s registries.

----------

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

From report at bugs.python.org  Mon Feb  6 18:18:22 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Feb 2012 17:18:22 +0000
Subject: [issue12703] Improve error reporting for packaging.util.resolve_name
In-Reply-To: <1312626935.87.0.525014153536.issue12703@psf.upfronthosting.co.za>
Message-ID: <1328548702.97.0.505185353693.issue12703@psf.upfronthosting.co.za>


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

In the absence of feedback, I?m going to apply my find_object idea as described in my previous message.

----------

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

From report at bugs.python.org  Mon Feb  6 18:43:56 2012
From: report at bugs.python.org (Ian Davis)
Date: Mon, 06 Feb 2012 17:43:56 +0000
Subject: [issue13952] mimetypes doesn't recognize .csv
Message-ID: <1328550236.31.0.476108753678.issue13952@psf.upfronthosting.co.za>


New submission from Ian Davis <iwd32900 at yahoo.com>:

The mimetypes module does not respond with "text/csv" for files that end in ".csv", and I think it should  :)  For goodness sake, "text/tab-delimited-values" is in there as ".tsv", and that seems much less used (to me).

----------
components: Library (Lib)
messages: 152751
nosy: iwd32900
priority: normal
severity: normal
status: open
title: mimetypes doesn't recognize .csv
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Feb  6 19:04:26 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Feb 2012 18:04:26 +0000
Subject: [issue13952] mimetypes doesn't recognize .csv
In-Reply-To: <1328550236.31.0.476108753678.issue13952@psf.upfronthosting.co.za>
Message-ID: <1328551466.65.0.468920279905.issue13952@psf.upfronthosting.co.za>


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

Yes, but text/tab-delimited-values/.tsv is older.  .tsv dates from the days of Gopher, but text/csv was formalized only in October of 2005.  Presumably nobody has asked for it before, for some odd reason.

Now we get to debate again whether updating mimetypes with a registered type can be considered a bug fix.  We've gone both ways in the past, as far as I can tell.  This one has the advantage of actually having a formal IANA registration, unlike the last couple.

----------
nosy: +r.david.murray
stage:  -> needs patch
versions: +Python 3.2, Python 3.3 -Python 2.6

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

From report at bugs.python.org  Mon Feb  6 19:20:25 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 06 Feb 2012 18:20:25 +0000
Subject: [issue8255] Packaging step-by-step tutorial
In-Reply-To: <1269787637.04.0.463586986817.issue8255@psf.upfronthosting.co.za>
Message-ID: <1328552425.67.0.612691544708.issue8255@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

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

From report at bugs.python.org  Mon Feb  6 19:31:37 2012
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 06 Feb 2012 18:31:37 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <4F3008D2.5060509@egenix.com>
Message-ID: <CA+OGgf6karxY5iBAK=JUFDW73bs7tZc7X5+-9sNZygM70aGKOw@mail.gmail.com>


Jim Jewett <jimjjewett at gmail.com> added the comment:

On Mon, Feb 6, 2012 at 12:07 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
>
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>
> Jim Jewett wrote:

>> The problematic case is, roughly,

>> (1) ?Find out what N will trigger collision-counting countermeasures.
>> (2) ?Insert N-1 colliding entries, to make it as slow as possible.
>> (3) ?Keep looking up (or updating) the N-1th entry, so that the
>> slow-as-possible-without-countermeasures path keeps getting rerun.

> Since N is constant, I don't see how such an "attack" could be used
> to trigger the O(n^2) worst-case behavior.

Agreed; it tops out with a constant, but if it takes only 16 bytes of
input to force another run through a 1000-long collision, that may
still be too much leverage.

> BTW: If you set the limit N to e.g. 100 (which is reasonable given
> Victor's and my tests),

Agreed.  Frankly, I think 5 would be more than reasonable so long as
there is a fallback.

> the time it takes to process one of those
> sets only takes 0.3 ms on my machine. That's hardly usable as basis
> for an effective DoS attack.

So it would take around 3Mb to cause a minute's delay...

----------

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

From report at bugs.python.org  Mon Feb  6 19:53:41 2012
From: report at bugs.python.org (Frank Sievertsen)
Date: Mon, 06 Feb 2012 18:53:41 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1328554421.26.0.580912085318.issue13703@psf.upfronthosting.co.za>


Frank Sievertsen <python at sievertsen.de> added the comment:

> Agreed; it tops out with a constant, but if it takes only 16 bytes of
> input to force another run through a 1000-long collision, that may
> still be too much leverage.

You should prepare the dict so that you have the collisions-run with a one-byte string or better with an even empty string, not a 16 bytes string.

> BTW: If you set the limit N to e.g. 100 (which is reasonable given
> Victor's and my tests),

100 is probably hard to exploit for a DoS attack. However
it makes it much easier to cause unwanted (future?) exceptions in
other apps.

> So it would take around 3Mb to cause a minute's delay...

How did you calculate that?

----------

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

From report at bugs.python.org  Mon Feb  6 19:54:50 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 06 Feb 2012 18:54:50 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <CA+OGgf6karxY5iBAK=JUFDW73bs7tZc7X5+-9sNZygM70aGKOw@mail.gmail.com>
Message-ID: <4F3021F5.7090502@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Jim Jewett wrote:
> 
>> BTW: If you set the limit N to e.g. 100 (which is reasonable given
>> Victor's and my tests),
> 
> Agreed.  Frankly, I think 5 would be more than reasonable so long as
> there is a fallback.
> 
>> the time it takes to process one of those
>> sets only takes 0.3 ms on my machine. That's hardly usable as basis
>> for an effective DoS attack.
> 
> So it would take around 3Mb to cause a minute's delay...

I'm not sure how you calculated that number.

Here's what I get: tale a dictionary with 100 integer collisions:
d = dict((x*(2**64 - 1), 1) for x in xrange(1, 100))

The repr(d) has 2713 bytes, which is a good approximation of how
much (string) data you have to send in order to trigger the
problem case.

If you can create 3333 distinct integer sequences, you'll get a
processing time of about 1 second on my slow dev machine. The
resulting dict will likely have a repr() of around
60*3333*2713 = 517MB.

So you need to send 517MB to cause my slow dev machine to consume
1 minute of CPU time. Today's servers are at least 10 times as fast as
my aging machine.

If you then take into account that the integer collision dictionary
is a very efficient collision example (size vs. effect), the attack
doesn't really sound practical anymore.

----------

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

From report at bugs.python.org  Mon Feb  6 19:59:00 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 06 Feb 2012 18:59:00 +0000
Subject: [issue13953] test_packaging: unused test?
Message-ID: <1328554740.27.0.167211242761.issue13953@psf.upfronthosting.co.za>


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

I'm not sure what's happening here (not sure how doctest works), but I suspect that there is no test at all. Perhaps it was forgotten: http://hg.python.org/cpython/file/567767a6df02/Lib/packaging/tests/test_version.py#l68.

I say this because it whatever change I make to that long string, I always get a successful test.

----------
assignee: tarek
components: Distutils2
messages: 152756
nosy: alexis, eric.araujo, tarek, tshepang
priority: normal
severity: normal
status: open
title: test_packaging: unused test?
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb  6 20:05:02 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Feb 2012 19:05:02 +0000
Subject: [issue13952] mimetypes doesn't recognize .csv
In-Reply-To: <1328550236.31.0.476108753678.issue13952@psf.upfronthosting.co.za>
Message-ID: <1328555102.97.0.952238891506.issue13952@psf.upfronthosting.co.za>


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

I would argue the embedded mime-types dictionary should at least mirror current IANA assignments, which are already present in up-to-date Unix systems:

>>> mimetypes.guess_type("foo.csv")
('text/csv', None)

So not having text/csv is IMHO a bug.
Also it would be nice if there were an easy way to keep the mime-types dictionary up-to-date wrt. a system's mime-types file.

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

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

From report at bugs.python.org  Mon Feb  6 20:11:04 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Feb 2012 19:11:04 +0000
Subject: [issue13952] mimetypes doesn't recognize .csv
In-Reply-To: <1328550236.31.0.476108753678.issue13952@psf.upfronthosting.co.za>
Message-ID: <1328555464.94.0.960351709602.issue13952@psf.upfronthosting.co.za>


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

As far as I know having it mirror the IANA registry is the intent (there's a comment in the module that can be read as implying that).  So I'd be inclined to treat this one as a bug and fix it in 2.7 and 3.2 as well as 3.3.

I'm not sure what you mean by your final comment, since by default the system mime types are read on both Unix and Windows and merged with the built in table.

----------

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

From report at bugs.python.org  Mon Feb  6 20:11:43 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 06 Feb 2012 19:11:43 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <4F2FA96D.1080600@egenix.com>
Message-ID: <1328555463.3741.95.camel@surprise>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

On Mon, 2012-02-06 at 10:20 +0000, Marc-Andre Lemburg wrote:
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
> 
> STINNER Victor wrote:
> > 
> > STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> > 
> >> In a security fix release, we shouldn't change the linkage procedures,
> >> so I recommend that the LoadLibrary dance remains.
> > 
> > So the overhead in startup time is not an issue?
> 
> It is an issue. Not only in terms of startup time, but also

msg152362 indicated that there was negligible impact on startup time
when randomization is disabled.  The impact when it *is* enabled is
unclear, but reported there as "isn't crippling".

> because randomization per default makes Python behave in
> non-deterministc ways - which is not what you want from a
> programming language or interpreter (unless you explicitly
> tell it to behave like that).

The release managers have pronounced:
http://mail.python.org/pipermail/python-dev/2012-January/115892.html
Quoting that email:
> 1. Simple hash randomization is the way to go. We think this has the
> best chance of actually fixing the problem while being fairly
> straightforward such that we're comfortable putting it in a stable
> release.
> 2. It will be off by default in stable releases and enabled by an
> envar at runtime. This will prevent code breakage from dictionary
> order changing as well as people depending on the hash stability.

----------

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

From report at bugs.python.org  Mon Feb  6 20:13:57 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Feb 2012 19:13:57 +0000
Subject: [issue13952] mimetypes doesn't recognize .csv
In-Reply-To: <1328555464.94.0.960351709602.issue13952@psf.upfronthosting.co.za>
Message-ID: <1328555474.3478.16.camel@localhost.localdomain>


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

> I'm not sure what you mean by your final comment, since by default the
> system mime types are read on both Unix and Windows and merged with
> the built in table.

I mean to have our built-in table mirror a recent Unix system's
mime-types table. There could be a special switch to mimetypes.py, which
would output the Python code of a dict mirroring /etc/mime.types (or
"/etc/mime.types" + the current built-in table) when run. Then it would
be easy to integrate the changes back into the code.

----------

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

From report at bugs.python.org  Mon Feb  6 20:19:23 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Feb 2012 19:19:23 +0000
Subject: [issue13952] mimetypes doesn't recognize .csv
In-Reply-To: <1328550236.31.0.476108753678.issue13952@psf.upfronthosting.co.za>
Message-ID: <1328555963.65.0.529194345566.issue13952@psf.upfronthosting.co.za>


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

Ah, analagous to the way keyword.py regenerates its embedded table based on the actual python grammar?  Yes, that would be nice.

----------

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

From report at bugs.python.org  Mon Feb  6 20:34:16 2012
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 06 Feb 2012 19:34:16 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1328554421.26.0.580912085318.issue13703@psf.upfronthosting.co.za>
Message-ID: <CA+OGgf4ewU0-t=Oc-nzvzioNSk-pY8F-ACtMDwBN5_H+_cOg+Q@mail.gmail.com>


Jim Jewett <jimjjewett at gmail.com> added the comment:

On Mon, Feb 6, 2012 at 1:53 PM, Frank Sievertsen <report at bugs.python.org> wrote:

>>> BTW: If you set the limit N to e.g. 100 (which is reasonable given
>>> Victor's and my tests),

>> So it would take around 3Mb to cause a minute's delay...

> How did you calculate that?

16 bytes/entry * 3300 entries/second * 60 seconds/minute

But if there is indeed a way to cut that 16 bytes/entry, that is worse.

Switching dict implementations at 5 collisions is still acceptable,
except from a complexity standpoint.

-jJ

----------

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

From report at bugs.python.org  Mon Feb  6 20:44:53 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 06 Feb 2012 19:44:53 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1328555463.3741.95.camel@surprise>
Message-ID: <4F302DB0.3080804@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Dave Malcolm wrote:
> 
>>> So the overhead in startup time is not an issue?
>>
>> It is an issue. Not only in terms of startup time, but also
>... 
>> because randomization per default makes Python behave in
>> non-deterministc ways - which is not what you want from a
>> programming language or interpreter (unless you explicitly
>> tell it to behave like that).
> 
> The release managers have pronounced:
> http://mail.python.org/pipermail/python-dev/2012-January/115892.html
> Quoting that email:
>> 1. Simple hash randomization is the way to go. We think this has the
>> best chance of actually fixing the problem while being fairly
>> straightforward such that we're comfortable putting it in a stable
>> release.
>> 2. It will be off by default in stable releases and enabled by an
>> envar at runtime. This will prevent code breakage from dictionary
>> order changing as well as people depending on the hash stability.

Right, but that doesn't contradict what I wrote about adding
env vars to fix a seed and optionally enable using a random
seed, or adding collision counting as extra protection for
cases that are not addressed by the hash seeding, such as
e.g. collisions caused by 3rd types or numbers.

----------

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

From report at bugs.python.org  Mon Feb  6 21:07:09 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 06 Feb 2012 20:07:09 +0000
Subject: [issue10811] sqlite segfault with generators
In-Reply-To: <1294018427.94.0.141740646278.issue10811@psf.upfronthosting.co.za>
Message-ID: <E1RuUqB-00079U-Q0@dinsdale.python.org>


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

New changeset 631e99961c5f by Petri Lehtinen in branch '2.7':
Issue #10811: Fix recursive usage of cursors. Instead of crashing, raise a ProgrammingError now.
http://hg.python.org/cpython/rev/631e99961c5f

New changeset d51ceef4b62f by Petri Lehtinen in branch '3.2':
Issue #10811: Fix recursive usage of cursors. Instead of crashing, raise a ProgrammingError now.
http://hg.python.org/cpython/rev/d51ceef4b62f

----------

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

From report at bugs.python.org  Mon Feb  6 21:08:05 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 06 Feb 2012 20:08:05 +0000
Subject: [issue10811] sqlite segfault with generators
In-Reply-To: <1294018427.94.0.141740646278.issue10811@psf.upfronthosting.co.za>
Message-ID: <1328558885.45.0.31969425742.issue10811@psf.upfronthosting.co.za>


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

It's now fixed in all branches. Thanks for reporting!

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

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

From report at bugs.python.org  Mon Feb  6 21:14:41 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 06 Feb 2012 20:14:41 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <4F302DB0.3080804@egenix.com>
Message-ID: <4F3034AC.8080407@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Marc-Andre Lemburg wrote:
> Dave Malcolm wrote:
>> The release managers have pronounced:
>> http://mail.python.org/pipermail/python-dev/2012-January/115892.html
>> Quoting that email:
>>> 1. Simple hash randomization is the way to go. We think this has the
>>> best chance of actually fixing the problem while being fairly
>>> straightforward such that we're comfortable putting it in a stable
>>> release.
>>> 2. It will be off by default in stable releases and enabled by an
>>> envar at runtime. This will prevent code breakage from dictionary
>>> order changing as well as people depending on the hash stability.
> 
> Right, but that doesn't contradict what I wrote about adding
> env vars to fix a seed and optionally enable using a random
> seed, or adding collision counting as extra protection for
> cases that are not addressed by the hash seeding, such as
> e.g. collisions caused by 3rd types or numbers.

... at least I hope not :-)

----------

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

From report at bugs.python.org  Mon Feb  6 21:17:48 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Feb 2012 20:17:48 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <4F3034AC.8080407@egenix.com>
Message-ID: <1328559305.3478.18.camel@localhost.localdomain>


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

> > Right, but that doesn't contradict what I wrote about adding
> > env vars to fix a seed and optionally enable using a random
> > seed, or adding collision counting as extra protection for
> > cases that are not addressed by the hash seeding, such as
> > e.g. collisions caused by 3rd types or numbers.
> 
> ... at least I hope not :-)

I think the env var part is a good idea (except that -1 as a magic value
to enable randomization isn't great).

----------

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

From report at bugs.python.org  Mon Feb  6 21:24:15 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 06 Feb 2012 20:24:15 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1328559305.3478.18.camel@localhost.localdomain>
Message-ID: <4F3036EB.8080303@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>>> Right, but that doesn't contradict what I wrote about adding
>>> env vars to fix a seed and optionally enable using a random
>>> seed, or adding collision counting as extra protection for
>>> cases that are not addressed by the hash seeding, such as
>>> e.g. collisions caused by 3rd types or numbers.
>>
>> ... at least I hope not :-)
> 
> I think the env var part is a good idea (except that -1 as a magic value
> to enable randomization isn't great).

Agreed. Since it's an env var, using "random" would be a better choice.

----------

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

From report at bugs.python.org  Mon Feb  6 21:24:22 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 06 Feb 2012 20:24:22 +0000
Subject: [issue13588] Change name of internal closure functions in importlib
In-Reply-To: <1323703954.36.0.434643027987.issue13588@psf.upfronthosting.co.za>
Message-ID: <1328559862.26.0.285699054171.issue13588@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Feb  6 21:27:13 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Feb 2012 20:27:13 +0000
Subject: [issue8184] multiprocessing.managers will not fail if listening ocket
	already in use
In-Reply-To: <1269104932.24.0.802901286813.issue8184@psf.upfronthosting.co.za>
Message-ID: <1328560033.76.0.798751320344.issue8184@psf.upfronthosting.co.za>


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

> Anyway, in that case, my last patch should be correct (tested on
> one of the Win7 buildbots).

It looks good to me.

----------

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

From report at bugs.python.org  Mon Feb  6 21:35:15 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 06 Feb 2012 20:35:15 +0000
Subject: [issue13954] Add regrtest option to record test results to a file
Message-ID: <1328560515.13.0.686472532234.issue13954@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The idea is that if a test succeeded then it is written to a file commented out(including skipped tests w/ the appropriate comment), and if a test failed then it is left uncommented. This way the failing tests can simply be passed to --fromfile for easy repeatability. This becomes especially handy when randomizing test order and there is some dependency on a previously run test as you can begin to uncomment tests until you find the trigger.

This can also be used with some other new flag which lists which tests to skip (i.e. the inverse of --fromfile). This is helpful when you don't want to run tests in some branch when you know they are failing in the default branch already and you are not trying to fix them.

----------
components: Tests
messages: 152771
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Add regrtest option to record test results to a file
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb  6 21:45:44 2012
From: report at bugs.python.org (Samuel Bronson)
Date: Mon, 06 Feb 2012 20:45:44 +0000
Subject: [issue13955] email: RFC 2822 has been obsoleted by RFC 5322
Message-ID: <1328561144.0.0.46908466856.issue13955@psf.upfronthosting.co.za>


New submission from Samuel Bronson <naesten at gmail.com>:

As you can see by looking at <http://tools.ietf.org/html/rfc2822> or <http://tools.ietf.org/html/rfc5322>, RFC 2822 has been obsoleted by RFC 5322.

It would probably be a good idea to update the email package to support it, if in fact anything needs changing, and to mention/link to the new RFC in the documentation.

(It would probably *not* be a good idea to stop mentioning RFC 2822, though, since that's rather more well known, and the number is a bit more memorable for those who've heard of RFC 822. I'm actually a bit surprised the new one didn't get numbered 5822...)

----------
components: Library (Lib)
messages: 152772
nosy: SamB
priority: normal
severity: normal
status: open
title: email: RFC 2822 has been obsoleted by RFC 5322
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13955>
_______________________________________

From report at bugs.python.org  Mon Feb  6 21:46:38 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 06 Feb 2012 20:46:38 +0000
Subject: [issue13956] add a note regarding building on recent versions of
	Debian and Ubuntu
Message-ID: <1328561198.71.0.464040865268.issue13956@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

I was puzzled why the various parts, like readline and ssl, failed to be built into my Python. It was after seeing #11715 that I realized I needed to install dpkg-dev, whose binary, dpkg-architecture, helps detect the locations of those libraries ().

----------
components: Devguide
files: note-on-building-on-recent-debian-releases.patch
keywords: patch
messages: 152773
nosy: ezio.melotti, tshepang
priority: normal
severity: normal
status: open
title: add a note regarding building on recent versions of Debian and Ubuntu
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file24438/note-on-building-on-recent-debian-releases.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13956>
_______________________________________

From report at bugs.python.org  Mon Feb  6 21:57:43 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 06 Feb 2012 20:57:43 +0000
Subject: [issue13955] email: RFC 2822 has been obsoleted by RFC 5322
In-Reply-To: <1328561144.0.0.46908466856.issue13955@psf.upfronthosting.co.za>
Message-ID: <1328561863.17.0.308177694078.issue13955@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13955>
_______________________________________

From report at bugs.python.org  Mon Feb  6 21:58:40 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 06 Feb 2012 20:58:40 +0000
Subject: [issue13954] Add regrtest option to record test results to a file
In-Reply-To: <1328560515.13.0.686472532234.issue13954@psf.upfronthosting.co.za>
Message-ID: <1328561920.16.0.899309639507.issue13954@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13954>
_______________________________________

From report at bugs.python.org  Mon Feb  6 21:59:42 2012
From: report at bugs.python.org (Samuel Bronson)
Date: Mon, 06 Feb 2012 20:59:42 +0000
Subject: [issue13957] parsedate_tz doesn't distinguish -0000 from +0000
Message-ID: <1328561981.97.0.928015101931.issue13957@psf.upfronthosting.co.za>


New submission from Samuel Bronson <naesten at gmail.com>:

This is what I'm seeing:

>>> import email.utils
>>> email.utils.parsedate_tz('Fri, 09 Nov 2001 01:08:47 +0000')
(2001, 11, 9, 1, 8, 47, 0, 1, -1, 0)
>>> email.utils.parsedate_tz('Fri, 09 Nov 2001 01:08:47 -0000')
(2001, 11, 9, 1, 8, 47, 0, 1, -1, 0)

But RFC 5322 says:

>    minutes).  The form "+0000" SHOULD be used to indicate a time zone at
>    Universal Time.  Though "-0000" also indicates Universal Time, it is
>    used to indicate that the time was generated on a system that may be
>    in a local time zone other than Universal Time and that the date-time
>    contains no information about the local time zone.

(As does RFC 2822, which RFC 5322 obsoletes.)

And the documentation for email.utils.parsedate_tz is:

> Performs the same function as parsedate(), but returns either None or a
> 10-tuple; the first 9 elements make up a tuple that can be passed directly to
> time.mktime(), and the tenth is the offset of the date?s timezone from UTC
> (which is the official term for Greenwich Mean Time) [1]. If the input string
> has no timezone, the last element of the tuple returned is None. Note that
> indexes 6, 7, and 8 of the result tuple are not usable.

So it seems like I should have seen:

>>> email.utils.parsedate_tz('Fri, 09 Nov 2001 01:08:47 -0000')
(2001, 11, 9, 1, 8, 47, 0, 1, -1, None)

----------
components: Library (Lib)
messages: 152774
nosy: SamB
priority: normal
severity: normal
status: open
title: parsedate_tz doesn't distinguish -0000 from +0000
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13957>
_______________________________________

From report at bugs.python.org  Mon Feb  6 22:08:01 2012
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 06 Feb 2012 21:08:01 +0000
Subject: [issue13958] Comment _PyUnicode_FromId
Message-ID: <1328562481.37.0.963430075051.issue13958@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at gmail.com>:

Add a comment explaining why _PyUnicode_FromId can (and should) assume ASCII-only identifiers.


	/* PEP3131 guarantees that all python-internal identifiers
	   are ASCII-only.  Violating this would break some supported
	   C compilers. */

See http://mail.python.org/pipermail/python-dev/2012-February/116234.html

----------
components: Unicode
messages: 152775
nosy: Jim.Jewett, ezio.melotti
priority: normal
severity: normal
status: open
title: Comment _PyUnicode_FromId
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13958>
_______________________________________

From report at bugs.python.org  Mon Feb  6 22:16:06 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Feb 2012 21:16:06 +0000
Subject: [issue13955] email: RFC 2822 has been obsoleted by RFC 5322
In-Reply-To: <1328561144.0.0.46908466856.issue13955@psf.upfronthosting.co.za>
Message-ID: <1328562966.81.0.733119833118.issue13955@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

5322 is still a draft, according to the IETF.

That said, we are paying attention to 5322.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13955>
_______________________________________

From report at bugs.python.org  Mon Feb  6 22:18:22 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 06 Feb 2012 21:18:22 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <4F302DB0.3080804@egenix.com>
Message-ID: <CAGE7PN+_L63U4boHo6ghtjH4-gXaap3+JU4QbC2Lyhzt3NkhYA@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

>
> > The release managers have pronounced:
> > http://mail.python.org/pipermail/python-dev/2012-January/115892.html
> > Quoting that email:
> >> 1. Simple hash randomization is the way to go. We think this has the
> >> best chance of actually fixing the problem while being fairly
> >> straightforward such that we're comfortable putting it in a stable
> >> release.
> >> 2. It will be off by default in stable releases and enabled by an
> >> envar at runtime. This will prevent code breakage from dictionary
> >> order changing as well as people depending on the hash stability.
>
> Right, but that doesn't contradict what I wrote about adding
> env vars to fix a seed and optionally enable using a random
> seed, or adding collision counting as extra protection for
> cases that are not addressed by the hash seeding, such as
> e.g. collisions caused by 3rd types or numbers.

We won't be back-porting anything more than the hash randomization for
2.6/2.7/3.1/3.2 but we are free to do more in 3.3 if someone can
demonstrate it working well and a need for it.

For me, things like collision counting and tree based collision
buckets when the types are all the same and known comparable make
sense but are really sounding like a lot of additional complexity. I'd
*like* to see active black-box design attack code produced that goes
after something like a wsgi web app written in Python with hash
randomization *enabled* to demonstrate the need before we accept
additional protections like this ?for 3.3+.

-gps

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Mon Feb  6 22:25:07 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 06 Feb 2012 21:25:07 +0000
Subject: [issue13958] Comment _PyUnicode_FromId
In-Reply-To: <1328562481.37.0.963430075051.issue13958@psf.upfronthosting.co.za>
Message-ID: <1328563507.3.0.111429381653.issue13958@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This has nothing to do with PEP 3131. Python could (and does) support non-ASCII identifiers just fine, regardless of C compiler limitations.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13958>
_______________________________________

From report at bugs.python.org  Mon Feb  6 22:25:56 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 06 Feb 2012 21:25:56 +0000
Subject: [issue13807] logging.Handler.handlerError() may raise AttributeError
	in traceback.print_exception()
In-Reply-To: <1326816014.41.0.202399739958.issue13807@psf.upfronthosting.co.za>
Message-ID: <E1RuW4Q-0002Df-RO@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6b951f27f6a8 by Vinay Sajip in branch '3.2':
Null merge for reverted fix for #13807.
http://hg.python.org/cpython/rev/6b951f27f6a8

New changeset 140f7de4d2a5 by Vinay Sajip in branch 'default':
Null merge for reverted fix for #13807.
http://hg.python.org/cpython/rev/140f7de4d2a5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13807>
_______________________________________

From report at bugs.python.org  Mon Feb  6 22:28:20 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Feb 2012 21:28:20 +0000
Subject: [issue13958] Comment _PyUnicode_FromId
In-Reply-To: <1328562481.37.0.963430075051.issue13958@psf.upfronthosting.co.za>
Message-ID: <1328563700.07.0.3400040818.issue13958@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/issue13958>
_______________________________________

From report at bugs.python.org  Mon Feb  6 22:41:04 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 06 Feb 2012 21:41:04 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <CAGE7PN+_L63U4boHo6ghtjH4-gXaap3+JU4QbC2Lyhzt3NkhYA@mail.gmail.com>
Message-ID: <4F3048EB.2050800@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Gregory P. Smith wrote:
> 
> Gregory P. Smith <greg at krypto.org> added the comment:
> 
>>
>>> The release managers have pronounced:
>>> http://mail.python.org/pipermail/python-dev/2012-January/115892.html
>>> Quoting that email:
>>>> 1. Simple hash randomization is the way to go. We think this has the
>>>> best chance of actually fixing the problem while being fairly
>>>> straightforward such that we're comfortable putting it in a stable
>>>> release.
>>>> 2. It will be off by default in stable releases and enabled by an
>>>> envar at runtime. This will prevent code breakage from dictionary
>>>> order changing as well as people depending on the hash stability.
>>
>> Right, but that doesn't contradict what I wrote about adding
>> env vars to fix a seed and optionally enable using a random
>> seed, or adding collision counting as extra protection for
>> cases that are not addressed by the hash seeding, such as
>> e.g. collisions caused by 3rd types or numbers.
> 
> We won't be back-porting anything more than the hash randomization for
> 2.6/2.7/3.1/3.2 but we are free to do more in 3.3 if someone can
> demonstrate it working well and a need for it.
> 
> For me, things like collision counting and tree based collision
> buckets when the types are all the same and known comparable make
> sense but are really sounding like a lot of additional complexity. I'd
> *like* to see active black-box design attack code produced that goes
> after something like a wsgi web app written in Python with hash
> randomization *enabled* to demonstrate the need before we accept
> additional protections like this  for 3.3+.

I posted several examples for the integer collision attack on this
ticket. The current randomization patch does not address this at all,
the collision counting patch does, which is why I think both are
needed.

Note that my comment was more about the desire to *not* recommend
using random hash seeds per default, but instead advocate using
a random but fixed seed, or at least document that using random
seeds that are set during interpreter startup will cause
problems with repeatability of application runs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Mon Feb  6 22:42:28 2012
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 06 Feb 2012 21:42:28 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <4F3048EB.2050800@egenix.com>
Message-ID: <CAFRnB2VOMXRW1RNvrEtVm2arFxWvLOeCkacRf7c6UNeHEPhMHQ@mail.gmail.com>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

On Mon, Feb 6, 2012 at 4:41 PM, Marc-Andre Lemburg
<report at bugs.python.org>wrote:

>
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>
> Gregory P. Smith wrote:
> >
> > Gregory P. Smith <greg at krypto.org> added the comment:
> >
> >>
> >>> The release managers have pronounced:
> >>> http://mail.python.org/pipermail/python-dev/2012-January/115892.html
> >>> Quoting that email:
> >>>> 1. Simple hash randomization is the way to go. We think this has the
> >>>> best chance of actually fixing the problem while being fairly
> >>>> straightforward such that we're comfortable putting it in a stable
> >>>> release.
> >>>> 2. It will be off by default in stable releases and enabled by an
> >>>> envar at runtime. This will prevent code breakage from dictionary
> >>>> order changing as well as people depending on the hash stability.
> >>
> >> Right, but that doesn't contradict what I wrote about adding
> >> env vars to fix a seed and optionally enable using a random
> >> seed, or adding collision counting as extra protection for
> >> cases that are not addressed by the hash seeding, such as
> >> e.g. collisions caused by 3rd types or numbers.
> >
> > We won't be back-porting anything more than the hash randomization for
> > 2.6/2.7/3.1/3.2 but we are free to do more in 3.3 if someone can
> > demonstrate it working well and a need for it.
> >
> > For me, things like collision counting and tree based collision
> > buckets when the types are all the same and known comparable make
> > sense but are really sounding like a lot of additional complexity. I'd
> > *like* to see active black-box design attack code produced that goes
> > after something like a wsgi web app written in Python with hash
> > randomization *enabled* to demonstrate the need before we accept
> > additional protections like this  for 3.3+.
>
> I posted several examples for the integer collision attack on this
> ticket. The current randomization patch does not address this at all,
> the collision counting patch does, which is why I think both are
> needed.
>
> Note that my comment was more about the desire to *not* recommend
> using random hash seeds per default, but instead advocate using
> a random but fixed seed, or at least document that using random
> seeds that are set during interpreter startup will cause
> problems with repeatability of application runs.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13703>
> _______________________________________
>

Can't randomization just be applied to integers as well?

Alex

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Mon Feb  6 22:42:30 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Feb 2012 21:42:30 +0000
Subject: [issue13957] parsedate_tz doesn't distinguish -0000 from +0000
In-Reply-To: <1328561981.97.0.928015101931.issue13957@psf.upfronthosting.co.za>
Message-ID: <1328564550.93.0.938856109427.issue13957@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is fixed already in 3.3.  It is a behavior change that could theoretically cause some problems.  Currently, you can think of None as meaning "there was no timezone info at all", which is subtly different from -0000, which means "this time is UTC, but I don't know what timezone it originated from".  These two tend to be conflated in practice (how else are you going to interpret a time with no timezone attached?), and since we are making other additions to email in 3.3 we decided it was a small enough change that it was OK for a dot release.  But not for a maintenance release, just in case.  (I'm open to argument on that, but these backward compatibility calls are notoriously hard to make.)

----------
assignee:  -> r.david.murray
nosy: +r.david.murray
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13957>
_______________________________________

From report at bugs.python.org  Mon Feb  6 22:51:43 2012
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 06 Feb 2012 21:51:43 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1328565103.46.0.200849151197.issue4709@psf.upfronthosting.co.za>


Ralf Schmitt <python-bugs at systemexit.de> added the comment:

There's no need to discuss or even run configure scripts. Martin, please reread the OPs original message. It's easy enough to reason about the issue instead of trying to reproduce it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4709>
_______________________________________

From report at bugs.python.org  Mon Feb  6 22:53:18 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 06 Feb 2012 21:53:18 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <CAFRnB2VOMXRW1RNvrEtVm2arFxWvLOeCkacRf7c6UNeHEPhMHQ@mail.gmail.com>
Message-ID: <1328565156.3741.118.camel@surprise>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

> Can't randomization just be applied to integers as well?
> 

It could, but see http://bugs.python.org/issue13703#msg151847

Would my patches be more or less likely to get reviewed with vs without
an extension of randomization to integers?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Mon Feb  6 22:53:33 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 06 Feb 2012 21:53:33 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1328565213.9.0.617922767116.issue2377@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Thanks to Benjamin, the test_capi assert failure is fixed. At this point the only failures are listed in the FAILING file and are (probably) minor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Mon Feb  6 22:59:43 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 06 Feb 2012 21:59:43 +0000
Subject: [issue13878] test_sched failures on Windows buildbot
In-Reply-To: <1327597038.78.0.0899603043053.issue13878@psf.upfronthosting.co.za>
Message-ID: <1328565583.92.0.551889485809.issue13878@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's another failure due to the same type of race:

"""
======================================================================
FAIL: test_queue (test.test_sched.TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_sched.py", line 74, in test_queue
    self.assertEqual(list(scheduler.queue), [e1, e2, e3, e4, e5])
AssertionError: Lists differ: [Event(time=1328544857.025, pr... != [Event(time=1328544857.025, pr...

First differing element 2:
Event(time=1328544857.055, priority=1, action=<function TestCase.test_queue.<locals>.<lambda> at 0x04C072D8>, argument=[], kwargs={})
Event(time=1328544857.0609999, priority=1, action=<function TestCase.test_queue.<locals>.<lambda> at 0x04C072D8>, argument=[], kwargs={})

Diff is 836 characters long. Set self.maxDiff to None to see it.
"""

Here's a patch that:
- increases the timeouts for test_enter
- converts other tests to use enterabs() instead of enter()

It should fix all those failures.

----------
components: +Tests
keywords: +needs review, patch
versions: +Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24439/test_sched_race.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13878>
_______________________________________

From report at bugs.python.org  Mon Feb  6 23:04:29 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 06 Feb 2012 22:04:29 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <CAFRnB2VOMXRW1RNvrEtVm2arFxWvLOeCkacRf7c6UNeHEPhMHQ@mail.gmail.com>
Message-ID: <4F304E68.5020807@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alex Gaynor wrote:
> Can't randomization just be applied to integers as well?

A simple seed xor'ed with the hash won't work, since the attacks
I posted will continue to work (just colliding on a different hash
value).

Using a more elaborate hash algorithm would slow down uses of
numbers as dictionary keys and also be difficult to implement for
non-integer types such as float, longs and complex numbers. The
reason is that Python applications expect x == y => hash(x) == hash(y),
e.g. hash(3) == hash(3L) == hash(3.0) == hash(3+0j).

AFAIK, the randomization patch also doesn't cover tuples, which are
rather common as dictionary keys as well, nor any of the other
more esoteric Python built-in hashable data types (e.g. frozenset)
or hashable data types defined by 3rd party extensions or
applications (simply because it can't).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Mon Feb  6 23:06:41 2012
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Feb 2012 22:06:41 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1328566001.4.0.276174545077.issue2377@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Is there a benchmark for import? How slow is importlib? :)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Mon Feb  6 23:07:39 2012
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 06 Feb 2012 22:07:39 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <4F304E68.5020807@egenix.com>
Message-ID: <CAFRnB2W-DwsOGFc9uA1A8QE9daoc8RBhMviCCNWsGmcHHu6k5A@mail.gmail.com>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

On Mon, Feb 6, 2012 at 5:04 PM, Marc-Andre Lemburg
<report at bugs.python.org>wrote:

>
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>
> Alex Gaynor wrote:
> > Can't randomization just be applied to integers as well?
>
> A simple seed xor'ed with the hash won't work, since the attacks
> I posted will continue to work (just colliding on a different hash
> value).
>
> Using a more elaborate hash algorithm would slow down uses of
> numbers as dictionary keys and also be difficult to implement for
> non-integer types such as float, longs and complex numbers. The
> reason is that Python applications expect x == y => hash(x) == hash(y),
> e.g. hash(3) == hash(3L) == hash(3.0) == hash(3+0j).
>
> AFAIK, the randomization patch also doesn't cover tuples, which are
> rather common as dictionary keys as well, nor any of the other
> more esoteric Python built-in hashable data types (e.g. frozenset)
> or hashable data types defined by 3rd party extensions or
> applications (simply because it can't).
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13703>
> _______________________________________
>

There's no need to cover any container types, because if their constituent
types are securely hashable then they will be as well.  And of course if
the constituent types are unsecure then they're directly vulnerable.

Alex

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Mon Feb  6 23:08:15 2012
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 06 Feb 2012 22:08:15 +0000
Subject: [issue13928] bug in asyncore.dispatcher_with_send
In-Reply-To: <1328241599.62.0.482443622644.issue13928@psf.upfronthosting.co.za>
Message-ID: <1328566095.35.0.583566915498.issue13928@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

No problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13928>
_______________________________________

From report at bugs.python.org  Mon Feb  6 23:08:42 2012
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 06 Feb 2012 22:08:42 +0000
Subject: [issue13958] Comment _PyUnicode_FromId
In-Reply-To: <1328563507.3.0.111429381653.issue13958@psf.upfronthosting.co.za>
Message-ID: <CA+OGgf6-K=++iaV81V3LHtuZVSCrgktm0V3cREY6PjH3VgUXrQ@mail.gmail.com>


Jim Jewett <jimjjewett at gmail.com> added the comment:

On Mon, Feb 6, 2012 at 4:25 PM, Martin v. L?wis <report at bugs.python.org> wrote:

> Martin v. L?wis <martin at v.loewis.de> added the comment:

> This has nothing to do with PEP 3131. Python could (and does)
> support non-ASCII identifiers just fine, regardless of C compiler
> limitations.

I *think* you're saying that the _Py_Identifier( ) is a smaller set
than identifiers in general.  Would the following be more accurate?

        /* PEP3131 does allow non-ASCII identifiers in user code, but
		   limits their use within the implementation itself.
		   In particular, a _Py_Identifier may be passed directly to
		   C code; such identifiers are restricted to ASCII to avoid
		   breaking some supported C compilers. */

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13958>
_______________________________________

From report at bugs.python.org  Mon Feb  6 23:10:36 2012
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 06 Feb 2012 22:10:36 +0000
Subject: [issue13958] Comment _PyUnicode_FromId
In-Reply-To: <CA+OGgf6-K=++iaV81V3LHtuZVSCrgktm0V3cREY6PjH3VgUXrQ@mail.gmail.com>
Message-ID: <CA+OGgf45rPKWyAR=cm9vFi+W6HNWtKxbSd+BV+P+i0MGmWsVZQ@mail.gmail.com>


Jim Jewett <jimjjewett at gmail.com> added the comment:

And is there a way to characterize the compilers that would break?  Is
it a few specific compilers, or "compilers that do not implement UTF8,
which is not required by the C standard", or ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13958>
_______________________________________

From report at bugs.python.org  Mon Feb  6 23:13:12 2012
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Feb 2012 22:13:12 +0000
Subject: [issue13958] Comment _PyUnicode_FromId
In-Reply-To: <1328562481.37.0.963430075051.issue13958@psf.upfronthosting.co.za>
Message-ID: <1328566392.08.0.72780098476.issue13958@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Using _Py_static_string(), you can write literal UTF-8 strings using hexadecimal escape sequences. It works on any C compiler. E.g. _Py_static_string(ecute, "\xc3\xa9").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13958>
_______________________________________

From report at bugs.python.org  Mon Feb  6 20:07:46 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 06 Feb 2012 19:07:46 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1328508674.15.0.948121616701.issue13703@psf.upfronthosting.co.za>
Message-ID: <1328555211.3741.90.camel@surprise>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

On Mon, 2012-02-06 at 06:11 +0000, Martin v. L?wis wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> IIUC, Win9x and NT4 are not supported anymore in any of the target releases of the patch, so calling CryptGenRandom should be fine.
> In a security fix release, we shouldn't change the linkage procedures, so I recommend that the LoadLibrary dance remains.

Thanks.

Am attaching tweaked versions of the 2012-02-01 patches, in which I've
removed the indecisive:
#if 1
       (void)win32_urandom((unsigned char *)secret, secret_size, 0);
#else
       /* fast but weak RNG (fast initialization, weak seed) */
       ...etc...
#endif

stuff, and simply use the first clause (win32_urandom) on Windows:
  add-randomization-to-2.6-dmalcolm-2012-02-06-001.patch 
  fix-broken-tests-on-2.6-dmalcolm-2012-02-06-001.patch 
  add-randomization-to-3.1-dmalcolm-2012-02-06-001.patch 
  fix-broken-tests-on-3.1-dmalcolm-2012-02-06-001.patch

----------
Added file: http://bugs.python.org/file24434/add-randomization-to-2.6-dmalcolm-2012-02-06-001.patch
Added file: http://bugs.python.org/file24435/fix-broken-tests-on-2.6-dmalcolm-2012-02-06-001.patch
Added file: http://bugs.python.org/file24436/add-randomization-to-3.1-dmalcolm-2012-02-06-001.patch
Added file: http://bugs.python.org/file24437/fix-broken-tests-on-3.1-dmalcolm-2012-02-06-001.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________
-------------- next part --------------
diff -r 9a4131ada792 Doc/library/sys.rst
--- a/Doc/library/sys.rst	Fri Jan 27 09:42:45 2012 +0100
+++ b/Doc/library/sys.rst	Mon Feb 06 14:01:17 2012 -0500
@@ -289,6 +289,8 @@
    +------------------------------+------------------------------------------+
    | :const:`bytes_warning`       | -b                                       |
    +------------------------------+------------------------------------------+
+   | :const:`hash_randomization`  | -R                                       |
+   +------------------------------+------------------------------------------+
 
    .. versionadded:: 2.6
 
diff -r 9a4131ada792 Doc/reference/datamodel.rst
--- a/Doc/reference/datamodel.rst	Fri Jan 27 09:42:45 2012 +0100
+++ b/Doc/reference/datamodel.rst	Mon Feb 06 14:01:17 2012 -0500
@@ -1273,6 +1273,8 @@
       modules are still available at the time when the :meth:`__del__` method is
       called.
 
+   See also the :option:`-R` command-line option.
+
 
 .. method:: object.__repr__(self)
 
diff -r 9a4131ada792 Doc/using/cmdline.rst
--- a/Doc/using/cmdline.rst	Fri Jan 27 09:42:45 2012 +0100
+++ b/Doc/using/cmdline.rst	Mon Feb 06 14:01:17 2012 -0500
@@ -21,7 +21,7 @@
 
 When invoking Python, you may specify any of these options::
 
-    python [-BdEiOQsStuUvVWxX3?] [-c command | -m module-name | script | - ] [args]
+    python [-BdEiOQsRStuUvVWxX3?] [-c command | -m module-name | script | - ] [args]
 
 The most common use case is, of course, a simple invocation of a script::
 
@@ -239,6 +239,30 @@
       :pep:`238` -- Changing the division operator
 
 
+.. cmdoption:: -R
+
+   Turn on "hash randomization, so that the :meth:`__hash__` values of str,
+   bytes and datetime objects are "salted" with an unpredictable random value.
+   Although they remain constant within an individual Python process, they
+   are not predictable between repeated invocations of Python.
+
+   This is intended to provide protection against a denial-of-service
+   caused by carefully-chosen inputs that exploit the worst case performance
+   of a dict lookup, O(n^2) complexity.  See:
+
+       http://www.ocert.org/advisories/ocert-2011-003.html
+
+   for details.
+
+   Changing hash values affects the order in which keys are retrieved from
+   a dict.  Although Python has never made guarantees about this ordering
+   (and it typically varies between 32-bit and 64-bit builds), enough
+   real-world code implicitly relies on this non-guaranteed behavior that
+   the randomization is disabled by default.
+
+   See also :envvar:`PYTHONHASHRANDOMIZATION`.
+
+
 .. cmdoption:: -s
 
    Don't add user site directory to sys.path
@@ -501,6 +525,24 @@
 
    .. versionadded:: 2.6
 
+.. envvar:: PYTHONHASHRANDOMIZATION
+
+   If this is set to a non-empty string it is equivalent to specifying the
+   :option:`-R` option.
+
+
+.. envvar:: PYTHONHASHSEED
+
+   If this is set, it is used as a fixed seed for generating the hash() of
+   the types covered by the :option:`-R` option (or its equivalent,
+   :envvar:`PYTHONHASHRANDOMIZATION`.
+
+   Its purpose is for use in selftests for the interpreter.
+
+   It should be a decimal number in the range [0; 4294967295].  Specifying
+   the value 0 overrides the other setting, disabling the hash random salt.
+
+
 .. envvar:: PYTHONIOENCODING
 
    Overrides the encoding used for stdin/stdout/stderr, in the syntax
diff -r 9a4131ada792 Include/object.h
--- a/Include/object.h	Fri Jan 27 09:42:45 2012 +0100
+++ b/Include/object.h	Mon Feb 06 14:01:17 2012 -0500
@@ -506,6 +506,12 @@
 PyAPI_FUNC(long) _Py_HashDouble(double);
 PyAPI_FUNC(long) _Py_HashPointer(void*);
 
+typedef struct {
+    long prefix;
+    long suffix;
+} _Py_HashSecret_t;
+PyAPI_DATA(_Py_HashSecret_t) _Py_HashSecret;
+
 /* Helper for passing objects to printf and the like */
 #define PyObject_REPR(obj) PyString_AS_STRING(PyObject_Repr(obj))
 
diff -r 9a4131ada792 Include/pydebug.h
--- a/Include/pydebug.h	Fri Jan 27 09:42:45 2012 +0100
+++ b/Include/pydebug.h	Mon Feb 06 14:01:17 2012 -0500
@@ -26,6 +26,7 @@
 PyAPI_DATA(int) _Py_QnewFlag;
 /* Warn about 3.x issues */
 PyAPI_DATA(int) Py_Py3kWarningFlag;
+PyAPI_DATA(int) Py_HashRandomizationFlag;
 
 /* this is a wrapper around getenv() that pays attention to
    Py_IgnoreEnvironmentFlag.  It should be used for getting variables like
diff -r 9a4131ada792 Include/pythonrun.h
--- a/Include/pythonrun.h	Fri Jan 27 09:42:45 2012 +0100
+++ b/Include/pythonrun.h	Mon Feb 06 14:01:17 2012 -0500
@@ -168,6 +168,8 @@
 PyAPI_FUNC(PyOS_sighandler_t) PyOS_getsig(int);
 PyAPI_FUNC(PyOS_sighandler_t) PyOS_setsig(int, PyOS_sighandler_t);
 
+/* Random */
+PyAPI_FUNC(int) _PyOS_URandom (void *buffer, Py_ssize_t size);
 
 #ifdef __cplusplus
 }
diff -r 9a4131ada792 Lib/os.py
--- a/Lib/os.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/os.py	Mon Feb 06 14:01:17 2012 -0500
@@ -742,22 +742,3 @@
                      _make_statvfs_result)
 except NameError: # statvfs_result may not exist
     pass
-
-if not _exists("urandom"):
-    def urandom(n):
-        """urandom(n) -> str
-
-        Return a string of n random bytes suitable for cryptographic use.
-
-        """
-        try:
-            _urandomfd = open("/dev/urandom", O_RDONLY)
-        except (OSError, IOError):
-            raise NotImplementedError("/dev/urandom (or equivalent) not found")
-        try:
-            bs = b""
-            while n - len(bs) >= 1:
-                bs += read(_urandomfd, n - len(bs))
-        finally:
-            close(_urandomfd)
-        return bs
diff -r 9a4131ada792 Lib/test/test_cmd_line.py
--- a/Lib/test/test_cmd_line.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_cmd_line.py	Mon Feb 06 14:01:17 2012 -0500
@@ -103,6 +103,20 @@
             self.exit_code('-c', 'pass'),
             0)
 
+    def test_hash_randomization(self):
+        # Verify that -R enables hash randomization:
+        self.verify_valid_flag('-R')
+        hashes = []
+        for i in range(2):
+            code = 'print(hash("spam"))'
+            data = self.start_python('-R', '-c', code)
+            hashes.append(data)
+        self.assertNotEqual(hashes[0], hashes[1])
+
+        # Verify that sys.flags contains hash_randomization
+        code = 'import sys; print(sys.flags)'
+        data = self.start_python('-R', '-c', code)
+        self.assertTrue('hash_randomization=1' in data)
 
 def test_main():
     test.test_support.run_unittest(CmdLineTest)
diff -r 9a4131ada792 Lib/test/test_hash.py
--- a/Lib/test/test_hash.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_hash.py	Mon Feb 06 14:01:17 2012 -0500
@@ -3,10 +3,14 @@
 #
 # Also test that hash implementations are inherited as expected
 
+import struct
+import subprocess
+import sys
 import unittest
 from test import test_support
 from collections import Hashable
 
+IS_64BIT = (struct.calcsize('l') == 8)
 
 class HashEqualityTestCase(unittest.TestCase):
 
@@ -133,10 +137,84 @@
         for obj in self.hashes_to_check:
             self.assertEqual(hash(obj), _default_hash(obj))
 
+class HashRandomizationTests(unittest.TestCase):
+
+    # Each subclass should define a field "repr_", containing the repr() of
+    # an object to be tested
+
+    def get_hash_command(self, repr_):
+        return 'print(hash(%s))' % repr_
+
+    def get_hash(self, repr_, randomization=None, seed=None):
+        env = {}
+        if randomization is not None:
+            env['PYTHONHASHRANDOMIZATION'] = str(randomization)
+        if seed is not None:
+            env['PYTHONHASHSEED'] = str(seed)
+        cmd_line = [sys.executable,
+                    '-c', self.get_hash_command(repr_)]
+        p = subprocess.Popen(cmd_line, stdin=subprocess.PIPE,
+                             stdout=subprocess.PIPE, stderr=subprocess.STDOUT,
+                             env=env)
+        out, err = p.communicate()
+        return int(out.strip())
+
+    def test_randomized_hash(self):
+        # two runs should return different hashes
+        run1 = self.get_hash(self.repr_, randomization=1)
+        run2 = self.get_hash(self.repr_, randomization=1)
+        self.assertNotEqual(run1, run2)
+
+class StringlikeHashRandomizationTests(HashRandomizationTests):
+    def test_null_hash(self):
+        # PYTHONHASHSEED=0 disables the randomized hash
+        if IS_64BIT:
+            known_hash_of_obj = 1453079729188098211
+        else:
+            known_hash_of_obj = -1600925533
+
+        # Randomization is disabled by default:
+        self.assertEqual(self.get_hash(self.repr_), known_hash_of_obj)
+
+        # If enabled, it can still be disabled by setting the seed to 0:
+        self.assertEqual(self.get_hash(self.repr_, randomization=1, seed=0),
+                         known_hash_of_obj)
+
+    def test_fixed_hash(self):
+        # test a fixed seed for the randomized hash
+        # Note that all types share the same values:
+        if IS_64BIT:
+            h = -4410911502303878509
+        else:
+            h = -206076799
+        self.assertEqual(self.get_hash(self.repr_, randomization=1, seed=42),
+                         h)
+
+class StrHashRandomizationTests(StringlikeHashRandomizationTests):
+    repr_ = repr('abc')
+
+    def test_empty_string(self):
+        self.assertEqual(hash(""), 0)
+
+class UnicodeHashRandomizationTests(StringlikeHashRandomizationTests):
+    repr_ = repr(u'abc')
+
+    def test_empty_string(self):
+        self.assertEqual(hash(u""), 0)
+
+class BufferHashRandomizationTests(StringlikeHashRandomizationTests):
+    repr_ = 'buffer("abc")'
+
+    def test_empty_string(self):
+        self.assertEqual(hash(buffer("")), 0)
+
 def test_main():
     test_support.run_unittest(HashEqualityTestCase,
                               HashInheritanceTestCase,
-                              HashBuiltinsTestCase)
+                              HashBuiltinsTestCase,
+                              StrHashRandomizationTests,
+                              UnicodeHashRandomizationTests,
+                              BufferHashRandomizationTests)
 
 
 if __name__ == "__main__":
diff -r 9a4131ada792 Lib/test/test_os.py
--- a/Lib/test/test_os.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_os.py	Mon Feb 06 14:01:17 2012 -0500
@@ -5,6 +5,7 @@
 import os
 import unittest
 import warnings
+import subprocess
 import sys
 from test import test_support
 
@@ -499,18 +500,45 @@
 
 class URandomTests (unittest.TestCase):
     def test_urandom(self):
-        try:
-            with test_support.check_warnings():
-                self.assertEqual(len(os.urandom(1)), 1)
-                self.assertEqual(len(os.urandom(10)), 10)
-                self.assertEqual(len(os.urandom(100)), 100)
-                self.assertEqual(len(os.urandom(1000)), 1000)
-                # see http://bugs.python.org/issue3708
-                self.assertEqual(len(os.urandom(0.9)), 0)
-                self.assertEqual(len(os.urandom(1.1)), 1)
-                self.assertEqual(len(os.urandom(2.0)), 2)
-        except NotImplementedError:
-            pass
+        with test_support.check_warnings():
+            self.assertEqual(len(os.urandom(1)), 1)
+            self.assertEqual(len(os.urandom(10)), 10)
+            self.assertEqual(len(os.urandom(100)), 100)
+            self.assertEqual(len(os.urandom(1000)), 1000)
+            # see http://bugs.python.org/issue3708
+            self.assertEqual(len(os.urandom(0.9)), 0)
+            self.assertEqual(len(os.urandom(1.1)), 1)
+            self.assertEqual(len(os.urandom(2.0)), 2)
+
+    def test_urandom_length(self):
+        self.assertEqual(len(os.urandom(0)), 0)
+        self.assertEqual(len(os.urandom(1)), 1)
+        self.assertEqual(len(os.urandom(10)), 10)
+        self.assertEqual(len(os.urandom(100)), 100)
+        self.assertEqual(len(os.urandom(1000)), 1000)
+
+    def test_urandom_value(self):
+        data1 = os.urandom(16)
+        data2 = os.urandom(16)
+        self.assertNotEqual(data1, data2)
+
+    def get_urandom_subprocess(self, count):
+        code = '\n'.join((
+            'import os, sys',
+            'data = os.urandom(%s)' % count,
+            'sys.stdout.write(data)'))
+        cmd_line = [sys.executable,
+                    '-c', code]
+        p = subprocess.Popen(cmd_line, stdin=subprocess.PIPE,
+                             stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
+        out, err = p.communicate()
+        self.assertEqual(len(out), count)
+        return out
+
+    def test_urandom_subprocess(self):
+        data1 = self.get_urandom_subprocess(16)
+        data2 = self.get_urandom_subprocess(16)
+        self.assertNotEqual(data1, data2)
 
 class Win32ErrorTests(unittest.TestCase):
     def test_rename(self):
diff -r 9a4131ada792 Lib/test/test_set.py
--- a/Lib/test/test_set.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_set.py	Mon Feb 06 14:01:17 2012 -0500
@@ -688,6 +688,17 @@
         if self.repr is not None:
             self.assertEqual(repr(self.set), self.repr)
 
+    def check_repr_against_values(self):
+        text = repr(self.set)
+        self.assertTrue(text.startswith('{'))
+        self.assertTrue(text.endswith('}'))
+
+        result = text[1:-1].split(', ')
+        result.sort()
+        sorted_repr_values = [repr(value) for value in self.values]
+        sorted_repr_values.sort()
+        self.assertEqual(result, sorted_repr_values)
+
     def test_print(self):
         fo = open(test_support.TESTFN, "wb")
         try:
diff -r 9a4131ada792 Lib/test/test_sys.py
--- a/Lib/test/test_sys.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_sys.py	Mon Feb 06 14:01:17 2012 -0500
@@ -384,7 +384,7 @@
         attrs = ("debug", "py3k_warning", "division_warning", "division_new",
                  "inspect", "interactive", "optimize", "dont_write_bytecode",
                  "no_site", "ignore_environment", "tabcheck", "verbose",
-                 "unicode", "bytes_warning")
+                 "unicode", "bytes_warning", "hash_randomization")
         for attr in attrs:
             self.assert_(hasattr(sys.flags, attr), attr)
             self.assertEqual(type(getattr(sys.flags, attr)), int, attr)
diff -r 9a4131ada792 Makefile.pre.in
--- a/Makefile.pre.in	Fri Jan 27 09:42:45 2012 +0100
+++ b/Makefile.pre.in	Mon Feb 06 14:01:17 2012 -0500
@@ -280,6 +280,7 @@
 		Python/pymath.o \
 		Python/pystate.o \
 		Python/pythonrun.o \
+		Python/random.o \
 		Python/structmember.o \
 		Python/symtable.o \
 		Python/sysmodule.o \
diff -r 9a4131ada792 Misc/NEWS
--- a/Misc/NEWS	Fri Jan 27 09:42:45 2012 +0100
+++ b/Misc/NEWS	Mon Feb 06 14:01:17 2012 -0500
@@ -10,6 +10,12 @@
 Core and Builtins
 -----------------
 
+- Issue #13703: oCERT-2011-003: add -R command-line option and
+  PYTHONHASHRANDOMIZATION (and PYTHONHASHSEED) environment variables, to
+  provide an opt-in way to protect against denial of service attacks due to
+  hash collisions within the dict and set types.  Patch by David Malcolm,
+  based on work by Victor Stinner.
+
 Library
 -------
 
diff -r 9a4131ada792 Misc/python.man
--- a/Misc/python.man	Fri Jan 27 09:42:45 2012 +0100
+++ b/Misc/python.man	Mon Feb 06 14:01:17 2012 -0500
@@ -34,6 +34,9 @@
 .B \-O0
 ]
 [
+.B \-R
+]
+[
 .B -Q
 .I argument
 ]
@@ -151,6 +154,18 @@
 .B \-O0
 Discard docstrings in addition to the \fB-O\fP optimizations.
 .TP
+.B \-R
+Turn on "hash randomization", so that the hash() values of str, bytes and
+datetime objects are "salted" with an unpredictable pseudo-random value.
+Although they remain constant within an individual Python process, they are
+not predictable between repeated invocations of Python.
+.IP
+This is intended to provide protection against a denial of service
+caused by carefully-chosen inputs that exploit the worst case performance
+of a dict lookup, O(n^2) complexity.  See
+http://www.ocert.org/advisories/ocert-2011-003.html
+for details.
+.TP
 .BI "\-Q " argument
 Division control; see PEP 238.  The argument must be one of "old" (the
 default, int/int and long/long return an int or long), "new" (new
@@ -411,6 +426,9 @@
 If this is set to a non-empty string it is equivalent to specifying
 the \fB\-v\fP option. If set to an integer, it is equivalent to
 specifying \fB\-v\fP multiple times. 
+.IP PYTHONHASHRANDOMIZATION
+If this is set to a non-empty string it is equivalent to specifying the
+\fB\-R\fP option.
 .SH AUTHOR
 The Python Software Foundation: http://www.python.org/psf
 .SH INTERNET RESOURCES
diff -r 9a4131ada792 Modules/main.c
--- a/Modules/main.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Modules/main.c	Mon Feb 06 14:01:17 2012 -0500
@@ -40,7 +40,7 @@
 static int  orig_argc;
 
 /* command line options */
-#define BASE_OPTS "3bBc:dEhiJm:OQ:sStuUvVW:xX?"
+#define BASE_OPTS "3bBc:dEhiJm:OQ:RsStuUvVW:xX?"
 
 #ifndef RISCOS
 #define PROGRAM_OPTS BASE_OPTS
@@ -72,6 +72,9 @@
 -O     : optimize generated bytecode slightly; also PYTHONOPTIMIZE=x\n\
 -OO    : remove doc-strings in addition to the -O optimizations\n\
 -Q arg : division options: -Qold (default), -Qwarn, -Qwarnall, -Qnew\n\
+-R     : use a pseudo-random salt to make hash() values of various types be\n\
+         unpredictable between separate invocations of the interpreter, as\n\
+         a defence against denial-of-service attacks\n\
 -s     : don't add user site directory to sys.path; also PYTHONNOUSERSITE\n\
 -S     : don't imply 'import site' on initialization\n\
 -t     : issue warnings about inconsistent tab usage (-tt: issue errors)\n\
@@ -101,6 +104,11 @@
 PYTHONCASEOK : ignore case in 'import' statements (Windows).\n\
 PYTHONIOENCODING: Encoding[:errors] used for stdin/stdout/stderr.\n\
 ";
+static char *usage_6 = "\
+PYTHONHASHRANDOMIZATION : make hash() values of various types be unpredictable\n\
+                          between separate invocations of the interpreter, as\n\
+                          a defence against denial-of-service attacks\n\
+";
 
 
 static int
@@ -117,6 +125,7 @@
         fputs(usage_3, f);
         fprintf(f, usage_4, DELIM);
         fprintf(f, usage_5, DELIM, PYTHONHOMEHELP);
+        fputs(usage_6, f);
     }
 #if defined(__VMS)
     if (exitcode == 0) {
@@ -388,6 +397,10 @@
             PySys_AddWarnOption(_PyOS_optarg);
             break;
 
+        case 'R':
+            Py_HashRandomizationFlag++;
+            break;
+
         /* This space reserved for other options */
 
         default:
diff -r 9a4131ada792 Modules/posixmodule.c
--- a/Modules/posixmodule.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Modules/posixmodule.c	Mon Feb 06 14:01:17 2012 -0500
@@ -8371,117 +8371,35 @@
 }
 #endif
 
-#ifdef MS_WINDOWS
-
-PyDoc_STRVAR(win32_urandom__doc__,
+PyDoc_STRVAR(posix_urandom__doc__,
 "urandom(n) -> str\n\n\
-Return a string of n random bytes suitable for cryptographic use.");
-
-typedef BOOL (WINAPI *CRYPTACQUIRECONTEXTA)(HCRYPTPROV *phProv,\
-              LPCSTR pszContainer, LPCSTR pszProvider, DWORD dwProvType,\
-              DWORD dwFlags );
-typedef BOOL (WINAPI *CRYPTGENRANDOM)(HCRYPTPROV hProv, DWORD dwLen,\
-              BYTE *pbBuffer );
-
-static CRYPTGENRANDOM pCryptGenRandom = NULL;
-/* This handle is never explicitly released. Instead, the operating
-   system will release it when the process terminates. */
-static HCRYPTPROV hCryptProv = 0;
-
-static PyObject*
-win32_urandom(PyObject *self, PyObject *args)
-{
-    int howMany;
-    PyObject* result;
-
-    /* Read arguments */
-    if (! PyArg_ParseTuple(args, "i:urandom", &howMany))
-        return NULL;
-    if (howMany < 0)
-        return PyErr_Format(PyExc_ValueError,
-                            "negative argument not allowed");
-
-    if (hCryptProv == 0) {
-        HINSTANCE hAdvAPI32 = NULL;
-        CRYPTACQUIRECONTEXTA pCryptAcquireContext = NULL;
-
-        /* Obtain handle to the DLL containing CryptoAPI
-           This should not fail         */
-        hAdvAPI32 = GetModuleHandle("advapi32.dll");
-        if(hAdvAPI32 == NULL)
-            return win32_error("GetModuleHandle", NULL);
-
-        /* Obtain pointers to the CryptoAPI functions
-           This will fail on some early versions of Win95 */
-        pCryptAcquireContext = (CRYPTACQUIRECONTEXTA)GetProcAddress(
-                                        hAdvAPI32,
-                                        "CryptAcquireContextA");
-        if (pCryptAcquireContext == NULL)
-            return PyErr_Format(PyExc_NotImplementedError,
-                                "CryptAcquireContextA not found");
-
-        pCryptGenRandom = (CRYPTGENRANDOM)GetProcAddress(
-                                        hAdvAPI32, "CryptGenRandom");
-        if (pCryptGenRandom == NULL)
-            return PyErr_Format(PyExc_NotImplementedError,
-                                "CryptGenRandom not found");
-
-        /* Acquire context */
-        if (! pCryptAcquireContext(&hCryptProv, NULL, NULL,
-                                   PROV_RSA_FULL, CRYPT_VERIFYCONTEXT))
-            return win32_error("CryptAcquireContext", NULL);
-    }
-
-    /* Allocate bytes */
-    result = PyString_FromStringAndSize(NULL, howMany);
-    if (result != NULL) {
-        /* Get random data */
-        memset(PyString_AS_STRING(result), 0, howMany); /* zero seed */
-        if (! pCryptGenRandom(hCryptProv, howMany, (unsigned char*)
-                              PyString_AS_STRING(result))) {
-            Py_DECREF(result);
-            return win32_error("CryptGenRandom", NULL);
-        }
+Return n pseudo-random bytes.");
+
+static PyObject *
+posix_urandom(PyObject *self, PyObject *args)
+{
+    Py_ssize_t size;
+    PyObject *result;
+    int ret;
+ 
+     /* Read arguments */
+    if (!PyArg_ParseTuple(args, "n:urandom", &size))
+        return NULL;
+    if (size < 0)
+         return PyErr_Format(PyExc_ValueError,
+                             "negative argument not allowed");
+    result = PyBytes_FromStringAndSize(NULL, size);
+    if (result == NULL)
+        return NULL;
+
+    ret = _PyOS_URandom(PyBytes_AS_STRING(result),
+                        PyBytes_GET_SIZE(result));
+    if (ret == -1) {
+        Py_DECREF(result);
+        return NULL;
     }
     return result;
 }
-#endif
-
-#ifdef __VMS
-/* Use openssl random routine */
-#include <openssl/rand.h>
-PyDoc_STRVAR(vms_urandom__doc__,
-"urandom(n) -> str\n\n\
-Return a string of n random bytes suitable for cryptographic use.");
-
-static PyObject*
-vms_urandom(PyObject *self, PyObject *args)
-{
-    int howMany;
-    PyObject* result;
-
-    /* Read arguments */
-    if (! PyArg_ParseTuple(args, "i:urandom", &howMany))
-        return NULL;
-    if (howMany < 0)
-        return PyErr_Format(PyExc_ValueError,
-                            "negative argument not allowed");
-
-    /* Allocate bytes */
-    result = PyString_FromStringAndSize(NULL, howMany);
-    if (result != NULL) {
-        /* Get random data */
-        if (RAND_pseudo_bytes((unsigned char*)
-                              PyString_AS_STRING(result),
-                              howMany) < 0) {
-            Py_DECREF(result);
-            return PyErr_Format(PyExc_ValueError,
-                                "RAND_pseudo_bytes");
-        }
-    }
-    return result;
-}
-#endif
 
 static PyMethodDef posix_methods[] = {
     {"access",          posix_access, METH_VARARGS, posix_access__doc__},
@@ -8787,12 +8705,7 @@
 #ifdef HAVE_GETLOADAVG
     {"getloadavg",      posix_getloadavg, METH_NOARGS, posix_getloadavg__doc__},
 #endif
- #ifdef MS_WINDOWS
-    {"urandom", win32_urandom, METH_VARARGS, win32_urandom__doc__},
- #endif
- #ifdef __VMS
-    {"urandom", vms_urandom, METH_VARARGS, vms_urandom__doc__},
- #endif
+    {"urandom",         posix_urandom,   METH_VARARGS, posix_urandom__doc__},
     {NULL,              NULL}            /* Sentinel */
 };
 
diff -r 9a4131ada792 Objects/bufferobject.c
--- a/Objects/bufferobject.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Objects/bufferobject.c	Mon Feb 06 14:01:17 2012 -0500
@@ -334,10 +334,16 @@
         return -1;
     p = (unsigned char *) ptr;
     len = size;
-    x = *p << 7;
+    if (len == 0) {
+        self->b_hash = 0;
+        return 0;
+    }
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= size;
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
     self->b_hash = x;
diff -r 9a4131ada792 Objects/object.c
--- a/Objects/object.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Objects/object.c	Mon Feb 06 14:01:17 2012 -0500
@@ -1101,6 +1101,8 @@
     return -1;
 }
 
+_Py_HashSecret_t _Py_HashSecret;
+
 long
 PyObject_Hash(PyObject *v)
 {
diff -r 9a4131ada792 Objects/stringobject.c
--- a/Objects/stringobject.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Objects/stringobject.c	Mon Feb 06 14:01:17 2012 -0500
@@ -1212,11 +1212,17 @@
     if (a->ob_shash != -1)
         return a->ob_shash;
     len = Py_SIZE(a);
+    if (len == 0) {
+        a->ob_shash = 0;
+        return 0;
+    }
     p = (unsigned char *) a->ob_sval;
-    x = *p << 7;
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= Py_SIZE(a);
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
     a->ob_shash = x;
diff -r 9a4131ada792 Objects/unicodeobject.c
--- a/Objects/unicodeobject.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Objects/unicodeobject.c	Mon Feb 06 14:01:17 2012 -0500
@@ -6695,11 +6695,17 @@
     if (self->hash != -1)
         return self->hash;
     len = PyUnicode_GET_SIZE(self);
+    if (len == 0) {
+        self->hash = 0;
+        return 0;
+    }
     p = PyUnicode_AS_UNICODE(self);
-    x = *p << 7;
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= PyUnicode_GET_SIZE(self);
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
     self->hash = x;
diff -r 9a4131ada792 PCbuild/pythoncore.vcproj
--- a/PCbuild/pythoncore.vcproj	Fri Jan 27 09:42:45 2012 +0100
+++ b/PCbuild/pythoncore.vcproj	Mon Feb 06 14:01:17 2012 -0500
@@ -1779,6 +1779,10 @@
 				>
 			</File>
 			<File
+				RelativePath="..\Python\random.c"
+				>
+			</File>
+			<File
 				RelativePath="..\Python\structmember.c"
 				>
 			</File>
diff -r 9a4131ada792 Python/pythonrun.c
--- a/Python/pythonrun.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Python/pythonrun.c	Mon Feb 06 14:01:17 2012 -0500
@@ -67,6 +67,7 @@
 static void call_ll_exitfuncs(void);
 extern void _PyUnicode_Init(void);
 extern void _PyUnicode_Fini(void);
+extern void _PyRandom_Init(void);
 
 #ifdef WITH_THREAD
 extern void _PyGILState_Init(PyInterpreterState *, PyThreadState *);
@@ -89,6 +90,7 @@
   true divisions (which they will be in 2.3). */
 int _Py_QnewFlag = 0;
 int Py_NoUserSiteDirectory = 0; /* for -s and site.py */
+int Py_HashRandomizationFlag = 0; /* for -R and PYTHONHASHRANDOMIZATION */
 
 /* PyModule_GetWarningsModule is no longer necessary as of 2.6
 since _warnings is builtin.  This API should not be used. */
@@ -166,6 +168,10 @@
         Py_OptimizeFlag = add_flag(Py_OptimizeFlag, p);
     if ((p = Py_GETENV("PYTHONDONTWRITEBYTECODE")) && *p != '\0')
         Py_DontWriteBytecodeFlag = add_flag(Py_DontWriteBytecodeFlag, p);
+    if ((p = Py_GETENV("PYTHONHASHRANDOMIZATION")) && *p != '\0')
+        Py_HashRandomizationFlag = add_flag(Py_HashRandomizationFlag, p);
+    
+    _PyRandom_Init();
 
     interp = PyInterpreterState_New();
     if (interp == NULL)
diff -r 9a4131ada792 Python/random.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Python/random.c	Mon Feb 06 14:01:17 2012 -0500
@@ -0,0 +1,272 @@
+#include "Python.h"
+#ifdef MS_WINDOWS
+#include <windows.h>
+#else
+#include <fcntl.h>
+#endif
+
+static int random_initialized = 0;
+
+#ifdef MS_WINDOWS
+typedef BOOL (WINAPI *CRYPTACQUIRECONTEXTA)(HCRYPTPROV *phProv,\
+              LPCSTR pszContainer, LPCSTR pszProvider, DWORD dwProvType,\
+              DWORD dwFlags );
+typedef BOOL (WINAPI *CRYPTGENRANDOM)(HCRYPTPROV hProv, DWORD dwLen,\
+              BYTE *pbBuffer );
+
+static CRYPTGENRANDOM pCryptGenRandom = NULL;
+/* This handle is never explicitly released. Instead, the operating
+   system will release it when the process terminates. */
+static HCRYPTPROV hCryptProv = 0;
+
+static int
+win32_urandom_init(int raise)
+{
+    HINSTANCE hAdvAPI32 = NULL;
+    CRYPTACQUIRECONTEXTA pCryptAcquireContext = NULL;
+
+    /* Obtain handle to the DLL containing CryptoAPI. This should not fail. */
+    hAdvAPI32 = GetModuleHandle("advapi32.dll");
+    if(hAdvAPI32 == NULL)
+        goto error;
+
+    /* Obtain pointers to the CryptoAPI functions. This will fail on some early
+       versions of Win95. */
+    pCryptAcquireContext = (CRYPTACQUIRECONTEXTA)GetProcAddress(
+                               hAdvAPI32, "CryptAcquireContextA");
+    if (pCryptAcquireContext == NULL)
+        goto error;
+
+    pCryptGenRandom = (CRYPTGENRANDOM)GetProcAddress(hAdvAPI32,
+                                                     "CryptGenRandom");
+    if (pCryptGenRandom == NULL)
+        goto error;
+
+    /* Acquire context */
+    if (! pCryptAcquireContext(&hCryptProv, NULL, NULL,
+                               PROV_RSA_FULL, CRYPT_VERIFYCONTEXT))
+        goto error;
+
+    return 0;
+
+error:
+    if (raise)
+        PyErr_SetFromWindowsErr(0);
+    else
+        Py_FatalError("Fail to initialize Windows random API (CryptoGen)");
+    return -1;
+}
+
+/* Fill buffer with size pseudo-random bytes generated by the Windows CryptoGen
+   API. Return 0 on success, or -1 on error. */
+static int
+win32_urandom(unsigned char *buffer, Py_ssize_t size, int raise)
+{
+    Py_ssize_t chunk;
+
+    if (hCryptProv == 0)
+    {
+        if (win32_urandom_init(raise) == -1)
+            return -1;
+    }
+
+    while (size > 0)
+    {
+        chunk = size > INT_MAX ? INT_MAX : size;
+        if (!pCryptGenRandom(hCryptProv, chunk, buffer))
+        {
+            /* CryptGenRandom() failed */
+            if (raise)
+                PyErr_SetFromWindowsErr(0);
+            else
+                Py_FatalError("Fail to initialized the randomized hash "
+                        "secret using CryptoGen)");
+            return -1;
+        }
+        buffer += chunk;
+        size -= chunk;
+    }
+    return 0;
+}
+
+#else
+
+/* Read size bytes from /dev/urandom into buffer.
+   Call Py_FatalError() on error. */
+static void
+dev_urandom_noraise(char *buffer, Py_ssize_t size)
+{
+    int fd;
+    Py_ssize_t n;
+
+    assert (0 < size);
+
+    fd = open("/dev/urandom", O_RDONLY);
+    if (fd < 0)
+        Py_FatalError("Fail to open /dev/urandom");
+
+    while (0 < size)
+    {
+        do {
+            n = read(fd, buffer, (size_t)size);
+        } while (n < 0 && errno == EINTR);
+        if (n <= 0)
+        {
+            /* stop on error or if read(size) returned 0 */
+            Py_FatalError("Fail to read bytes from /dev/urandom");
+            break;
+        }
+        buffer += n;
+        size -= (Py_ssize_t)n;
+    }
+    close(fd);
+}
+
+/* Read size bytes from /dev/urandom into buffer.
+   Return 0 on success, raise an exception and return -1 on error. */
+static int
+dev_urandom_python(char *buffer, Py_ssize_t size)
+{
+    int fd;
+    Py_ssize_t n;
+
+    if (size <= 0)
+        return 0;
+
+    Py_BEGIN_ALLOW_THREADS
+    fd = open("/dev/urandom", O_RDONLY);
+    Py_END_ALLOW_THREADS
+    if (fd < 0)
+    {
+        PyErr_SetFromErrnoWithFilename(PyExc_OSError, "/dev/urandom");
+        return -1;
+    }
+
+    Py_BEGIN_ALLOW_THREADS
+    do {
+        do {
+            n = read(fd, buffer, (size_t)size);
+        } while (n < 0 && errno == EINTR);
+        if (n <= 0)
+            break;
+        buffer += n;
+        size -= (Py_ssize_t)n;
+    } while (0 < size);
+    Py_END_ALLOW_THREADS
+
+    if (n <= 0)
+    {
+        /* stop on error or if read(size) returned 0 */
+        if (n < 0)
+            PyErr_SetFromErrno(PyExc_OSError);
+        else
+            PyErr_Format(PyExc_RuntimeError,
+                         "Fail to read %zi bytes from /dev/urandom",
+                         size);
+        close(fd);
+        return -1;
+    }
+    close(fd);
+    return 0;
+}
+#endif
+
+/* Fill buffer with pseudo-random bytes generated by a linear congruent
+   generator (LCG):
+
+       x(n+1) = (x(n) * 214013 + 2531011) % 2^32
+
+   Use bits 23..16 of x(n) to generate a byte. */
+static void
+lcg_urandom(unsigned int x0, unsigned char *buffer, size_t size)
+{
+    size_t index;
+    unsigned int x;
+
+    x = x0;
+    for (index=0; index < size; index++) {
+        x *= 214013;
+        x += 2531011;
+        /* modulo 2 ^ (8 * sizeof(int)) */
+        buffer[index] = (x >> 16) & 0xff;
+    }
+}
+
+/* Fill buffer with size pseudo-random bytes, not suitable for cryptographic
+   use, from the operating random number generator (RNG).
+
+   Return 0 on success, raise an exception and return -1 on error. */
+int
+_PyOS_URandom(void *buffer, Py_ssize_t size)
+{
+    if (size < 0) {
+        PyErr_Format(PyExc_ValueError,
+                     "negative argument not allowed");
+        return -1;
+    }
+    if (size == 0)
+        return 0;
+
+#ifdef MS_WINDOWS
+    return win32_urandom((unsigned char *)buffer, size, 1);
+#else
+    return dev_urandom_python((char*)buffer, size);
+#endif
+}
+
+void
+_PyRandom_Init(void)
+{
+    char *env;
+    void *secret = &_Py_HashSecret;
+    Py_ssize_t secret_size = sizeof(_Py_HashSecret);
+
+    if (random_initialized)
+        return;
+    random_initialized = 1;
+
+    /*
+      By default, hash randomization is disabled, and only
+      enabled if PYTHONHASHRANDOMIZATION is set to non-empty
+      or if "-R" is provided at the command line:
+    */
+    if (!Py_HashRandomizationFlag) {
+        /* Disable the randomized hash: */
+        memset(secret, 0, secret_size);
+        return;
+    }
+
+    /*
+      PYTHONHASHRANDOMIZATION was found; generate a per-process secret,
+      using PYTHONHASHSEED if provided.
+    */
+
+    env = Py_GETENV("PYTHONHASHSEED");
+    if (env && *env != '\0') {
+        char *endptr = env;
+        unsigned long seed;
+        seed = strtoul(env, &endptr, 10);
+        if (*endptr != '\0'
+            || seed > 4294967295UL
+            || (errno == ERANGE && seed == ULONG_MAX))
+        {
+            Py_FatalError("PYTHONHASHSEED must be an integer "
+                          "in range [0; 4294967295]");
+        }
+        if (seed == 0) {
+            /* disable the randomized hash */
+            memset(secret, 0, secret_size);
+        }
+        else {
+            lcg_urandom(seed, (unsigned char*)secret, secret_size);
+        }
+    }
+    else {
+#ifdef MS_WINDOWS
+        (void)win32_urandom((unsigned char *)secret, secret_size, 0);
+#else /* #ifdef MS_WINDOWS */
+        dev_urandom_noraise((char*)secret, secret_size);
+#endif
+    }
+}
+
diff -r 9a4131ada792 Python/sysmodule.c
--- a/Python/sysmodule.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Python/sysmodule.c	Mon Feb 06 14:01:17 2012 -0500
@@ -1224,6 +1224,7 @@
     {"unicode",                 "-U"},
     /* {"skip_first",                   "-x"}, */
     {"bytes_warning", "-b"},
+    {"hash_randomization", "-R"},
     {0}
 };
 
@@ -1232,9 +1233,9 @@
     flags__doc__,       /* doc */
     flags_fields,       /* fields */
 #ifdef RISCOS
+    17
+#else
     16
-#else
-    15
 #endif
 };
 
@@ -1271,6 +1272,7 @@
     SetFlag(Py_UnicodeFlag);
     /* SetFlag(skipfirstline); */
     SetFlag(Py_BytesWarningFlag);
+    SetFlag(Py_HashRandomizationFlag);
 #undef SetFlag
 
     if (PyErr_Occurred()) {
-------------- next part --------------
diff -r 9a4131ada792 Lib/json/__init__.py
--- a/Lib/json/__init__.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/json/__init__.py	Mon Feb 06 14:01:35 2012 -0500
@@ -29,8 +29,8 @@
 Compact encoding::
 
     >>> import json
-    >>> json.dumps([1,2,3,{'4': 5, '6': 7}], separators=(',',':'))
-    '[1,2,3,{"4":5,"6":7}]'
+    >>> json.dumps([1,2,3,{"4":"5"}], separators=(',',':'))
+    '[1,2,3,{"4":"5"}]'
 
 Pretty printing (using repr() because of extraneous whitespace in the output)::
 
-------------- next part --------------
diff -r e7706bdaaa0d Doc/library/sys.rst
--- a/Doc/library/sys.rst	Fri Jan 27 09:48:47 2012 +0100
+++ b/Doc/library/sys.rst	Mon Feb 06 14:02:24 2012 -0500
@@ -220,6 +220,7 @@
    :const:`ignore_environment`   :option:`-E`
    :const:`verbose`              :option:`-v`
    :const:`bytes_warning`        :option:`-b`
+   :const:`hash_randomization`   :option:`-R`
    ============================= =============================
 
 
diff -r e7706bdaaa0d Doc/reference/datamodel.rst
--- a/Doc/reference/datamodel.rst	Fri Jan 27 09:48:47 2012 +0100
+++ b/Doc/reference/datamodel.rst	Mon Feb 06 14:02:24 2012 -0500
@@ -1265,6 +1265,8 @@
    inheritance of :meth:`__hash__` will be blocked, just as if :attr:`__hash__`
    had been explicitly set to :const:`None`.
 
+   See also the :option:`-R` command-line option.
+
 
 .. method:: object.__bool__(self)
 
diff -r e7706bdaaa0d Doc/using/cmdline.rst
--- a/Doc/using/cmdline.rst	Fri Jan 27 09:48:47 2012 +0100
+++ b/Doc/using/cmdline.rst	Mon Feb 06 14:02:24 2012 -0500
@@ -21,7 +21,7 @@
 
 When invoking Python, you may specify any of these options::
 
-    python [-bBdEhiOsSuvVWx?] [-c command | -m module-name | script | - ] [args]
+    python [-bBdEhiORsSuvVWx?] [-c command | -m module-name | script | - ] [args]
 
 The most common use case is, of course, a simple invocation of a script::
 
@@ -215,6 +215,30 @@
    Discard docstrings in addition to the :option:`-O` optimizations.
 
 
+.. cmdoption:: -R
+
+   Turn on "hash randomization, so that the :meth:`__hash__` values of str,
+   bytes and datetime objects are "salted" with an unpredictable random value.
+   Although they remain constant within an individual Python process, they
+   are not predictable between repeated invocations of Python.
+
+   This is intended to provide protection against a denial-of-service
+   caused by carefully-chosen inputs that exploit the worst case performance
+   of a dict lookup, O(n^2) complexity.  See:
+
+       http://www.ocert.org/advisories/ocert-2011-003.html
+
+   for details.
+
+   Changing hash values affects the order in which keys are retrieved from
+   a dict.  Although Python has never made guarantees about this ordering
+   (and it typically varies between 32-bit and 64-bit builds), enough
+   real-world code implicitly relies on this non-guaranteed behavior that
+   the randomization is disabled by default.
+
+   See also :envvar:`PYTHONHASHRANDOMIZATION`.
+
+
 .. cmdoption:: -s
 
    Don't add user site directory to sys.path
@@ -435,6 +459,24 @@
    import of source modules.
 
 
+.. envvar:: PYTHONHASHRANDOMIZATION
+
+   If this is set to a non-empty string it is equivalent to specifying the
+   :option:`-R` option.
+
+
+.. envvar:: PYTHONHASHSEED
+
+   If this is set, it is used as a fixed seed for generating the hash() of
+   the types covered by the :option:`-R` option (or its equivalent,
+   :envvar:`PYTHONHASHRANDOMIZATION`.
+
+   Its purpose is for use in selftests for the interpreter.
+
+   It should be a decimal number in the range [0; 4294967295].  Specifying
+   the value 0 overrides the other setting, disabling the hash random salt.
+
+
 .. envvar:: PYTHONIOENCODING
 
    Overrides the encoding used for stdin/stdout/stderr, in the syntax
diff -r e7706bdaaa0d Include/object.h
--- a/Include/object.h	Fri Jan 27 09:48:47 2012 +0100
+++ b/Include/object.h	Mon Feb 06 14:02:24 2012 -0500
@@ -473,6 +473,12 @@
 PyAPI_FUNC(long) _Py_HashDouble(double);
 PyAPI_FUNC(long) _Py_HashPointer(void*);
 
+typedef struct {
+    long prefix;
+    long suffix;
+} _Py_HashSecret_t;
+PyAPI_DATA(_Py_HashSecret_t) _Py_HashSecret;
+
 /* Helper for passing objects to printf and the like */
 #define PyObject_REPR(obj) _PyUnicode_AsString(PyObject_Repr(obj))
 
diff -r e7706bdaaa0d Include/pydebug.h
--- a/Include/pydebug.h	Fri Jan 27 09:48:47 2012 +0100
+++ b/Include/pydebug.h	Mon Feb 06 14:02:24 2012 -0500
@@ -19,6 +19,7 @@
 PyAPI_DATA(int) Py_DontWriteBytecodeFlag;
 PyAPI_DATA(int) Py_NoUserSiteDirectory;
 PyAPI_DATA(int) Py_UnbufferedStdioFlag;
+PyAPI_DATA(int) Py_HashRandomizationFlag;
 
 /* this is a wrapper around getenv() that pays attention to
    Py_IgnoreEnvironmentFlag.  It should be used for getting variables like
diff -r e7706bdaaa0d Include/pythonrun.h
--- a/Include/pythonrun.h	Fri Jan 27 09:48:47 2012 +0100
+++ b/Include/pythonrun.h	Mon Feb 06 14:02:24 2012 -0500
@@ -174,6 +174,8 @@
 PyAPI_FUNC(PyOS_sighandler_t) PyOS_getsig(int);
 PyAPI_FUNC(PyOS_sighandler_t) PyOS_setsig(int, PyOS_sighandler_t);
 
+/* Random */
+PyAPI_FUNC(int) _PyOS_URandom (void *buffer, Py_ssize_t size);
 
 #ifdef __cplusplus
 }
diff -r e7706bdaaa0d Lib/os.py
--- a/Lib/os.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/os.py	Mon Feb 06 14:02:24 2012 -0500
@@ -611,23 +611,6 @@
 except NameError: # statvfs_result may not exist
     pass
 
-if not _exists("urandom"):
-    def urandom(n):
-        """urandom(n) -> str
-
-        Return a string of n random bytes suitable for cryptographic use.
-
-        """
-        try:
-            _urandomfd = open("/dev/urandom", O_RDONLY)
-        except (OSError, IOError):
-            raise NotImplementedError("/dev/urandom (or equivalent) not found")
-        bs = b""
-        while len(bs) < n:
-            bs += read(_urandomfd, n - len(bs))
-        close(_urandomfd)
-        return bs
-
 # Supply os.popen()
 def popen(cmd, mode="r", buffering=-1):
     if not isinstance(cmd, str):
diff -r e7706bdaaa0d Lib/test/regrtest.py
--- a/Lib/test/regrtest.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/regrtest.py	Mon Feb 06 14:02:24 2012 -0500
@@ -428,6 +428,11 @@
         except ValueError:
             print("Couldn't find starting test (%s), using all tests" % start)
     if randomize:
+        hashseed = os.getenv('PYTHONHASHSEED')
+        if not hashseed:
+            os.environ['PYTHONHASHSEED'] = str(random_seed)
+            os.execv(sys.executable, [sys.executable] + sys.argv)
+            return
         random.seed(random_seed)
         print("Using random seed", random_seed)
         random.shuffle(tests)
diff -r e7706bdaaa0d Lib/test/test_cmd_line.py
--- a/Lib/test/test_cmd_line.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_cmd_line.py	Mon Feb 06 14:02:24 2012 -0500
@@ -190,6 +190,22 @@
             self.assertTrue(path1.encode('ascii') in stdout)
             self.assertTrue(path2.encode('ascii') in stdout)
 
+    def test_hash_randomization(self):
+        # Verify that -R enables hash randomization:
+        self.verify_valid_flag('-R')
+        hashes = []
+        for i in range(2):
+            code = 'print(hash("spam"))'
+            data, rc = self.start_python_and_exit_code('-R', '-c', code)
+            self.assertEqual(rc, 0)
+            hashes.append(data)
+        self.assertNotEqual(hashes[0], hashes[1])
+
+        # Verify that sys.flags contains hash_randomization
+        code = 'import sys; print(sys.flags)'
+        data, rc = self.start_python_and_exit_code('-R', '-c', code)
+        self.assertEqual(rc,0)
+        self.assertIn(b'hash_randomization=1', data)
 
 def test_main():
     test.support.run_unittest(CmdLineTest)
diff -r e7706bdaaa0d Lib/test/test_hash.py
--- a/Lib/test/test_hash.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_hash.py	Mon Feb 06 14:02:24 2012 -0500
@@ -3,10 +3,15 @@
 #
 # Also test that hash implementations are inherited as expected
 
+import datetime
+import struct
 import unittest
 from test import support
+from test.script_helper import assert_python_ok
 from collections import Hashable
 
+IS_64BIT = (struct.calcsize('l') == 8)
+
 
 class HashEqualityTestCase(unittest.TestCase):
 
@@ -118,10 +123,92 @@
         for obj in self.hashes_to_check:
             self.assertEqual(hash(obj), _default_hash(obj))
 
+class HashRandomizationTests(unittest.TestCase):
+
+    # Each subclass should define a field "repr_", containing the repr() of
+    # an object to be tested
+
+    def get_hash_command(self, repr_):
+        return 'print(hash(%s))' % repr_
+
+    def get_hash(self, repr_, randomization=None, seed=None):
+        env = {}
+        if randomization is not None:
+            env['PYTHONHASHRANDOMIZATION'] = str(randomization)
+        if seed is not None:
+            env['PYTHONHASHSEED'] = str(seed)
+        out = assert_python_ok(
+            '-c', self.get_hash_command(repr_),
+            **env)
+        stdout = out[1].strip()
+        return int(stdout)
+
+    def test_randomized_hash(self):
+        # two runs should return different hashes
+        run1 = self.get_hash(self.repr_, randomization=1)
+        run2 = self.get_hash(self.repr_, randomization=1)
+        self.assertNotEqual(run1, run2)
+
+class StringlikeHashRandomizationTests(HashRandomizationTests):
+    def test_null_hash(self):
+        # PYTHONHASHSEED=0 disables the randomized hash
+        if IS_64BIT:
+            known_hash_of_obj = 1453079729188098211
+        else:
+            known_hash_of_obj = -1600925533
+
+        # Randomization is disabled by default:
+        self.assertEqual(self.get_hash(self.repr_), known_hash_of_obj)
+
+        # If enabled, it can still be disabled by setting the seed to 0:
+        self.assertEqual(self.get_hash(self.repr_, randomization=1, seed=0),
+                         known_hash_of_obj)
+
+    def test_fixed_hash(self):
+        # test a fixed seed for the randomized hash
+        # Note that all types share the same values:
+        if IS_64BIT:
+            h = -4410911502303878509
+        else:
+            h = -206076799
+        self.assertEqual(self.get_hash(self.repr_, randomization=1, seed=42),
+                         h)
+
+class StrHashRandomizationTests(StringlikeHashRandomizationTests):
+    repr_ = repr('abc')
+
+    def test_empty_string(self):
+        self.assertEqual(hash(""), 0)
+
+class BytesHashRandomizationTests(StringlikeHashRandomizationTests):
+    repr_ = repr(b'abc')
+
+    def test_empty_string(self):
+        self.assertEqual(hash(b""), 0)
+
+class DatetimeTests(HashRandomizationTests):
+    def get_hash_command(self, repr_):
+        return 'import datetime; print(hash(%s))' % repr_
+
+class DatetimeDateTests(DatetimeTests):
+    repr_ = repr(datetime.date(1066, 10, 14))
+
+class DatetimeDatetimeTests(DatetimeTests):
+    repr_ = repr(datetime.datetime(1, 2, 3, 4, 5, 6, 7))
+
+class DatetimeTimeTests(DatetimeTests):
+    repr_ = repr(datetime.time(0))
+
 def test_main():
     support.run_unittest(HashEqualityTestCase,
                               HashInheritanceTestCase,
-                              HashBuiltinsTestCase)
+                              HashBuiltinsTestCase,
+                         StrHashRandomizationTests,
+                         BytesHashRandomizationTests,
+                         DatetimeDateTests,
+                         DatetimeDatetimeTests,
+                         DatetimeTimeTests)
+
 
 
 if __name__ == "__main__":
diff -r e7706bdaaa0d Lib/test/test_os.py
--- a/Lib/test/test_os.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_os.py	Mon Feb 06 14:02:24 2012 -0500
@@ -9,6 +9,7 @@
 import sys
 import shutil
 from test import support
+from test.script_helper import assert_python_ok
 
 # Detect whether we're on a Linux system that uses the (now outdated
 # and unmaintained) linuxthreads threading library.  There's an issue
@@ -574,14 +575,33 @@
         f.close()
 
 class URandomTests(unittest.TestCase):
-    def test_urandom(self):
-        try:
-            self.assertEqual(len(os.urandom(1)), 1)
-            self.assertEqual(len(os.urandom(10)), 10)
-            self.assertEqual(len(os.urandom(100)), 100)
-            self.assertEqual(len(os.urandom(1000)), 1000)
-        except NotImplementedError:
-            pass
+    def test_urandom_length(self):
+        self.assertEqual(len(os.urandom(0)), 0)
+        self.assertEqual(len(os.urandom(1)), 1)
+        self.assertEqual(len(os.urandom(10)), 10)
+        self.assertEqual(len(os.urandom(100)), 100)
+        self.assertEqual(len(os.urandom(1000)), 1000)
+
+    def test_urandom_value(self):
+        data1 = os.urandom(16)
+        data2 = os.urandom(16)
+        self.assertNotEqual(data1, data2)
+
+    def get_urandom_subprocess(self, count):
+        code = '\n'.join((
+            'import os, sys',
+            'data = os.urandom(%s)' % count,
+            'sys.stdout.buffer.write(data)',
+            'sys.stdout.buffer.flush()'))
+        out = assert_python_ok('-c', code)
+        stdout = out[1]
+        self.assertEqual(len(stdout), 16)
+        return stdout
+
+    def test_urandom_subprocess(self):
+        data1 = self.get_urandom_subprocess(16)
+        data2 = self.get_urandom_subprocess(16)
+        self.assertNotEqual(data1, data2)
 
 class ExecTests(unittest.TestCase):
     @unittest.skipIf(USING_LINUXTHREADS,
diff -r e7706bdaaa0d Lib/test/test_sys.py
--- a/Lib/test/test_sys.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_sys.py	Mon Feb 06 14:02:24 2012 -0500
@@ -446,7 +446,7 @@
         attrs = ("debug", "division_warning",
                  "inspect", "interactive", "optimize", "dont_write_bytecode",
                  "no_user_site", "no_site", "ignore_environment", "verbose",
-                 "bytes_warning")
+                 "bytes_warning", "hash_randomization")
         for attr in attrs:
             self.assertTrue(hasattr(sys.flags, attr), attr)
             self.assertEqual(type(getattr(sys.flags, attr)), int, attr)
diff -r e7706bdaaa0d Makefile.pre.in
--- a/Makefile.pre.in	Fri Jan 27 09:48:47 2012 +0100
+++ b/Makefile.pre.in	Mon Feb 06 14:02:24 2012 -0500
@@ -305,6 +305,7 @@
 		Python/pymath.o \
 		Python/pystate.o \
 		Python/pythonrun.o \
+		Python/random.o \
 		Python/structmember.o \
 		Python/symtable.o \
 		Python/sysmodule.o \
diff -r e7706bdaaa0d Misc/NEWS
--- a/Misc/NEWS	Fri Jan 27 09:48:47 2012 +0100
+++ b/Misc/NEWS	Mon Feb 06 14:02:24 2012 -0500
@@ -10,6 +10,12 @@
 Core and Builtins
 -----------------
 
+- Issue #13703: oCERT-2011-003: add -R command-line option and
+  PYTHONHASHRANDOMIZATION (and PYTHONHASHSEED) environment variables, to
+  provide an opt-in way to protect against denial of service attacks due to
+  hash collisions within the dict and set types.  Patch by David Malcolm,
+  based on work by Victor Stinner.
+
 Library
 -------
 
diff -r e7706bdaaa0d Misc/python.man
--- a/Misc/python.man	Fri Jan 27 09:48:47 2012 +0100
+++ b/Misc/python.man	Mon Feb 06 14:02:24 2012 -0500
@@ -34,6 +34,9 @@
 .B \-OO
 ]
 [
+.B \-R
+]
+[
 .B -Q
 .I argument
 ]
@@ -145,6 +148,18 @@
 .B \-OO
 Discard docstrings in addition to the \fB-O\fP optimizations.
 .TP
+.B \-R
+Turn on "hash randomization", so that the hash() values of str, bytes and
+datetime objects are "salted" with an unpredictable pseudo-random value.
+Although they remain constant within an individual Python process, they are
+not predictable between repeated invocations of Python.
+.IP
+This is intended to provide protection against a denial of service
+caused by carefully-chosen inputs that exploit the worst case performance
+of a dict lookup, O(n^2) complexity.  See
+http://www.ocert.org/advisories/ocert-2011-003.html
+for details.
+.TP
 .BI "\-Q " argument
 Division control; see PEP 238.  The argument must be one of "old" (the
 default, int/int and long/long return an int or long), "new" (new
@@ -403,6 +418,9 @@
 If this is set to a non-empty string it is equivalent to specifying
 the \fB\-v\fP option. If set to an integer, it is equivalent to
 specifying \fB\-v\fP multiple times. 
+.IP PYTHONHASHRANDOMIZATION
+If this is set to a non-empty string it is equivalent to specifying the
+\fB\-R\fP option.
 .SH AUTHOR
 The Python Software Foundation: http://www.python.org/psf
 .SH INTERNET RESOURCES
diff -r e7706bdaaa0d Modules/datetimemodule.c
--- a/Modules/datetimemodule.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Modules/datetimemodule.c	Mon Feb 06 14:02:24 2012 -0500
@@ -2566,10 +2566,12 @@
     register long x;
 
     p = (unsigned char *) data;
-    x = *p << 7;
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= len;
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
 
diff -r e7706bdaaa0d Modules/main.c
--- a/Modules/main.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Modules/main.c	Mon Feb 06 14:02:24 2012 -0500
@@ -47,7 +47,7 @@
 static int  orig_argc;
 
 /* command line options */
-#define BASE_OPTS L"bBc:dEhiJm:OsStuvVW:xX?"
+#define BASE_OPTS L"bBc:dEhiJm:ORsStuvVW:xX?"
 
 #define PROGRAM_OPTS BASE_OPTS
 
@@ -72,6 +72,9 @@
 -m mod : run library module as a script (terminates option list)\n\
 -O     : optimize generated bytecode slightly; also PYTHONOPTIMIZE=x\n\
 -OO    : remove doc-strings in addition to the -O optimizations\n\
+-R     : use a pseudo-random salt to make hash() values of various types be\n\
+         unpredictable between separate invocations of the interpreter, as\n\
+         a defence against denial-of-service attacks\n\
 -s     : don't add user site directory to sys.path; also PYTHONNOUSERSITE\n\
 -S     : don't imply 'import site' on initialization\n\
 ";
@@ -99,6 +102,11 @@
 PYTHONCASEOK : ignore case in 'import' statements (Windows).\n\
 PYTHONIOENCODING: Encoding[:errors] used for stdin/stdout/stderr.\n\
 ";
+static char *usage_6 = "\
+PYTHONHASHRANDOMIZATION : make hash() values of various types be unpredictable\n\
+                          between separate invocations of the interpreter, as\n\
+                          a defence against denial-of-service attacks\n\
+";
 
 #ifndef MS_WINDOWS
 static FILE*
@@ -136,6 +144,7 @@
         fputs(usage_3, f);
         fprintf(f, usage_4, DELIM);
         fprintf(f, usage_5, DELIM, PYTHONHOMEHELP);
+        fputs(usage_6, f);
     }
 #if defined(__VMS)
     if (exitcode == 0) {
@@ -373,6 +382,10 @@
             PySys_AddWarnOption(_PyOS_optarg);
             break;
 
+        case 'R':
+            Py_HashRandomizationFlag++;
+            break;
+
         /* This space reserved for other options */
 
         default:
diff -r e7706bdaaa0d Modules/posixmodule.c
--- a/Modules/posixmodule.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Modules/posixmodule.c	Mon Feb 06 14:02:24 2012 -0500
@@ -6942,82 +6942,6 @@
 }
 #endif
 
-#ifdef MS_WINDOWS
-
-PyDoc_STRVAR(win32_urandom__doc__,
-"urandom(n) -> str\n\n\
-Return n random bytes suitable for cryptographic use.");
-
-typedef BOOL (WINAPI *CRYPTACQUIRECONTEXTA)(HCRYPTPROV *phProv,\
-              LPCSTR pszContainer, LPCSTR pszProvider, DWORD dwProvType,\
-              DWORD dwFlags );
-typedef BOOL (WINAPI *CRYPTGENRANDOM)(HCRYPTPROV hProv, DWORD dwLen,\
-              BYTE *pbBuffer );
-
-static CRYPTGENRANDOM pCryptGenRandom = NULL;
-/* This handle is never explicitly released. Instead, the operating
-   system will release it when the process terminates. */
-static HCRYPTPROV hCryptProv = 0;
-
-static PyObject*
-win32_urandom(PyObject *self, PyObject *args)
-{
-    int howMany;
-    PyObject* result;
-
-    /* Read arguments */
-    if (! PyArg_ParseTuple(args, "i:urandom", &howMany))
-        return NULL;
-    if (howMany < 0)
-        return PyErr_Format(PyExc_ValueError,
-                            "negative argument not allowed");
-
-    if (hCryptProv == 0) {
-        HINSTANCE hAdvAPI32 = NULL;
-        CRYPTACQUIRECONTEXTA pCryptAcquireContext = NULL;
-
-        /* Obtain handle to the DLL containing CryptoAPI
-           This should not fail         */
-        hAdvAPI32 = GetModuleHandle("advapi32.dll");
-        if(hAdvAPI32 == NULL)
-            return win32_error("GetModuleHandle", NULL);
-
-        /* Obtain pointers to the CryptoAPI functions
-           This will fail on some early versions of Win95 */
-        pCryptAcquireContext = (CRYPTACQUIRECONTEXTA)GetProcAddress(
-                                        hAdvAPI32,
-                                        "CryptAcquireContextA");
-        if (pCryptAcquireContext == NULL)
-            return PyErr_Format(PyExc_NotImplementedError,
-                                "CryptAcquireContextA not found");
-
-        pCryptGenRandom = (CRYPTGENRANDOM)GetProcAddress(
-                                        hAdvAPI32, "CryptGenRandom");
-        if (pCryptGenRandom == NULL)
-            return PyErr_Format(PyExc_NotImplementedError,
-                                "CryptGenRandom not found");
-
-        /* Acquire context */
-        if (! pCryptAcquireContext(&hCryptProv, NULL, NULL,
-                                   PROV_RSA_FULL, CRYPT_VERIFYCONTEXT))
-            return win32_error("CryptAcquireContext", NULL);
-    }
-
-    /* Allocate bytes */
-    result = PyBytes_FromStringAndSize(NULL, howMany);
-    if (result != NULL) {
-        /* Get random data */
-        memset(PyBytes_AS_STRING(result), 0, howMany); /* zero seed */
-        if (! pCryptGenRandom(hCryptProv, howMany, (unsigned char*)
-                              PyBytes_AS_STRING(result))) {
-            Py_DECREF(result);
-            return win32_error("CryptGenRandom", NULL);
-        }
-    }
-    return result;
-}
-#endif
-
 PyDoc_STRVAR(device_encoding__doc__,
 "device_encoding(fd) -> str\n\n\
 Return a string describing the encoding of the device\n\
@@ -7055,41 +6979,35 @@
     return Py_None;
 }
 
-#ifdef __VMS
-/* Use openssl random routine */
-#include <openssl/rand.h>
-PyDoc_STRVAR(vms_urandom__doc__,
+PyDoc_STRVAR(posix_urandom__doc__,
 "urandom(n) -> str\n\n\
-Return n random bytes suitable for cryptographic use.");
-
-static PyObject*
-vms_urandom(PyObject *self, PyObject *args)
-{
-    int howMany;
-    PyObject* result;
-
-    /* Read arguments */
-    if (! PyArg_ParseTuple(args, "i:urandom", &howMany))
-        return NULL;
-    if (howMany < 0)
+Return n pseudo-random bytes.");
+
+static PyObject *
+posix_urandom(PyObject *self, PyObject *args)
+{
+    Py_ssize_t size;
+    PyObject *result;
+    int ret;
+ 
+     /* Read arguments */
+    if (!PyArg_ParseTuple(args, "n:urandom", &size))
+        return NULL;
+    if (size < 0)
         return PyErr_Format(PyExc_ValueError,
                             "negative argument not allowed");
-
-    /* Allocate bytes */
-    result = PyBytes_FromStringAndSize(NULL, howMany);
-    if (result != NULL) {
-        /* Get random data */
-        if (RAND_pseudo_bytes((unsigned char*)
-                              PyBytes_AS_STRING(result),
-                              howMany) < 0) {
-            Py_DECREF(result);
-            return PyErr_Format(PyExc_ValueError,
-                                "RAND_pseudo_bytes");
-        }
+    result = PyBytes_FromStringAndSize(NULL, size);
+    if (result == NULL)
+        return NULL;
+
+    ret = _PyOS_URandom(PyBytes_AS_STRING(result),
+                        PyBytes_GET_SIZE(result));
+    if (ret == -1) {
+        Py_DECREF(result);
+        return NULL;
     }
     return result;
 }
-#endif
 
 static PyMethodDef posix_methods[] = {
     {"access",          posix_access, METH_VARARGS, posix_access__doc__},
@@ -7374,12 +7292,7 @@
 #ifdef HAVE_GETLOADAVG
     {"getloadavg",      posix_getloadavg, METH_NOARGS, posix_getloadavg__doc__},
 #endif
- #ifdef MS_WINDOWS
-    {"urandom", win32_urandom, METH_VARARGS, win32_urandom__doc__},
- #endif
- #ifdef __VMS
-    {"urandom", vms_urandom, METH_VARARGS, vms_urandom__doc__},
- #endif
+    {"urandom",         posix_urandom,   METH_VARARGS, posix_urandom__doc__},
     {NULL,              NULL}            /* Sentinel */
 };
 
diff -r e7706bdaaa0d Objects/bytesobject.c
--- a/Objects/bytesobject.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Objects/bytesobject.c	Mon Feb 06 14:02:24 2012 -0500
@@ -899,11 +899,17 @@
     if (a->ob_shash != -1)
         return a->ob_shash;
     len = Py_SIZE(a);
+    if (len == 0) {
+        a->ob_shash = 0;
+        return 0;
+    }
     p = (unsigned char *) a->ob_sval;
-    x = *p << 7;
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= Py_SIZE(a);
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
     a->ob_shash = x;
diff -r e7706bdaaa0d Objects/object.c
--- a/Objects/object.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Objects/object.c	Mon Feb 06 14:02:24 2012 -0500
@@ -712,6 +712,8 @@
     return -1;
 }
 
+_Py_HashSecret_t _Py_HashSecret;
+
 long
 PyObject_Hash(PyObject *v)
 {
diff -r e7706bdaaa0d Objects/unicodeobject.c
--- a/Objects/unicodeobject.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Objects/unicodeobject.c	Mon Feb 06 14:02:24 2012 -0500
@@ -7344,11 +7344,17 @@
     if (self->hash != -1)
         return self->hash;
     len = Py_SIZE(self);
+    if (len == 0) {
+        self->hash = 0;
+        return 0;
+    }
     p = self->str;
-    x = *p << 7;
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= Py_SIZE(self);
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
     self->hash = x;
diff -r e7706bdaaa0d PCbuild/pythoncore.vcproj
--- a/PCbuild/pythoncore.vcproj	Fri Jan 27 09:48:47 2012 +0100
+++ b/PCbuild/pythoncore.vcproj	Mon Feb 06 14:02:24 2012 -0500
@@ -1778,6 +1778,10 @@
 				RelativePath="..\Python\pythonrun.c"
 				>
 			</File>
+ 			<File
+				RelativePath="..\Python\random.c"
+				>
+			</File>
 			<File
 				RelativePath="..\Python\structmember.c"
 				>
diff -r e7706bdaaa0d Python/pythonrun.c
--- a/Python/pythonrun.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Python/pythonrun.c	Mon Feb 06 14:02:24 2012 -0500
@@ -73,6 +73,7 @@
 extern void _PyUnicode_Fini(void);
 extern int _PyLong_Init(void);
 extern void PyLong_Fini(void);
+extern void _PyRandom_Init(void);
 
 #ifdef WITH_THREAD
 extern void _PyGILState_Init(PyInterpreterState *, PyThreadState *);
@@ -91,6 +92,7 @@
 int Py_IgnoreEnvironmentFlag; /* e.g. PYTHONPATH, PYTHONHOME */
 int Py_NoUserSiteDirectory = 0; /* for -s and site.py */
 int Py_UnbufferedStdioFlag = 0; /* Unbuffered binary std{in,out,err} */
+int Py_HashRandomizationFlag = 0; /* for -R and PYTHONHASHRANDOMIZATION */
 
 /* PyModule_GetWarningsModule is no longer necessary as of 2.6
 since _warnings is builtin.  This API should not be used. */
@@ -195,6 +197,10 @@
         Py_OptimizeFlag = add_flag(Py_OptimizeFlag, p);
     if ((p = Py_GETENV("PYTHONDONTWRITEBYTECODE")) && *p != '\0')
         Py_DontWriteBytecodeFlag = add_flag(Py_DontWriteBytecodeFlag, p);
+    if ((p = Py_GETENV("PYTHONHASHRANDOMIZATION")) && *p != '\0')
+        Py_HashRandomizationFlag = add_flag(Py_HashRandomizationFlag, p);
+    
+    _PyRandom_Init();
 
     interp = PyInterpreterState_New();
     if (interp == NULL)
diff -r e7706bdaaa0d Python/random.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Python/random.c	Mon Feb 06 14:02:24 2012 -0500
@@ -0,0 +1,272 @@
+#include "Python.h"
+#ifdef MS_WINDOWS
+#include <windows.h>
+#else
+#include <fcntl.h>
+#endif
+
+static int random_initialized = 0;
+
+#ifdef MS_WINDOWS
+typedef BOOL (WINAPI *CRYPTACQUIRECONTEXTA)(HCRYPTPROV *phProv,\
+              LPCSTR pszContainer, LPCSTR pszProvider, DWORD dwProvType,\
+              DWORD dwFlags );
+typedef BOOL (WINAPI *CRYPTGENRANDOM)(HCRYPTPROV hProv, DWORD dwLen,\
+              BYTE *pbBuffer );
+
+static CRYPTGENRANDOM pCryptGenRandom = NULL;
+/* This handle is never explicitly released. Instead, the operating
+   system will release it when the process terminates. */
+static HCRYPTPROV hCryptProv = 0;
+
+static int
+win32_urandom_init(int raise)
+{
+    HINSTANCE hAdvAPI32 = NULL;
+    CRYPTACQUIRECONTEXTA pCryptAcquireContext = NULL;
+
+    /* Obtain handle to the DLL containing CryptoAPI. This should not fail. */
+    hAdvAPI32 = GetModuleHandle("advapi32.dll");
+    if(hAdvAPI32 == NULL)
+        goto error;
+
+    /* Obtain pointers to the CryptoAPI functions. This will fail on some early
+       versions of Win95. */
+    pCryptAcquireContext = (CRYPTACQUIRECONTEXTA)GetProcAddress(
+                               hAdvAPI32, "CryptAcquireContextA");
+    if (pCryptAcquireContext == NULL)
+        goto error;
+
+    pCryptGenRandom = (CRYPTGENRANDOM)GetProcAddress(hAdvAPI32,
+                                                     "CryptGenRandom");
+    if (pCryptGenRandom == NULL)
+        goto error;
+
+    /* Acquire context */
+    if (! pCryptAcquireContext(&hCryptProv, NULL, NULL,
+                               PROV_RSA_FULL, CRYPT_VERIFYCONTEXT))
+        goto error;
+
+    return 0;
+
+error:
+    if (raise)
+        PyErr_SetFromWindowsErr(0);
+    else
+        Py_FatalError("Failed to initialize Windows random API (CryptoGen)");
+    return -1;
+}
+
+/* Fill buffer with size pseudo-random bytes generated by the Windows CryptoGen
+   API. Return 0 on success, or -1 on error. */
+static int
+win32_urandom(unsigned char *buffer, Py_ssize_t size, int raise)
+{
+    Py_ssize_t chunk;
+
+    if (hCryptProv == 0)
+    {
+        if (win32_urandom_init(raise) == -1)
+            return -1;
+    }
+
+    while (size > 0)
+    {
+        chunk = size > INT_MAX ? INT_MAX : size;
+        if (!pCryptGenRandom(hCryptProv, chunk, buffer))
+        {
+            /* CryptGenRandom() failed */
+            if (raise)
+                PyErr_SetFromWindowsErr(0);
+            else
+                Py_FatalError("Failed to initialized the randomized hash "
+                        "secret using CryptoGen)");
+            return -1;
+        }
+        buffer += chunk;
+        size -= chunk;
+    }
+    return 0;
+}
+
+#else
+
+/* Read size bytes from /dev/urandom into buffer.
+   Call Py_FatalError() on error. */
+static void
+dev_urandom_noraise(char *buffer, Py_ssize_t size)
+{
+    int fd;
+    Py_ssize_t n;
+
+    assert (0 < size);
+
+    fd = open("/dev/urandom", O_RDONLY);
+    if (fd < 0)
+        Py_FatalError("Failed to open /dev/urandom");
+
+    while (0 < size)
+    {
+        do {
+            n = read(fd, buffer, (size_t)size);
+        } while (n < 0 && errno == EINTR);
+        if (n <= 0)
+        {
+            /* stop on error or if read(size) returned 0 */
+            Py_FatalError("Failed to read bytes from /dev/urandom");
+            break;
+        }
+        buffer += n;
+        size -= (Py_ssize_t)n;
+    }
+    close(fd);
+}
+
+/* Read size bytes from /dev/urandom into buffer.
+   Return 0 on success, raise an exception and return -1 on error. */
+static int
+dev_urandom_python(char *buffer, Py_ssize_t size)
+{
+    int fd;
+    Py_ssize_t n;
+
+    if (size <= 0)
+        return 0;
+
+    Py_BEGIN_ALLOW_THREADS
+    fd = open("/dev/urandom", O_RDONLY);
+    Py_END_ALLOW_THREADS
+    if (fd < 0)
+    {
+        PyErr_SetFromErrnoWithFilename(PyExc_OSError, "/dev/urandom");
+        return -1;
+    }
+
+    Py_BEGIN_ALLOW_THREADS
+    do {
+        do {
+            n = read(fd, buffer, (size_t)size);
+        } while (n < 0 && errno == EINTR);
+        if (n <= 0)
+            break;
+        buffer += n;
+        size -= (Py_ssize_t)n;
+    } while (0 < size);
+    Py_END_ALLOW_THREADS
+
+    if (n <= 0)
+    {
+        /* stop on error or if read(size) returned 0 */
+        if (n < 0)
+            PyErr_SetFromErrno(PyExc_OSError);
+        else
+            PyErr_Format(PyExc_RuntimeError,
+                         "Failed to read %zi bytes from /dev/urandom",
+                         size);
+        close(fd);
+        return -1;
+    }
+    close(fd);
+    return 0;
+}
+#endif
+
+/* Fill buffer with pseudo-random bytes generated by a linear congruent
+   generator (LCG):
+
+       x(n+1) = (x(n) * 214013 + 2531011) % 2^32
+
+   Use bits 23..16 of x(n) to generate a byte. */
+static void
+lcg_urandom(unsigned int x0, unsigned char *buffer, size_t size)
+{
+    size_t index;
+    unsigned int x;
+
+    x = x0;
+    for (index=0; index < size; index++) {
+        x *= 214013;
+        x += 2531011;
+        /* modulo 2 ^ (8 * sizeof(int)) */
+        buffer[index] = (x >> 16) & 0xff;
+    }
+}
+
+/* Fill buffer with size pseudo-random bytes, not suitable for cryptographic
+   use, from the operating random number generator (RNG).
+
+   Return 0 on success, raise an exception and return -1 on error. */
+int
+_PyOS_URandom(void *buffer, Py_ssize_t size)
+{
+    if (size < 0) {
+        PyErr_Format(PyExc_ValueError,
+                     "negative argument not allowed");
+        return -1;
+    }
+    if (size == 0)
+        return 0;
+
+#ifdef MS_WINDOWS
+    return win32_urandom((unsigned char *)buffer, size, 1);
+#else
+    return dev_urandom_python((char*)buffer, size);
+#endif
+}
+
+void
+_PyRandom_Init(void)
+{
+    char *env;
+    void *secret = &_Py_HashSecret;
+    Py_ssize_t secret_size = sizeof(_Py_HashSecret);
+
+    if (random_initialized)
+        return;
+    random_initialized = 1;
+
+    /*
+      By default, hash randomization is disabled, and only
+      enabled if PYTHONHASHRANDOMIZATION is set to non-empty
+      or if "-R" is provided at the command line:
+    */
+    if (!Py_HashRandomizationFlag) {
+        /* Disable the randomized hash: */
+        memset(secret, 0, secret_size);
+        return;
+    }
+
+    /*
+      Hash randomization is enabled.  Generate a per-process secret,
+      using PYTHONHASHSEED if provided.
+    */
+
+    env = Py_GETENV("PYTHONHASHSEED");
+    if (env && *env != '\0') {
+        char *endptr = env;
+        unsigned long seed;
+        seed = strtoul(env, &endptr, 10);
+        if (*endptr != '\0'
+            || seed > 4294967295UL
+            || (errno == ERANGE && seed == ULONG_MAX))
+        {
+            Py_FatalError("PYTHONHASHSEED must be an integer "
+                          "in range [0; 4294967295]");
+        }
+        if (seed == 0) {
+            /* disable the randomized hash */
+            memset(secret, 0, secret_size);
+        }
+        else {
+            lcg_urandom(seed, (unsigned char*)secret, secret_size);
+        }
+    }
+    else {
+#ifdef MS_WINDOWS
+        (void)win32_urandom((unsigned char *)secret, secret_size, 0);
+#else /* #ifdef MS_WINDOWS */
+        dev_urandom_noraise((char*)secret, secret_size);
+#endif
+    }
+}
+
diff -r e7706bdaaa0d Python/sysmodule.c
--- a/Python/sysmodule.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Python/sysmodule.c	Mon Feb 06 14:02:24 2012 -0500
@@ -1126,6 +1126,7 @@
     /* {"unbuffered",                   "-u"}, */
     /* {"skip_first",                   "-x"}, */
     {"bytes_warning", "-b"},
+    {"hash_randomization", "-R"},
     {0}
 };
 
@@ -1134,9 +1135,9 @@
     flags__doc__,       /* doc */
     flags_fields,       /* fields */
 #ifdef RISCOS
+    13
+#else
     12
-#else
-    11
 #endif
 };
 
@@ -1169,6 +1170,7 @@
     /* SetFlag(saw_unbuffered_flag); */
     /* SetFlag(skipfirstline); */
     SetFlag(Py_BytesWarningFlag);
+    SetFlag(Py_HashRandomizationFlag);
 #undef SetFlag
 
     if (PyErr_Occurred()) {
-------------- next part --------------
diff -r e7706bdaaa0d Lib/json/__init__.py
--- a/Lib/json/__init__.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/json/__init__.py	Mon Feb 06 14:02:31 2012 -0500
@@ -31,7 +31,9 @@
 Compact encoding::
 
     >>> import json
-    >>> json.dumps([1,2,3,{'4': 5, '6': 7}], separators=(',', ':'))
+    >>> from collections import OrderedDict
+    >>> mydict = OrderedDict([('4', 5), ('6', 7)])
+    >>> json.dumps([1,2,3,mydict], separators=(',', ':'))
     '[1,2,3,{"4":5,"6":7}]'
 
 Pretty printing::
diff -r e7706bdaaa0d Lib/test/mapping_tests.py
--- a/Lib/test/mapping_tests.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/mapping_tests.py	Mon Feb 06 14:02:31 2012 -0500
@@ -14,7 +14,7 @@
     def _reference(self):
         """Return a dictionary of values which are invariant by storage
         in the object under test."""
-        return {1:2, "key1":"value1", "key2":(1,2,3)}
+        return {"1": "2", "key1":"value1", "key2":(1,2,3)}
     def _empty_mapping(self):
         """Return an empty mapping object"""
         return self.type2test()
diff -r e7706bdaaa0d Lib/test/test_descr.py
--- a/Lib/test/test_descr.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_descr.py	Mon Feb 06 14:02:31 2012 -0500
@@ -4300,8 +4300,18 @@
 
     def test_repr(self):
         # Testing dict_proxy.__repr__
+        def sorted_dict_repr(repr_):
+            # Given the repr of a dict, sort the keys
+            assert repr_.startswith('{')
+            assert repr_.endswith('}')
+            kvs = repr_[1:-1].split(', ')
+            return '{' + ', '.join(sorted(kvs)) + '}'
         dict_ = {k: v for k, v in self.C.__dict__.items()}
-        self.assertEqual(repr(self.C.__dict__), 'dict_proxy({!r})'.format(dict_))
+        repr_ = repr(self.C.__dict__)
+        self.assert_(repr_.startswith('dict_proxy('))
+        self.assert_(repr_.endswith(')'))
+        self.assertEqual(sorted_dict_repr(repr_[len('dict_proxy('):-len(')')]),
+                         sorted_dict_repr('{!r}'.format(dict_)))
 
 
 class PTypesLongInitTest(unittest.TestCase):
diff -r e7706bdaaa0d Lib/test/test_set.py
--- a/Lib/test/test_set.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_set.py	Mon Feb 06 14:02:31 2012 -0500
@@ -734,6 +734,17 @@
         if self.repr is not None:
             self.assertEqual(repr(self.set), self.repr)
 
+    def check_repr_against_values(self):
+        text = repr(self.set)
+        self.assertTrue(text.startswith('{'))
+        self.assertTrue(text.endswith('}'))
+
+        result = text[1:-1].split(', ')
+        result.sort()
+        sorted_repr_values = [repr(value) for value in self.values]
+        sorted_repr_values.sort()
+        self.assertEqual(result, sorted_repr_values)
+
     def test_print(self):
         try:
             fo = open(support.TESTFN, "w")
@@ -892,7 +903,9 @@
         self.set    = set(self.values)
         self.dup    = set(self.values)
         self.length = 3
-        self.repr   = "{'a', 'c', 'b'}"
+
+    def test_repr(self):
+        self.check_repr_against_values()
 
 #------------------------------------------------------------------------------
 
@@ -903,7 +916,9 @@
         self.set    = set(self.values)
         self.dup    = set(self.values)
         self.length = 3
-        self.repr   = "{b'a', b'c', b'b'}"
+
+    def test_repr(self):
+        self.check_repr_against_values()
 
 #------------------------------------------------------------------------------
 
@@ -916,11 +931,13 @@
         self.set    = set(self.values)
         self.dup    = set(self.values)
         self.length = 4
-        self.repr   = "{'a', b'a', 'b', b'b'}"
 
     def tearDown(self):
         warnings.filters = self.warning_filters
 
+    def test_repr(self):
+        self.check_repr_against_values()
+
 #==============================================================================
 
 def baditer():
diff -r e7706bdaaa0d Lib/test/test_urllib.py
--- a/Lib/test/test_urllib.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_urllib.py	Mon Feb 06 14:02:31 2012 -0500
@@ -12,6 +12,7 @@
 import sys
 import tempfile
 import warnings
+import collections
 
 def hexescape(char):
     """Escape char as RFC 2396 specifies"""
@@ -840,8 +841,9 @@
         self.assertEqual("a=1&a=2", urllib.parse.urlencode({"a": [1, 2]}, True))
         self.assertEqual("a=None&a=a",
                          urllib.parse.urlencode({"a": [None, "a"]}, True))
+        data = collections.OrderedDict([("a", 1), ("b", 1)])
         self.assertEqual("a=a&a=b",
-                         urllib.parse.urlencode({"a": {"a": 1, "b": 1}}, True))
+                         urllib.parse.urlencode({"a": data}, True))
 
     def test_urlencode_encoding(self):
         # ASCII encoding. Expect %3F with errors="replace'
diff -r e7706bdaaa0d Lib/tkinter/test/test_ttk/test_functions.py
--- a/Lib/tkinter/test/test_ttk/test_functions.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/tkinter/test/test_ttk/test_functions.py	Mon Feb 06 14:02:31 2012 -0500
@@ -143,7 +143,7 @@
             ('a', 'b', 'c')), ("test {a b} c", ()))
         # state spec and options
         self.assertEqual(ttk._format_elemcreate('image', False, 'test',
-            ('a', 'b'), a='x', b='y'), ("test a b", ("-a", "x", "-b", "y")))
+            ('a', 'b'), a='x'), ("test a b", ("-a", "x")))
         # format returned values as a tcl script
         # state spec with multiple states and an option with a multivalue
         self.assertEqual(ttk._format_elemcreate('image', True, 'test',

From report at bugs.python.org  Mon Feb  6 23:32:52 2012
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 06 Feb 2012 22:32:52 +0000
Subject: [issue13578] Add subprocess.iter_output() convenience function
In-Reply-To: <1323579954.88.0.437166836576.issue13578@psf.upfronthosting.co.za>
Message-ID: <1328567572.95.0.969913887655.issue13578@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> This biggest challenge I have noticed so far in exploring 
> this is how to handle timeouts on Windows

I haven't actually looked into it but this somewhat recalls:
http://bugs.python.org/issue1191964
Since issue1191964 is supposed to provide async subprocess I/O I presume Windows timeouts are also involved somewhere in the provided patch/recipe.

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13578>
_______________________________________

From report at bugs.python.org  Mon Feb  6 23:50:21 2012
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Feb 2012 22:50:21 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328568621.94.0.637093930896.issue13882@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Hum, time_decimal-10.patch contains a debug message:

+            print("la")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Mon Feb  6 23:59:17 2012
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Feb 2012 22:59:17 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328569157.92.0.0655353450532.issue13882@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

-    return posix_do_stat(self, args, "O&:stat", STAT, "U:stat", win32_stat_w);
+    return posix_do_stat(self, args, kw, "O&|O:stat", STAT, "U:stat", win32_stat_w);

The second format string should also be updated to "U|O:stat".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Tue Feb  7 00:00:03 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 06 Feb 2012 23:00:03 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <CAFRnB2W-DwsOGFc9uA1A8QE9daoc8RBhMviCCNWsGmcHHu6k5A@mail.gmail.com>
Message-ID: <4F305B6E.4010302@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alex Gaynor wrote:
> There's no need to cover any container types, because if their constituent
> types are securely hashable then they will be as well.  And of course if
> the constituent types are unsecure then they're directly vulnerable.

I wouldn't necessarily take that for granted: since container
types usually calculate their hash based on the hashes of their
elements, it's possible that a clever combination of elements
could lead to a neutralization of the the hash seed used by
the elements, thereby reenabling the original attack on the
unprotected interpreter.

Still, because we have far more vulnerable hashable types out there,
trying to find such an attack doesn't really make practical
sense, so protecting containers is indeed not as urgent :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Tue Feb  7 00:01:17 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Mon, 06 Feb 2012 23:01:17 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>
Message-ID: <1328569277.99.0.274719321531.issue12659@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

I've just updated ?test_support.py? and tested against 'default'
and 'distutils2' (after changing the imports).

Just let me know what has to be changed ...


BTW: in distutils2 I get (not because of this change):

======================================================================
FAIL: test_bad_urls (distutils2.tests.test_pypi_simple.SimpleCrawlerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ci/prog/cpython/distutils2/distutils2/tests/pypi_server.py", line 68, in wrapped
    func(server=server, *args, **kwargs)
  File "/home/ci/prog/cpython/distutils2/distutils2/tests/test_pypi_simple.py", line 93, in test_bad_urls
    self.assertIn(wanted, str(v))
AssertionError: 'nonnumeric port' not found in 'Download error for http://http://svn.pythonpaste.org/Paste/wphp/trunk: [Errno -2] Name or service not known'

----------------------------------------------------------------------
 
Cheers,
francis

----------
Added file: http://bugs.python.org/file24440/test_support_v2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12659>
_______________________________________

From report at bugs.python.org  Tue Feb  7 00:25:03 2012
From: report at bugs.python.org (Samuel Iseli)
Date: Mon, 06 Feb 2012 23:25:03 +0000
Subject: [issue13889] str(float) and round(float) issues with FPU precision
In-Reply-To: <1327676303.66.0.487112802864.issue13889@psf.upfronthosting.co.za>
Message-ID: <1328570703.02.0.55620167014.issue13889@psf.upfronthosting.co.za>


Samuel Iseli <samuel.iseli at gmail.com> added the comment:

Completed the patch by adding the rounding-control bits to the mask (_MCW_RC) and making sure the macros only get defined for MS-VC compiler (#ifdef _MSC_VER).

Ran the tests (python_d -m test.autotest) on win32. Seems OK. The tests that were skipped or failed don't seem to be connected to this patch:
- test_repr failed on trying to import a very long package and module name
- test_popen failed with SyntaxError: unexpected EOF while parsing.

Here's the summary:
323 tests OK.
2 tests failed:
   test_popen test_repr
2 tests altered the execution environment:
   test_distutils test_site
62 tests skipped:
   test_aepack test_al test_applesingle test_bsddb test_bsddb185
   test_bsddb3 test_bz2 test_cd test_cl test_codecmaps_cn
   test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr
   test_codecmaps_tw test_commands test_crypt test_curses test_dbm
   test_dl test_epoll test_fcntl test_fork1 test_gdb test_gdbm
   test_gl test_grp test_imgfile test_ioctl test_kqueue
   test_largefile test_linuxaudiodev test_macos test_macostools
   test_mhlib test_nis test_openpty test_ossaudiodev test_pipes
   test_poll test_posix test_pty test_pwd test_py3kwarn test_readline
   test_resource test_scriptpackages test_smtpnet test_socketserver
   test_sqlite test_ssl test_sunaudiodev test_tcl test_threadsignals
   test_timeout test_tk test_ttk_guionly test_ttk_textonly
   test_urllib2net test_urllibnet test_wait3 test_wait4
   test_zipfile64
10 skips unexpected on win32:
   test_bsddb test_bz2 test_gdb test_readline test_sqlite test_ssl
   test_tcl test_tk test_ttk_guionly test_ttk_textonly
[43048 refs]

----------
Added file: http://bugs.python.org/file24441/120206_set_53bit_precision.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13889>
_______________________________________

From report at bugs.python.org  Tue Feb  7 00:29:50 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Mon, 06 Feb 2012 23:29:50 +0000
Subject: [issue13953] test_packaging: unused test?
In-Reply-To: <1328554740.27.0.167211242761.issue13953@psf.upfronthosting.co.za>
Message-ID: <1328570990.79.0.689234849022.issue13953@psf.upfronthosting.co.za>


Changes by Francisco Mart?n Brugu? <francismb at email.de>:


----------
nosy: +francismb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13953>
_______________________________________

From report at bugs.python.org  Tue Feb  7 01:51:30 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 07 Feb 2012 00:51:30 +0000
Subject: [issue13959] Re-implement parts of imp in pure Python
Message-ID: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

A bunch of code in Python/import.c exists purely for the imp module, but a large chunk of it does not need to be implemented in C but instead can be implemented in Python code.

Once importlib is bootstrapped in then an attempt to scale back the C code should be done by re-implementing parts of imp in pure Python (either in some _imp module or directly in _importlib itself).

----------
components: Library (Lib)
messages: 152800
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Re-implement parts of imp in pure Python
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13959>
_______________________________________

From report at bugs.python.org  Tue Feb  7 01:51:42 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 07 Feb 2012 00:51:42 +0000
Subject: [issue13959] Re-implement parts of imp in pure Python
In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za>
Message-ID: <1328575902.07.0.499178344519.issue13959@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
dependencies: +Replace __import__ w/ importlib.__import__

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13959>
_______________________________________

From report at bugs.python.org  Tue Feb  7 03:06:21 2012
From: report at bugs.python.org (Sung-Yu Chen)
Date: Tue, 07 Feb 2012 02:06:21 +0000
Subject: [issue12970] os.walk() consider some symlinks as dirs instead of
	non-dirs
In-Reply-To: <1315918932.02.0.810529185276.issue12970@psf.upfronthosting.co.za>
Message-ID: <1328580381.67.0.0341515481883.issue12970@psf.upfronthosting.co.za>


Changes by Sung-Yu Chen <eesonyu at gmail.com>:


----------
nosy: +Sung-Yu.Chen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12970>
_______________________________________

From report at bugs.python.org  Tue Feb  7 03:12:08 2012
From: report at bugs.python.org (Meador Inge)
Date: Tue, 07 Feb 2012 02:12:08 +0000
Subject: [issue13370] test_ctypes fails when building python with clang
In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za>
Message-ID: <1328580728.76.0.956474658194.issue13370@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

It turns out that this isn't OS X specific.  I can reproduce the exact same issue by building with clang on a 64-bit Fedora 16 box.

----------
components:  -Macintosh
title: test_ctypes fails on osx 10.7 -> test_ctypes fails when building python with clang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13370>
_______________________________________

From report at bugs.python.org  Tue Feb  7 05:11:25 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 07 Feb 2012 04:11:25 +0000
Subject: [issue13742] Add a key parameter (like sorted) to heapq.merge
In-Reply-To: <1326105342.42.0.0197399269422.issue13742@psf.upfronthosting.co.za>
Message-ID: <1328587885.18.0.589302798095.issue13742@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'll look at this in the next couple of weeks.  Hang tight :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13742>
_______________________________________

From report at bugs.python.org  Tue Feb  7 05:48:35 2012
From: report at bugs.python.org (Ned Deily)
Date: Tue, 07 Feb 2012 04:48:35 +0000
Subject: [issue13590] extension module builds fail with python.org OS X
	installers on OS X 10.7 and 10.6 with Xcode 4.2
In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za>
Message-ID: <1328590115.3.0.997035143281.issue13590@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

When building and installing C extension modules, distutils attempts to use the same compiler and some compiler options as Python itself was built with.  For the current (3.2.2 and 2.7.2) 64-bit/32-bit python installers, the standard Apple-supplied gcc-4.2 in Xcode 3.2.x on OS X 10.6 was used.  As of Xcode 4.2, now standard for OS X 10.7 and optional for OS X 10.6, Apple no longer ships gcc-4.2 in Xcode, in favor of clang and the transitional llvm-gcc.  Moving the entire Python build to another compiler is a major undertaking, requiring careful testing, which is underway.  A compiler change may well be deemed too risky for a bug-fix release.

In any case, we can no longer assume that the same build compiler will be available on most user systems.  While it is possible for the user to manually override the distutils defaults by setting the CC and LDSHARED environment variables properly, setting the latter is tedious.  For example, to manually override to clang, the following is currently needed:

  CC=clang
  LDSHARED='clang -bundle -undefined dynamic_lookup \
    -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -g'
  python setup.py ...

Attached is a patch that attempts to "do the right thing" for OS X.  First, if the default build compiler is gcc-4.2 and the compiler has not been explicitly overridden by defining CC, distutils will check for the presence of gcc-4.2 on the default path.  If gcc-4.2 is not found and if clang is found, it will automatically substitute clang as the build compiler.  Second, if CC is used to override the compiler selection but LDSHARED is not defined, distutils will substitute the CC value into the default LDSHARED value.  This allows simple one-line compiler overrides, like:

  CC=llvm-gcc python setup.py ...

To minimize the risk of unintended side effects, these changes would apply to OS X only.

I propose applying this patch to 3.2 (for 3.2.3) and 2.7 (for 2.7.3) as well as provisionally to default for 3.3; a second patch will be needed with similar changes to packaging.  After the evaluation of compiler alternatives is complete and we decide what to do for 3.3, this approach might change.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file24442/issue13590_distutils.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13590>
_______________________________________

From report at bugs.python.org  Tue Feb  7 06:00:24 2012
From: report at bugs.python.org (Ned Deily)
Date: Tue, 07 Feb 2012 05:00:24 +0000
Subject: [issue13370] test_ctypes fails when building python with clang
In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za>
Message-ID: <1328590824.62.0.335743557545.issue13370@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the analysis, Meador.  So perhaps as a temporary workaround, we could tweak setup.py to set -O0 for building ctypes with clang?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13370>
_______________________________________

From report at bugs.python.org  Tue Feb  7 09:44:03 2012
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 07 Feb 2012 08:44:03 +0000
Subject: [issue13742] Add a key parameter (like sorted) to heapq.merge
In-Reply-To: <1326105342.42.0.0197399269422.issue13742@psf.upfronthosting.co.za>
Message-ID: <1328604243.33.0.246259917351.issue13742@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/issue13742>
_______________________________________

From report at bugs.python.org  Tue Feb  7 12:54:27 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 07 Feb 2012 11:54:27 +0000
Subject: [issue12970] os.walk() consider some symlinks as dirs instead of
	non-dirs
In-Reply-To: <1315918932.02.0.810529185276.issue12970@psf.upfronthosting.co.za>
Message-ID: <1328615667.67.0.554991283436.issue12970@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This behaviour came up recently when implementing os.fwalk() [1]. There are problems with all 3 possible approaches (list as dirs, list as files, don't list at all) when followlinks is False. Since all alternatives are potentially surprising, the current behaviour wins by default (as people will already have written their code to cope with that behaviour and there's no net gain in changing the default, since the desired treatment of such links will vary according to the task at hand).

As a result, I'm converting this to a pure documentation issue - the os.walk() docs should definitely mention this subtlety. The behaviour won't be changing, though.

[1] http://bugs.python.org/issue13734,#msg151077

----------
components:  -Library (Lib)
nosy: +ncoghlan
type: behavior -> enhancement
versions:  -Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12970>
_______________________________________

From report at bugs.python.org  Tue Feb  7 12:56:36 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 07 Feb 2012 11:56:36 +0000
Subject: [issue13960] Handling of broken comments in HTMLParser
Message-ID: <1328615796.36.0.0693404155355.issue13960@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

html.parser fails to handle the following invalid comments:
<! foo >
<! bar -->
<! -- baz -->
The attached patch follows the HTML5 specs [0], and parses them as "bogus comments".  Currently the patch fixes the problem only when strict=False, but it might be better to make this the default behavior and apply it to 2.7 too.

[0]: http://www.w3.org/TR/html5/tokenization.html#bogus-comment-state

----------
components: Library (Lib)
files: issue13960.diff
keywords: patch
messages: 152806
nosy: eric.araujo, ezio.melotti
priority: normal
severity: normal
stage: patch review
status: open
title: Handling of broken comments in HTMLParser
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24443/issue13960.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13960>
_______________________________________

From report at bugs.python.org  Tue Feb  7 12:57:23 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 07 Feb 2012 11:57:23 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1328615843.12.0.0685887250655.issue6210@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Tue Feb  7 13:38:11 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 07 Feb 2012 12:38:11 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1328618291.45.0.645946839936.issue13609@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

All right, I've found some time to grep conversation related to COLUMNS/ROWS environment/shell variable.

+1 for low level system wrapper to get current stdout console size
-1 on COLUMN/ROWS "business logic"


My user story 001:
I need exact values of my console and don't want them to be overridden by environment/shell variables. 
-- or --
When troubleshooting problems with console width on user side and don't want this feature to implicitly depend on some variables in user environment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Tue Feb  7 14:09:34 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Feb 2012 13:09:34 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1328618291.45.0.645946839936.issue13609@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbHX9g79VroP0yue8agy_3rQT_2s33QnKPi7n2wZWwuqA@mail.gmail.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> +1 for low level system wrapper to get current stdout console size

So use os.get_terminal_size()

> -1 on COLUMN/ROWS "business logic"

So don't use shutil.get_terminal_size(), but it looks like their is a
use case for this feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Tue Feb  7 14:52:45 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 07 Feb 2012 13:52:45 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1328622765.65.0.15329024178.issue6210@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I started work on integrating this into 3.3 this evening, but ran into too many issues to finish it.

Problems found and fixed:
- traceback.py displayed the wrong exception (test added and impl fixed)

Additional changes:
- eliminated duplicate code paths for __cause__ validation in ceval.c and exceptions.c (latter now exposes a private C API for ceval to use)
- documented that Ellipsis may be used as a sentinel when None is not appropriate
- broke up the long test case in test_exceptions a bit
- started a placeholder section in What's New

Remaining problems:
- default sys.excepthook implementation currently does the wrong thing
- needs a test for the pythonrun display logic (test_cmd_line_script would be the appropriate place)
- testCauseSyntax test should probably be in test_raise, not test_exceptions

Off the top of my head, I'm not even sure where the default sys.excepthook impl even *lives*. Making that behave itself is the major blocker at this point, though (followed by a test for the pythonrun change - given the problem in traceback.py, it may be that it's this code that's buggy and it's affecting the interactive interpreter as well).

(I deliberately haven't added a NEWS entry yet - that's best left until last, since it's a major cause of merge conflicts otherwise)

----------
Added file: http://bugs.python.org/file24444/pep409_interactive_broken.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Tue Feb  7 15:26:36 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 07 Feb 2012 14:26:36 +0000
Subject: [issue13961] Have importlib use os.replace()
Message-ID: <1328624796.15.0.577971130856.issue13961@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The new os.replace() function should be used by importlib.

----------
components: Library (Lib)
messages: 152810
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Have importlib use os.replace()
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13961>
_______________________________________

From report at bugs.python.org  Tue Feb  7 16:41:36 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 07 Feb 2012 15:41:36 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <4F305B6E.4010302@egenix.com>
Message-ID: <1328629255.3741.132.camel@surprise>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

On Mon, 2012-02-06 at 23:00 +0000, Marc-Andre Lemburg wrote:
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
> 
> Alex Gaynor wrote:
> > There's no need to cover any container types, because if their constituent
> > types are securely hashable then they will be as well.  And of course if
> > the constituent types are unsecure then they're directly vulnerable.
> 
> I wouldn't necessarily take that for granted: since container
> types usually calculate their hash based on the hashes of their
> elements, it's possible that a clever combination of elements
> could lead to a neutralization of the the hash seed used by
> the elements, thereby reenabling the original attack on the
> unprotected interpreter.
> 
> Still, because we have far more vulnerable hashable types out there,
> trying to find such an attack doesn't really make practical
> sense, so protecting containers is indeed not as urgent :-)

FWIW, I'm still awaiting review of my patches.  I don't believe
Marc-Andre's concerns are a sufficient rebuttal to the approach I've
taken.

If anyone is aware of an attack via numeric hashing that's actually
possible, please let me know (privately).  I believe only specific apps
could be affected, and I'm not aware of any such specific apps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Tue Feb  7 17:16:27 2012
From: report at bugs.python.org (Ray)
Date: Tue, 07 Feb 2012 16:16:27 +0000
Subject: [issue13962] multiple lib and include directories on Linux
Message-ID: <1328631387.63.0.77049382306.issue13962@psf.upfronthosting.co.za>


New submission from Ray <rpqpro at hotmail.com>:

I'm opening a new ticket based on ticket 13511 (http://bugs.python.org/issue13511) since the last one was closed.  Read ronaldoussoren's post in Ticket 13511 in case you're still confused. 

There is no way to specify multiple lib and include directories on Linux when installing Python 2.7; other versions of Python may be affected.

----------
assignee: tarek
components: Build, Distutils, Installation
messages: 152812
nosy: eric.araujo, rpq, tarek
priority: normal
severity: normal
status: open
title: multiple lib and include directories on Linux
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13962>
_______________________________________

From report at bugs.python.org  Tue Feb  7 17:24:38 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 07 Feb 2012 16:24:38 +0000
Subject: [issue13963] dev guide has no mention of mechanics of patch review
Message-ID: <1328631878.8.0.85188160352.issue13963@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

I've been waiting for patch review of my work on http://bugs.python.org/issue13703 only to discover that people *have* been reviewing it.

It turns out that next to some of the patches in the issue tracker there's a "review" link, which takes me to http://bugs.python.org/review/13703/show and there's a whole second conversation going on about the issue there.  I haven't been getting any emails about it.

I've been looking through http://docs.python.org/devguide but I can't see any mention of the mechanics of patch review, or that this secondary site exists.  
Clearly I missed something big, but was it actually documented anywhere?

http://docs.python.org/devguide/patch.html mentions uploading patches for review, and talks about an iterative process of commenting and refining a patch, but when I read it, I assumed it was referring to discussion within the issue, rather than on this secondary site.

Some questions:
  * Do all patches go into this review site, or do I have to do something extra to get them to land there?
  * I have patches for both 2.6 and 3.1 - are they kept separate, or do they affect each other's "delta from patch set"?
  * Is there a way to enable notifications, e.g. for me to receive emails when someone comments on my patch?  or to put a comment into the *issue* noting that someone commented on the patch?

Thanks

----------
components: Devguide
messages: 152813
nosy: dmalcolm, ezio.melotti
priority: normal
severity: normal
status: open
title: dev guide has no mention of mechanics of patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13963>
_______________________________________

From report at bugs.python.org  Tue Feb  7 17:39:42 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 07 Feb 2012 16:39:42 +0000
Subject: [issue13963] dev guide has no mention of mechanics of patch review
In-Reply-To: <1328631878.8.0.85188160352.issue13963@psf.upfronthosting.co.za>
Message-ID: <1328632782.12.0.416944992649.issue13963@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13963>
_______________________________________

From report at bugs.python.org  Tue Feb  7 17:42:03 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Tue, 07 Feb 2012 16:42:03 +0000
Subject: [issue13963] dev guide has no mention of mechanics of patch review
In-Reply-To: <1328631878.8.0.85188160352.issue13963@psf.upfronthosting.co.za>
Message-ID: <1328632923.89.0.464703466024.issue13963@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13963>
_______________________________________

From report at bugs.python.org  Tue Feb  7 17:48:31 2012
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Tue, 07 Feb 2012 16:48:31 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1328633311.5.0.520798952977.issue6210@psf.upfronthosting.co.za>


Changes by Raghuram Devarakonda <draghuram at gmail.com>:


----------
nosy:  -draghuram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Tue Feb  7 19:28:38 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 07 Feb 2012 18:28:38 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1328566001.4.0.276174545077.issue2377@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W4aBjHhBEzfZjJBR8fbaDMqRMTnDqRM-v136hapYMYGoA@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Mon, Feb 6, 2012 at 17:06, STINNER Victor <report at bugs.python.org> wrote:

>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
> Is there a benchmark for import? How slow is importlib? :)
>

importlib.test.benchmark

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Tue Feb  7 22:19:59 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 07 Feb 2012 21:19:59 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1328649599.14.0.893137969109.issue10287@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


----------
nosy: +hynek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10287>
_______________________________________

From report at bugs.python.org  Tue Feb  7 22:45:06 2012
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 07 Feb 2012 21:45:06 +0000
Subject: [issue13962] multiple lib and include directories on Linux
In-Reply-To: <1328631387.63.0.77049382306.issue13962@psf.upfronthosting.co.za>
Message-ID: <1328651106.14.0.234190540745.issue13962@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

hmm,  issue 13511 is perfectly closed as invalid.
Ray you misunderstood  meaning on configure flags --XXXdir.
You properly found that LDFLAGS is what is required bug correct for headers is CPPFLAGS . 
Is ./configure --help not clear for you ?

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13962>
_______________________________________

From report at bugs.python.org  Tue Feb  7 23:29:16 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 07 Feb 2012 22:29:16 +0000
Subject: [issue13846] Add time.monotonic() function
In-Reply-To: <1327364549.64.0.960699645726.issue13846@psf.upfronthosting.co.za>
Message-ID: <E1RutXH-000183-AM@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 376ce937823c by Victor Stinner in branch 'default':
Issue #13846: Add time.monotonic(), monotonic clock.
http://hg.python.org/cpython/rev/376ce937823c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13846>
_______________________________________

From report at bugs.python.org  Tue Feb  7 23:30:30 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Feb 2012 22:30:30 +0000
Subject: [issue13846] Add time.monotonic() function
In-Reply-To: <1327364549.64.0.960699645726.issue13846@psf.upfronthosting.co.za>
Message-ID: <1328653830.82.0.424640905997.issue13846@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/issue13846>
_______________________________________

From report at bugs.python.org  Tue Feb  7 23:40:31 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 07 Feb 2012 22:40:31 +0000
Subject: [issue13845] Use GetSystemTimeAsFileTime() to get a resolution of 100
	ns on Windows
In-Reply-To: <1327363365.73.0.00740710968562.issue13845@psf.upfronthosting.co.za>
Message-ID: <E1RutiA-0002dr-E8@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset bee7943d38c6 by Victor Stinner in branch 'default':
Issue #13845: time.time() now uses GetSystemTimeAsFileTime() instead of ftime()
http://hg.python.org/cpython/rev/bee7943d38c6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13845>
_______________________________________

From report at bugs.python.org  Tue Feb  7 23:41:16 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Feb 2012 22:41:16 +0000
Subject: [issue13845] Use GetSystemTimeAsFileTime() to get a resolution of 100
	ns on Windows
In-Reply-To: <1327363365.73.0.00740710968562.issue13845@psf.upfronthosting.co.za>
Message-ID: <1328654476.09.0.288769189978.issue13845@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/issue13845>
_______________________________________

From report at bugs.python.org  Wed Feb  8 00:27:12 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Feb 2012 23:27:12 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328657232.83.0.0381968475771.issue13882@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Updated patch (version 11).

----------
Added file: http://bugs.python.org/file24445/time_decimal-11.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Wed Feb  8 00:27:21 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Feb 2012 23:27:21 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328657241.68.0.446613687849.issue13882@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file24404/time_decimal-9.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Wed Feb  8 00:27:22 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Feb 2012 23:27:22 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328657242.91.0.531695947474.issue13882@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file24407/time_decimal-10.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Wed Feb  8 00:38:35 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Feb 2012 23:38:35 +0000
Subject: [issue13619] Add a new codec: "locale", the current locale encoding
In-Reply-To: <1324102425.92.0.741478756596.issue13619@psf.upfronthosting.co.za>
Message-ID: <1328657915.99.0.0970081075648.issue13619@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> + encoding = locale.getpreferredencoding()
> It should be locale.getpreferredencoding(False).

Fixed in patch version 3.

----------
Added file: http://bugs.python.org/file24446/locale_encoding-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13619>
_______________________________________

From report at bugs.python.org  Wed Feb  8 00:38:43 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Feb 2012 23:38:43 +0000
Subject: [issue13619] Add a new codec: "locale", the current locale encoding
In-Reply-To: <1324102425.92.0.741478756596.issue13619@psf.upfronthosting.co.za>
Message-ID: <1328657923.57.0.20227139712.issue13619@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file23985/locale_encoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13619>
_______________________________________

From report at bugs.python.org  Wed Feb  8 00:38:44 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Feb 2012 23:38:44 +0000
Subject: [issue13619] Add a new codec: "locale", the current locale encoding
In-Reply-To: <1324102425.92.0.741478756596.issue13619@psf.upfronthosting.co.za>
Message-ID: <1328657924.71.0.594221717053.issue13619@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file23987/locale_encoding-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13619>
_______________________________________

From report at bugs.python.org  Wed Feb  8 00:42:22 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Feb 2012 23:42:22 +0000
Subject: [issue13550] Rewrite logging hack of the threading module
In-Reply-To: <1323297626.55.0.00727033353184.issue13550@psf.upfronthosting.co.za>
Message-ID: <1328658142.17.0.520554837155.issue13550@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Alright, Nick agreed on python-dev to remove the logging hack.

You mean removing complelty debug logging from the threading module? Or just to simplify the code to decide if we should log or not?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13550>
_______________________________________

From report at bugs.python.org  Wed Feb  8 00:44:29 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Feb 2012 23:44:29 +0000
Subject: [issue13286] PEP 3151 breaks backward compatibility: it should be
	documented
In-Reply-To: <1319811530.69.0.689775391155.issue13286@psf.upfronthosting.co.za>
Message-ID: <1328658269.12.0.886836053352.issue13286@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The code was fixed in importlib. I don't think that this borderline case should be documented anywhere, so I close this issue.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13286>
_______________________________________

From report at bugs.python.org  Wed Feb  8 01:10:52 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Feb 2012 00:10:52 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1328659852.26.0.12652325903.issue2377@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

bench_startup.py: short script to compute the best startup time (I wrote the original script for the hash collision issue, #13703). Result on my PC:
 - original: 22.2 ms
 - importlib: 27.9 ms

So importlib adds an overhead of 25.7% in startup time.

----------
Added file: http://bugs.python.org/file24447/bench_startup.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Wed Feb  8 02:05:11 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Feb 2012 01:05:11 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328663111.25.0.00920615388269.issue13882@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

os.stat().st_birthtime should depend on the timestamp argument.

A timestamp optional argument should also be added to os.wait3() and os.wait4() for the utime and stime fields of the rusage tuple.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Wed Feb  8 02:09:25 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 08 Feb 2012 01:09:25 +0000
Subject: [issue13550] Rewrite logging hack of the threading module
In-Reply-To: <1323297626.55.0.00727033353184.issue13550@psf.upfronthosting.co.za>
Message-ID: <1328663365.51.0.985666537514.issue13550@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I believe Charles-Fran?ois was referring to this message:
http://mail.python.org/pipermail/python-dev/2012-January/115372.html

We shouldn't be encumbering threading *all the time* with stuff that "might be useful sometimes". Adding selective output to help debug problems can be handled with Thread subclasses, or even temporarily running with a modified threading.py (for people hacking on the stdlib itself).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13550>
_______________________________________

From report at bugs.python.org  Wed Feb  8 02:19:54 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Feb 2012 01:19:54 +0000
Subject: [issue13964] os.utimensat() and os.futimes() should accept Decimal,
	drop os.futimens()
Message-ID: <1328663994.2.0.189878263913.issue13964@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Python 3.3 has 4 new functions to set the access and modification time of a file (only os.utime() was already present in Python 3.2). New functions taking timestamp with a nanonsecond resolution use a tuple of int because the float type doesn't support nanosecond resolution. Thanks to the PEP 410, we can simplify the API to use a simple number (int, float or Decimal) instead of a tuple of 2 integers.

Current API:

- futimes(fd[, (atime, mtime)]): 1 argument for timestamps
- lutimes(path[, (atime, mtime)]): 1 argument for timestamps
- utime(path[, (atime, mtime)]): 1 argument for timestamps

- futimens(fd[, (atime_sec, atime_nsec), (mtime_sec, mtime_nsec)]): 2 arguments for timestamps
- utimensat(dirfd, path[, atime=(atime_sec, atime_nsec), mtime=(mtime_sec, mtime_nsec), flags=0]): 2 arguments for timestamps

I propose to:

- support Decimal type in all functions: avoid conversion to float to not lose precision
- remove os.futimens(): os.futimes() does already use futimens() if the function is present (and Decimal can be used to get nanosecond resolution)
- change os.utimensat() API to: os.utimensat(dirfd, path[, (atime, mtime), flags=0])

----------
components: Library (Lib)
messages: 152825
nosy: haypo, ncoghlan
priority: normal
severity: normal
status: open
title: os.utimensat() and os.futimes() should accept Decimal, drop os.futimens()
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13964>
_______________________________________

From report at bugs.python.org  Wed Feb  8 02:20:20 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Feb 2012 01:20:20 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328664020.73.0.700953344614.issue13882@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I created the issue #13964 to cleanup the API of os.*utime*() functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Wed Feb  8 02:32:46 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 08 Feb 2012 01:32:46 +0000
Subject: [issue13964] os.utimensat() and os.futimes() should accept Decimal,
	drop os.futimens()
In-Reply-To: <1328663994.2.0.189878263913.issue13964@psf.upfronthosting.co.za>
Message-ID: <1328664766.85.0.166547552486.issue13964@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/issue13964>
_______________________________________

From report at bugs.python.org  Wed Feb  8 02:57:16 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 08 Feb 2012 01:57:16 +0000
Subject: [issue13965] Windows 64-bit installer actually installing a 32-bit
	version
Message-ID: <1328666235.95.0.56390698095.issue13965@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

On the downloader page, http://www.python.org/download/releases/2.7.2/ there is an entry "?Windows X86-64 MSI Installer" that links to http://www.python.org/ftp/python/2.7.2/python-2.7.2.amd64.msi

Running this installer succeeds and show messages that a 64-bit version of Python is being installed; however, running Python shows that only a 32-bit version is being run despite a welcome message stating that a 64-bit version is being run:


C:\Python27>python
Python 2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit (AMD64)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.maxint
2147483647

----------
assignee: loewis
components: Installation
messages: 152827
nosy: loewis, rhettinger
priority: normal
severity: normal
status: open
title: Windows 64-bit installer actually installing a 32-bit version
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13965>
_______________________________________

From report at bugs.python.org  Wed Feb  8 03:00:43 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 08 Feb 2012 02:00:43 +0000
Subject: [issue13964] os.utimensat() and os.futimes() should accept Decimal,
	drop os.futimens()
In-Reply-To: <1328663994.2.0.189878263913.issue13964@psf.upfronthosting.co.za>
Message-ID: <E1Ruwpu-0000O5-36@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d297f9b10c64 by Victor Stinner in branch 'default':
Issue #13964: Write tests for new os.*utime*() functions
http://hg.python.org/cpython/rev/d297f9b10c64

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13964>
_______________________________________

From report at bugs.python.org  Wed Feb  8 03:02:32 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Feb 2012 02:02:32 +0000
Subject: [issue13964] os.utimensat() and os.futimes() should accept Decimal,
	drop os.futimens()
In-Reply-To: <1328663994.2.0.189878263913.issue13964@psf.upfronthosting.co.za>
Message-ID: <1328666552.58.0.310424918877.issue13964@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Current API:

Oh, I forgot:
- futimesat(dirfd, path[, (atime, mtime)])

This API looks fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13964>
_______________________________________

From report at bugs.python.org  Wed Feb  8 03:06:57 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 08 Feb 2012 02:06:57 +0000
Subject: [issue13964] os.utimensat() and os.futimes() should accept Decimal,
	drop os.futimens()
In-Reply-To: <1328663994.2.0.189878263913.issue13964@psf.upfronthosting.co.za>
Message-ID: <E1Ruwvw-0001SA-4n@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c6e9c4d18b36 by Victor Stinner in branch 'default':
Issue #13964: Test also os.futimesat()
http://hg.python.org/cpython/rev/c6e9c4d18b36

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13964>
_______________________________________

From report at bugs.python.org  Wed Feb  8 03:16:07 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 08 Feb 2012 02:16:07 +0000
Subject: [issue13964] os.utimensat() and os.futimes() should accept Decimal,
	drop os.futimens()
In-Reply-To: <1328663994.2.0.189878263913.issue13964@psf.upfronthosting.co.za>
Message-ID: <1328667367.17.0.418860880232.issue13964@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I suggest to support the following functions:
futimes(fd, (atime, mtime), flags=0)
utimes(path, (atime, mtime), flags=0)
utimesat(dirfd, path, (atime, mtime), flags=0)

And deprecate other functions already present in 3.2.
flags argument of utimes*() would specify e.g. if symlinks should be dereferenced, so lutime*() wouldn't be needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13964>
_______________________________________

From report at bugs.python.org  Wed Feb  8 03:35:53 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 08 Feb 2012 02:35:53 +0000
Subject: [issue13964] os.utimensat() and os.futimes() should accept Decimal,
	drop os.futimens()
In-Reply-To: <1328663994.2.0.189878263913.issue13964@psf.upfronthosting.co.za>
Message-ID: <E1RuxNw-00075Q-J7@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 478fb4869c99 by Victor Stinner in branch 'default':
Issue #13964: Split os.*utime*() subsecond tests into multiple tests to help
http://hg.python.org/cpython/rev/478fb4869c99

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13964>
_______________________________________

From report at bugs.python.org  Wed Feb  8 04:09:15 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 08 Feb 2012 03:09:15 +0000
Subject: [issue13964] os.utimensat() and os.futimes() should accept Decimal,
	drop os.futimens()
In-Reply-To: <1328663994.2.0.189878263913.issue13964@psf.upfronthosting.co.za>
Message-ID: <E1RuxuD-0003nE-Gx@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 58bd6a58365d by Victor Stinner in branch 'default':
Issue #13964: Skip os.*utime*() tests if os.stat() doesn't support timestamp
http://hg.python.org/cpython/rev/58bd6a58365d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13964>
_______________________________________

From report at bugs.python.org  Wed Feb  8 04:14:50 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Feb 2012 03:14:50 +0000
Subject: [issue13964] os.utimensat() and os.futimes() should accept Decimal,
	drop os.futimens()
In-Reply-To: <1328663994.2.0.189878263913.issue13964@psf.upfronthosting.co.za>
Message-ID: <1328670890.75.0.432168037319.issue13964@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> New changeset 478fb4869c99 by Victor Stinner in branch 'default':
> Issue #13964: Split os.*utime*() subsecond tests into multiple tests...

Oops, I also commited my change on extract_time() by mistake. But it is not completly a mistake: it was the goal of my patch serie :-)

This commit changes two things on extract_time().

 - always use nanoseconds: if we need microseconds, divide by 1000
 - use (long)(fmod()*1e9) to get nanoseconds instead of the previous code, I'm not sure that this change is correct

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13964>
_______________________________________

From report at bugs.python.org  Wed Feb  8 04:18:33 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Feb 2012 03:18:33 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328671113.5.0.300274283022.issue13882@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

fill_time() should use denominator=1 if the OS doesn't support timestamp with a subsecond resolution. See also issue #13964.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Wed Feb  8 04:42:15 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 08 Feb 2012 03:42:15 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1328672535.95.0.338904305328.issue11379@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

IMHO this wording proposed by Stefan:

"""
[[Note: The xml.dom.minidom module provides an implementation of the W3C-DOM whose API is similar to that in other programming languages. Users who are unfamiliar with the W3C-DOM interface or who would like to write less code for processing XML files should consider using the xml.etree.ElementTree module instead.]]
"""

Sounds very reasonable. Perhaps something about a more Pythonic API can also be added there, in addition to "to write less code".

Any objections?

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Wed Feb  8 04:44:33 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 08 Feb 2012 03:44:33 +0000
Subject: [issue13782] xml.etree.ElementTree: Element.append doesn't type-check
	its argument
In-Reply-To: <1326502453.32.0.206779556991.issue13782@psf.upfronthosting.co.za>
Message-ID: <1328672673.59.0.928936384691.issue13782@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/issue13782>
_______________________________________

From report at bugs.python.org  Wed Feb  8 04:45:46 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 08 Feb 2012 03:45:46 +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: <1328672746.46.0.267766956951.issue9257@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

At this point, 3.1 won't be fixed with such changes any longer.

Is this fixed in 3.2/3.3?

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9257>
_______________________________________

From report at bugs.python.org  Wed Feb  8 04:57:38 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Feb 2012 03:57:38 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328673458.83.0.989048606192.issue13882@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch version 12:

 * os.stat().st_birthtime uses also the timestamp argument
 * Add an optional timestamp argument to os.wait3() and os.wait4(): change type of utime and stime attributes of the resource usage
 * os.stat() changes the timestamp resolution depending if nanosecond resolution is available or not

I realized that resource.getrusage() should also be modified. I will maybe do that in another version of the patch, or maybe change resource usage in another patch.

----------
Added file: http://bugs.python.org/file24448/time_decimal-12.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Wed Feb  8 05:14:17 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 08 Feb 2012 04:14:17 +0000
Subject: [issue13964] os.utimensat() and os.futimes() should accept Decimal,
	drop os.futimens()
In-Reply-To: <1328663994.2.0.189878263913.issue13964@psf.upfronthosting.co.za>
Message-ID: <1328674457.77.0.659109121375.issue13964@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/issue13964>
_______________________________________

From report at bugs.python.org  Wed Feb  8 08:49:28 2012
From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgQXR0aWxhIFTDs3Ro?=)
Date: Wed, 08 Feb 2012 07:49:28 +0000
Subject: [issue13966] Add disable_interspersed_args() to
	argparse.ArgumentParser
Message-ID: <1328687368.18.0.265955669963.issue13966@psf.upfronthosting.co.za>


New submission from L?szl? Attila T?th <laszlo.attila.toth at gmail.com>:

If someone ports his code from optparse to argparse, there is a limit, that options and non-options can be mixed by default, and this behaviour cannot be disabled easily, an extra '--' argument is required in the command line.

In some cases it is much prettier to explicitly disable this, as was available in the deprecated optparse module.

I attach a patch that does this, adds disable_interspersed_args() to argparse.ArgumentParser.

----------
components: Library (Lib)
files: argparse.patch
keywords: patch
messages: 152839
nosy: Laszlo.Attila.Toth
priority: normal
severity: normal
status: open
title: Add disable_interspersed_args() to argparse.ArgumentParser
versions: Python 2.7
Added file: http://bugs.python.org/file24449/argparse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13966>
_______________________________________

From report at bugs.python.org  Wed Feb  8 10:04:55 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 08 Feb 2012 09:04:55 +0000
Subject: [issue13967] also test for an empty pathname
Message-ID: <1328691895.76.0.461063464523.issue13967@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

increases coverage by one line: http://hg.python.org/cpython/file/58bd6a58365d/Lib/packaging/util.py#l110

----------
assignee: tarek
components: Distutils2
files: test-for-empty-string.patch
keywords: patch
messages: 152840
nosy: alexis, eric.araujo, tarek, tshepang
priority: normal
severity: normal
status: open
title: also test for an empty pathname
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file24450/test-for-empty-string.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13967>
_______________________________________

From report at bugs.python.org  Wed Feb  8 10:13:25 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 08 Feb 2012 09:13:25 +0000
Subject: [issue13782] xml.etree.ElementTree: Element.append doesn't type-check
	its argument
In-Reply-To: <1326502453.32.0.206779556991.issue13782@psf.upfronthosting.co.za>
Message-ID: <1328692405.2.0.423888986517.issue13782@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13782>
_______________________________________

From report at bugs.python.org  Wed Feb  8 10:22:52 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 08 Feb 2012 09:22:52 +0000
Subject: [issue13965] Windows 64-bit installer actually installing a 32-bit
	version
In-Reply-To: <1328666235.95.0.56390698095.issue13965@psf.upfronthosting.co.za>
Message-ID: <1328692972.08.0.10681296641.issue13965@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

64-bit Windows (or at least Visual C++) uses the LLP64 model, so a long
is 32 bits wide (the only 64-bit integer type being long long) - see
<http://en.wikipedia.org/wiki/64-bit#64-bit_data_models>

Since Python's int is documented as being implemented on top of C's long,
this behaviour appears to be correct (if surprising).

----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13965>
_______________________________________

From report at bugs.python.org  Wed Feb  8 10:27:53 2012
From: report at bugs.python.org (Pauli Rikula)
Date: Wed, 08 Feb 2012 09:27:53 +0000
Subject: [issue9041] raised exception is misleading
In-Reply-To: <1314714480.92.0.730814291982.issue9041@psf.upfronthosting.co.za>
Message-ID: <CANYHms1W8F6-mk89AYe+H8CjQ9OD84fcqNvwONUqOBCO3hKixQ@mail.gmail.com>


Pauli Rikula <pauli.rikula at gmail.com> added the comment:

Could we overcome these issues by some kind of exception inheritance?

On Tue, Aug 30, 2011 at 5:28 PM, Meador Inge <report at bugs.python.org> wrote:
>
> Meador Inge <meadori at gmail.com> added the comment:
>
> That is a good question. ?While it is true that errors other than 'PyExc_OverflowError', will be mapped onto a 'TypeError' I don't think that is a bad thing. ?Any errors that come out of 'PyFloat_AsDouble' should be handled on a case-by-case basis and not blindly passed back out the call chain. ?Otherwise, we may end up passing back errors (which are who knows what) that make sense for a caller of 'PyFloat_AsDouble', but not for callers of 'g_set'.
>
> Also, the interface would become variable, meaning that whenever 'PyFloat_AsDouble' introduces new exceptions, then this code would too, which would lead to a somewhat unpredictable interface for callers of 'g_set'.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue9041>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9041>
_______________________________________

From report at bugs.python.org  Wed Feb  8 11:30:08 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 08 Feb 2012 10:30:08 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1328697008.19.0.632164433056.issue11379@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Wed Feb  8 12:22:26 2012
From: report at bugs.python.org (Yuval Greenfield)
Date: Wed, 08 Feb 2012 11:22:26 +0000
Subject: [issue13968] Add a recursive function to the glob package
Message-ID: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>


New submission from Yuval Greenfield <ubershmekel at gmail.com>:

This is a feature I've wanted to use in too many times to remember. I've made a patch with an implementation, docs and a test. I've named the function rglob and tried to stay within the conventions of the glob package.

----------
components: Library (Lib)
files: rglob.patch
keywords: patch
messages: 152843
nosy: ubershmekel
priority: normal
severity: normal
status: open
title: Add a recursive function to the glob package
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file24451/rglob.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 12:26:24 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 08 Feb 2012 11:26:24 +0000
Subject: [issue13965] Windows 64-bit installer actually installing a 32-bit
	version
In-Reply-To: <1328666235.95.0.56390698095.issue13965@psf.upfronthosting.co.za>
Message-ID: <1328700384.5.0.343381357074.issue13965@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

IIRC sys.maxsize was added for this reason. This one should show a 64bit value.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13965>
_______________________________________

From report at bugs.python.org  Wed Feb  8 12:53:46 2012
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 08 Feb 2012 11:53:46 +0000
Subject: [issue13968] Add a recursive function to the glob package
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328702026.71.0.0375133627687.issue13968@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/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 12:56:38 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 08 Feb 2012 11:56:38 +0000
Subject: [issue13969] path name must always be string
Message-ID: <1328702198.23.0.695483013492.issue13969@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

I was writing a test that could return True for "if not pathname" (http://hg.python.org/cpython/file/58bd6a58365d/Lib/packaging/util.py#l109), and included all values I know that could return a False value, but then I realised that the only value we should check against is an empty string... I don't think any other type is applicable.

I left None as a valid type, otherwise some other test (test_command_install_dist.py) fails.

----------
files: path-name-must-be-string-or-None.patch
keywords: patch
messages: 152845
nosy: tshepang
priority: normal
severity: normal
status: open
title: path name must always be string
Added file: http://bugs.python.org/file24452/path-name-must-be-string-or-None.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13969>
_______________________________________

From report at bugs.python.org  Wed Feb  8 13:10:37 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 08 Feb 2012 12:10:37 +0000
Subject: [issue13968] Add a recursive function to the glob package
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328703037.69.0.0239176116366.issue13968@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm inclined to close this as a functional duplicate of http://bugs.python.org/issue13229

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 13:19:53 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 08 Feb 2012 12:19:53 +0000
Subject: [issue13960] Handling of broken comments in HTMLParser
In-Reply-To: <1328615796.36.0.0693404155355.issue13960@psf.upfronthosting.co.za>
Message-ID: <1328703593.29.0.466427714037.issue13960@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13960>
_______________________________________

From report at bugs.python.org  Wed Feb  8 13:28:55 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 08 Feb 2012 12:28:55 +0000
Subject: [issue13969] path name must always be string (or None)
In-Reply-To: <1328702198.23.0.695483013492.issue13969@psf.upfronthosting.co.za>
Message-ID: <1328704135.68.0.704767110546.issue13969@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
assignee:  -> tarek
components: +Distutils2
nosy: +alexis, eric.araujo, tarek
title: path name must always be string -> path name must always be string (or None)
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13969>
_______________________________________

From report at bugs.python.org  Wed Feb  8 13:47:35 2012
From: report at bugs.python.org (Yuval Greenfield)
Date: Wed, 08 Feb 2012 12:47:35 +0000
Subject: [issue13968] Add a recursive function to the glob package
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328705255.35.0.33905066091.issue13968@psf.upfronthosting.co.za>


Yuval Greenfield <ubershmekel at gmail.com> added the comment:

I'd say it's very close to a duplicate but maybe isn't so. If walkdir is added then rglob can be implemented using it.

I'd say "rglob" to "walkdir" is like "urlopen" to "http.client". One is the stupid and simple function (that still has a bazillion use cases) and the other is the heavy lifting swiss army knife.

"file_paths(filtered_walk('.', included_files=['*.py']))" is a lot longer than "rglob('*.py')".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 13:49:02 2012
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 08 Feb 2012 12:49:02 +0000
Subject: [issue13965] Windows 64-bit installer actually installing a 32-bit
	version
In-Reply-To: <1328666235.95.0.56390698095.issue13965@psf.upfronthosting.co.za>
Message-ID: <1328705342.14.0.549665969602.issue13965@psf.upfronthosting.co.za>


Ralf Schmitt <python-bugs at systemexit.de> added the comment:

struct.calcsize("P")==8 will tell you if you're running a 64bit python or not.

----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13965>
_______________________________________

From report at bugs.python.org  Wed Feb  8 13:49:16 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Feb 2012 12:49:16 +0000
Subject: [issue13968] Add a recursive function to the glob package
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328705356.58.0.73772821943.issue13968@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> "file_paths(filtered_walk('.', included_files=['*.py']))" is a lot
> longer than "rglob('*.py')".

Agreed.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 13:51:16 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 08 Feb 2012 12:51:16 +0000
Subject: [issue13965] Windows 64-bit installer actually installing a 32-bit
	version
In-Reply-To: <1328666235.95.0.56390698095.issue13965@psf.upfronthosting.co.za>
Message-ID: <1328705476.05.0.982789672174.issue13965@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Or more directly, try platform.architecture().

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13965>
_______________________________________

From report at bugs.python.org  Wed Feb  8 13:53:54 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Feb 2012 12:53:54 +0000
Subject: [issue13956] add a note regarding building on recent versions of
	Debian and Ubuntu
In-Reply-To: <1328561198.71.0.464040865268.issue13956@psf.upfronthosting.co.za>
Message-ID: <1328705634.56.0.793521150612.issue13956@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Or, rather, setup.py should be smart enough to warn about that.

----------
nosy: +barry, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13956>
_______________________________________

From report at bugs.python.org  Wed Feb  8 13:55:59 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 08 Feb 2012 12:55:59 +0000
Subject: [issue13968] Add a recursive function to the glob package
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328705759.22.0.6488800841.issue13968@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

A fair point indeed.

To follow the shutil naming convention (rmtree, copytree, and likely chmodtree, chowntree), a more appropriate name might be "globtree". (Thanks to string methods, the 'r' prefix doesn't read correctly to me: what does "globbing from the right" mean?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 13:57:25 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Feb 2012 12:57:25 +0000
Subject: [issue13968] Add a recursive function to the glob package
In-Reply-To: <1328705759.22.0.6488800841.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328705679.3387.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> To follow the shutil naming convention (rmtree, copytree, and likely
> chmodtree, chowntree), a more appropriate name might be "globtree".
> (Thanks to string methods, the 'r' prefix doesn't read correctly to
> me: what does "globbing from the right" mean?)

Well, if you put it in the glob module, it doesn't have to follow the
shutil naming convention :-)
(I prefer "rglob" myself)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 13:58:24 2012
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 08 Feb 2012 12:58:24 +0000
Subject: [issue13965] Windows 64-bit installer actually installing a 32-bit
	version
In-Reply-To: <1328666235.95.0.56390698095.issue13965@psf.upfronthosting.co.za>
Message-ID: <1328705904.49.0.224952493102.issue13965@psf.upfronthosting.co.za>


Ralf Schmitt <python-bugs at systemexit.de> added the comment:

according to the documentation platform.architecture() may not work on OS X.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13965>
_______________________________________

From report at bugs.python.org  Wed Feb  8 14:10:40 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 08 Feb 2012 13:10:40 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1328629255.3741.132.camel@surprise>
Message-ID: <4F327449.2010408@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Dave Malcolm wrote:
> 
> If anyone is aware of an attack via numeric hashing that's actually
> possible, please let me know (privately).  I believe only specific apps
> could be affected, and I'm not aware of any such specific apps.

I'm not sure what you'd like to see.

Any application reading user provided data from a file, database,
web, etc. is vulnerable to the attack, if it uses the read numeric
data as keys in a dictionary.

The most common use case for this is a dictionary mapping codes or
IDs to strings or objects, e.g. for caching purposes, to find a list
of unique IDs, checking for duplicates, etc.

This also works indirectly on 32-bit platforms, e.g. via date/time
or IP address values that get converted to key integers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Wed Feb  8 14:40:15 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 08 Feb 2012 13:40:15 +0000
Subject: [issue13968] Add a recursive function to the glob package
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328708415.34.0.718824516886.issue13968@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I can live with it either way - I just wanted to point out that our current examples of this kind of recursive filesystem access use a 'tree' suffix rather than an 'r' prefix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 14:43:30 2012
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 08 Feb 2012 13:43:30 +0000
Subject: [issue13903] New shared-keys dictionary implementation
In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za>
Message-ID: <1328708610.37.0.518702797412.issue13903@psf.upfronthosting.co.za>


Changes by Mark Shannon <mark at hotpy.org>:


----------
hgrepos: +112

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13903>
_______________________________________

From report at bugs.python.org  Wed Feb  8 14:44:35 2012
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 08 Feb 2012 13:44:35 +0000
Subject: [issue13903] New shared-keys dictionary implementation
In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za>
Message-ID: <1328708675.47.0.923100455582.issue13903@psf.upfronthosting.co.za>


Changes by Mark Shannon <mark at hotpy.org>:


Added file: http://bugs.python.org/file24453/a9138aba7896.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13903>
_______________________________________

From report at bugs.python.org  Wed Feb  8 14:48:54 2012
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 08 Feb 2012 13:48:54 +0000
Subject: [issue13903] New shared-keys dictionary implementation
In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za>
Message-ID: <1328708934.8.0.0287401012576.issue13903@psf.upfronthosting.co.za>


Changes by Mark Shannon <mark at hotpy.org>:


Removed file: http://bugs.python.org/file24360/6a21f3b35e20.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13903>
_______________________________________

From report at bugs.python.org  Wed Feb  8 15:00:54 2012
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 08 Feb 2012 14:00:54 +0000
Subject: [issue13903] New shared-keys dictionary implementation
In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za>
Message-ID: <1328709654.03.0.603386591232.issue13903@psf.upfronthosting.co.za>


Changes by Mark Shannon <mark at hotpy.org>:


Removed file: http://bugs.python.org/file24453/a9138aba7896.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13903>
_______________________________________

From report at bugs.python.org  Wed Feb  8 15:05:23 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 08 Feb 2012 14:05:23 +0000
Subject: [issue13968] Add a recursive function to the glob package
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328709923.67.0.924124486578.issue13968@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

"file_paths(filtered_walk('.', included_files=['*.py']))" is a lot longer than "rglob('*.py')".


It is, but is that a good enough reason to have both? It can also be achieved with just a bit more code using the simple `os.walk`. I suppose there are a lot of instances of stdlib tools where we could add new tools that would make the code slightly shorter. However, this is not really faithful to the Python spirit, since it adds too many ways to do achieve the same effect, and ultimately confuses users.

That it adds additional maintenance burden on the coredevs goes without saying :-) Each such new burden should have a very good reason.

To conclude, personally I'm -1 on this, especially if `walkdir` eventually makes it into the stdlib.

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 15:14:02 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Feb 2012 14:14:02 +0000
Subject: [issue13968] Add a recursive function to the glob package
In-Reply-To: <1328709923.67.0.924124486578.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328710275.3387.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> "file_paths(filtered_walk('.', included_files=['*.py']))" is a lot
> longer than "rglob('*.py')".
> 
> 
> It is, but is that a good enough reason to have both?

It is. globbing is a well-known operation that many people expect to be
easily done.

> However, this is not really faithful to the Python spirit, since it
> adds too many ways to do achieve the same effect, and ultimately
> confuses users.

Which "Python spirit" are you talking about? We have many high-level
tools in the stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 15:20:23 2012
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 08 Feb 2012 14:20:23 +0000
Subject: [issue13903] New shared-keys dictionary implementation
In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za>
Message-ID: <1328710823.26.0.153381014726.issue13903@psf.upfronthosting.co.za>


Changes by Mark Shannon <mark at hotpy.org>:


Added file: http://bugs.python.org/file24454/1f703b2607af.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13903>
_______________________________________

From report at bugs.python.org  Wed Feb  8 15:24:48 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 14:24:48 +0000
Subject: [issue13807] logging.Handler.handlerError() may raise AttributeError
	in traceback.print_exception()
In-Reply-To: <1326816014.41.0.202399739958.issue13807@psf.upfronthosting.co.za>
Message-ID: <1328711088.37.0.299695556104.issue13807@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the prompt action!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13807>
_______________________________________

From report at bugs.python.org  Wed Feb  8 15:25:31 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 14:25:31 +0000
Subject: [issue13846] Add time.monotonic() function
In-Reply-To: <1327364549.64.0.960699645726.issue13846@psf.upfronthosting.co.za>
Message-ID: <1328711131.28.0.0869577820214.issue13846@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Victor, I think the doc doesn?t say why the function is useful for people like me who don?t already know it.  David?s explanation could be reused.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13846>
_______________________________________

From report at bugs.python.org  Wed Feb  8 15:28:56 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 14:28:56 +0000
Subject: [issue13960] Handling of broken comments in HTMLParser
In-Reply-To: <1328615796.36.0.0693404155355.issue13960@psf.upfronthosting.co.za>
Message-ID: <1328711336.73.0.0144879140849.issue13960@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

LGTM.  What did our last discussion about following HTML5 rules for Python 2.7 lead to?  I don?t remember if we agreed that ?3.3 is soon enough? or ?let?s fix the bugs with HTML5 as reference?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13960>
_______________________________________

From report at bugs.python.org  Wed Feb  8 15:33:02 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 08 Feb 2012 14:33:02 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1328672535.95.0.338904305328.issue11379@psf.upfronthosting.co.za>
Message-ID: <20120208143252.GC1896@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

On Wed, Feb 08, 2012 at 03:42:16AM +0000, Eli Bendersky wrote:
> Any objections?

None. The explanation sounds reasonable.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Wed Feb  8 15:37:38 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Feb 2012 14:37:38 +0000
Subject: [issue13903] New shared-keys dictionary implementation
In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za>
Message-ID: <1328711858.73.0.565565457867.issue13903@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looking at your latest patch, I worry about "any deletion
+(including pop & popitem) causes a split table to become a combined table". Why wouldn't you use a dummy pointer (such as ((PyObject *) 1)) to signal deleted slots?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13903>
_______________________________________

From report at bugs.python.org  Wed Feb  8 15:42:49 2012
From: report at bugs.python.org (Eric Talevich)
Date: Wed, 08 Feb 2012 14:42:49 +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: <1328712169.66.0.984877167878.issue9257@psf.upfronthosting.co.za>


Eric Talevich <eric.talevich at gmail.com> added the comment:

It's more-or-less fixed in Python 3.2:

- With cElementTree, both bytes and strings are accepted for events; 

- With ElementTree, only strings are accepted, and bytes raise a ValueError (unknown event).

A small inconsistency remains, but it's fine to just use strings in all cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9257>
_______________________________________

From report at bugs.python.org  Wed Feb  8 16:02:43 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 15:02:43 +0000
Subject: [issue12703] Improve error reporting for packaging.util.resolve_name
In-Reply-To: <1312626935.87.0.525014153536.issue12703@psf.upfronthosting.co.za>
Message-ID: <1328713363.47.0.549388740921.issue12703@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FYI, here is code that can handle arbitrary dotted names: <http://svn.eby-sarna.com/Importing/peak/util/imports.py?view=markup>.  I haven?t checked if its error reporting has the problem we?re discussing in this report.

An alternative would be to use colon notation, e.g. package.submodule:Thing.Nested.attribute.

My preference is still for find_object, using dots and with the nesting prohibition.

----------
nosy: +erik.bray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12703>
_______________________________________

From report at bugs.python.org  Wed Feb  8 16:11:53 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 15:11:53 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1328713913.24.0.0637324565991.issue11379@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 to the suggested wording.

-1 to talking about a more pythonic API.

(Want a nit?  s/W3C-DOM/W3C DOM/)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Wed Feb  8 16:19:52 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 08 Feb 2012 15:19:52 +0000
Subject: [issue13956] add a note regarding building on recent versions of
	Debian and Ubuntu
In-Reply-To: <1328705634.56.0.793521150612.issue13956@psf.upfronthosting.co.za>
Message-ID: <20120208101931.4a535f3f@resist.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Feb 08, 2012, at 12:53 PM, Antoine Pitrou wrote:

>Or, rather, setup.py should be smart enough to warn about that.

It shouldn't just be limited to Debian and its derivatives.  Other platforms
(even Linux OSes) will probably have similar issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13956>
_______________________________________

From report at bugs.python.org  Wed Feb  8 16:21:44 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 15:21:44 +0000
Subject: [issue13968] Add a recursive function to the glob package
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328714504.53.0.817176850774.issue13968@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

There is an alternative: supporting ** syntax, e.g. '**/*.py', which should find all *.py files in the current directory and all descendents.  At present glob('**/*.py') is equivalent to glob('*/*.py'), but we would say this behavior was undefined and the new behavior would be a new feature.

----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 16:30:35 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 15:30:35 +0000
Subject: [issue13960] Handling of broken comments in HTMLParser
In-Reply-To: <1328615796.36.0.0693404155355.issue13960@psf.upfronthosting.co.za>
Message-ID: <1328715035.39.0.475886595281.issue13960@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

After reading some emails again, I?m +1 on porting the fixes to 2.7.

1) We agree that HTML5 is the reference specification.

2) I don?t think there is sane code that would be broken if some previously unparsable page became parsable (an exception can be HTML parsers, but the obvious example BeautifulSoup does not use HTMLParser for example); HTMLParser is not a validating parser and never made any guarantee about the validity of handled pages.

3) Most people should be happy to have more pages handled by HTMLParser.

4) 2.7 is unique as long-term support, last 2.7 release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13960>
_______________________________________

From report at bugs.python.org  Wed Feb  8 16:37:09 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Feb 2012 15:37:09 +0000
Subject: [issue13956] add a note regarding building on recent versions of
	Debian and Ubuntu
In-Reply-To: <20120208101931.4a535f3f@resist.wooz.org>
Message-ID: <1328715263.3387.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> >Or, rather, setup.py should be smart enough to warn about that.
> 
> It shouldn't just be limited to Debian and its derivatives.  Other platforms
> (even Linux OSes) will probably have similar issues.

The issue (having to install dpkg-dev) is specifically about Debian and
Ubuntu. I don't think we should have tons of platform-specific
instructions in the devguide, and I think that in this case setup.py
should detect that the required tool is missing (depending on the
platform, of course).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13956>
_______________________________________

From report at bugs.python.org  Wed Feb  8 16:43:21 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 08 Feb 2012 15:43:21 +0000
Subject: [issue13968] Add a recursive function to the glob package
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328715801.22.0.217839127365.issue13968@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

>> It is. globbing is a well-known operation that many people expect to be easily done.

According to Wikipedia (http://en.wikipedia.org/wiki/Glob_%28programming%29) - "The noun "glob" is used to refer to a particular pattern, e.g. "use the glob *.log to match all those log files"". 

IOW, globbing is usually understood as the act of expanding a pattern to the files it matches. Nothing in that implies recursive traversal of a directory tree. On the other hand, os.walk and/or walkdir suggest that in their name.

>> Which "Python spirit" are you talking about? We have many high-level
tools in the stdlib.

There should be one -- and preferably only one -- obvious way to do it. 

Admittedly, we already have more than one, and a high-level tool is proposed with Nick's walkdir. Why add *yet another* high-level tool?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 16:51:03 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 15:51:03 +0000
Subject: [issue13956] add a note regarding building on recent versions of
	Debian and Ubuntu
In-Reply-To: <1328561198.71.0.464040865268.issue13956@psf.upfronthosting.co.za>
Message-ID: <1328716263.97.0.576815890393.issue13956@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The correct way to get build dependencies on Debian and derivatives is to use ?aptitude build-dep pythonX.Y? (see #13472).  I think dpkg-dev would get installed as a dependency; Tshepang, could you uninstall dpkg-dev and test the aptitude command?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13956>
_______________________________________

From report at bugs.python.org  Wed Feb  8 16:51:54 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 15:51:54 +0000
Subject: [issue13963] dev guide has no mention of mechanics of patch review
In-Reply-To: <1328631878.8.0.85188160352.issue13963@psf.upfronthosting.co.za>
Message-ID: <1328716314.41.0.363619110237.issue13963@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/issue13963>
_______________________________________

From report at bugs.python.org  Wed Feb  8 16:52:06 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Feb 2012 15:52:06 +0000
Subject: [issue13968] Add a recursive function to the glob package
In-Reply-To: <1328715801.22.0.217839127365.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328716158.3387.11.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> IOW, globbing is usually understood as the act of expanding a pattern
> to the files it matches. Nothing in that implies recursive traversal
> of a directory tree.

Still, that's a common need. "I want all Python files in a subtree".

> On the other hand, os.walk and/or walkdir suggest that in their name.

I don't know why "walk" is supposedly more recursive than "glob".

> Admittedly, we already have more than one, and a high-level tool is
> proposed with Nick's walkdir. Why add *yet another* high-level tool?

Because the walkdir spelling (IIUC) is longish, tedious and awkward.
I could see myself typing "rglob('*.py')" in a short script or an
interpreter session, without having to look up any kind of docs.
Certainly not the walkdir alternative (I've already forgotten what it
is).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 16:54:34 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 15:54:34 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328716474.71.0.26415238651.issue13968@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: Add a recursive function to the glob package -> Support recursive globs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 16:55:41 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 08 Feb 2012 15:55:41 +0000
Subject: [issue13956] add a note regarding building on recent versions of
	Debian and Ubuntu
In-Reply-To: <1328716263.97.0.576815890393.issue13956@psf.upfronthosting.co.za>
Message-ID: <20120208105536.79c4fd67@resist.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Feb 08, 2012, at 03:51 PM, ?ric Araujo wrote:

>The correct way to get build dependencies on Debian and derivatives is to use
>?aptitude build-dep pythonX.Y? (see #13472).  I think dpkg-dev would get
>installed as a dependency; Tshepang, could you uninstall dpkg-dev and test
>the aptitude command?

+1 and that definitely works.  I use that all the time on new VMs.

If it *doesn't* work, then that's a bug in the Debian pythonX.Y package.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13956>
_______________________________________

From report at bugs.python.org  Wed Feb  8 16:57:38 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 15:57:38 +0000
Subject: [issue13956] add a note regarding building on recent versions of
	Debian and Ubuntu
In-Reply-To: <1328561198.71.0.464040865268.issue13956@psf.upfronthosting.co.za>
Message-ID: <1328716658.17.0.527283237413.issue13956@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Then I propose to close this as duplicate of #13472.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13956>
_______________________________________

From report at bugs.python.org  Wed Feb  8 16:59:23 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 08 Feb 2012 15:59:23 +0000
Subject: [issue13968] Add a recursive function to the glob package
In-Reply-To: <1328716158.3387.11.camel@localhost.localdomain>
Message-ID: <CAF-Rda9m-JMvX-5K_kJawANh-rLL3+tTi81eP_zEzeL7jhFEKQ@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

>> IOW, globbing is usually understood as the act of expanding a pattern
>> to the files it matches. Nothing in that implies recursive traversal
>> of a directory tree.
>
> Still, that's a common need. "I want all Python files in a subtree".
>
>> On the other hand, os.walk and/or walkdir suggest that in their name.
>
> I don't know why "walk" is supposedly more recursive than "glob".

Google "walk directory". First hit is a Rosetta code page with
*recursive* walking implemented in various languages. So I guess it
does have this connotation. Regardless, os.walk has been in Python for
ages, and it's always been the go-to tool for recursive traversal.
walkdir's name suggests the same.

>
>> Admittedly, we already have more than one, and a high-level tool is
>> proposed with Nick's walkdir. Why add *yet another* high-level tool?
>
> Because the walkdir spelling (IIUC) is longish, tedious and awkward.
> I could see myself typing "rglob('*.py')" in a short script or an
> interpreter session, without having to look up any kind of docs.
> Certainly not the walkdir alternative (I've already forgotten what it
> is).

walkdir is a new module proposal. If its API is tedious and awkward,
it should probably be improved *now* while it's in development. Adding
yet another tool that implements part of its functionality, winning a
golf tournament along the way, isn't the solution, IMHO.

----------
title: Support recursive globs -> Add a recursive function to the glob package

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:01:25 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 16:01:25 +0000
Subject: [issue13968] Add a recursive function to the glob package
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328716885.0.0.19395812177.issue13968@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Feedback from Antoine on IRC about my syntax proposal: ?The "**" meaning is not really universal like other quantifiers are. [...] (also, it would be quite harder to implement, I think)?

That and the compat issue makes me go in favor of a new function.

I?m not sure glob is the right place: when you use glob.glob, the search is rooted in the current directory, and you may have sub-directories in your pattern, e.g. 'Lib/*/__main__.py'.  A function meaning ?look for this file pattern recursively? would be IMO more at home in fnmatch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:07:20 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 08 Feb 2012 16:07:20 +0000
Subject: [issue13956] add a note regarding building on recent versions of
	Debian and Ubuntu
In-Reply-To: <1328561198.71.0.464040865268.issue13956@psf.upfronthosting.co.za>
Message-ID: <1328717240.46.0.100580284538.issue13956@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

@Barry, it does work on Debian as well
@Eric, I agree with closing it as a dupe

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13956>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:09:59 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Feb 2012 16:09:59 +0000
Subject: [issue13968] Add a recursive function to the glob package
In-Reply-To: <CAF-Rda9m-JMvX-5K_kJawANh-rLL3+tTi81eP_zEzeL7jhFEKQ@mail.gmail.com>
Message-ID: <1328717232.3387.20.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Google "walk directory". First hit is a Rosetta code page with
> *recursive* walking implemented in various languages. So I guess it
> does have this connotation. Regardless, os.walk has been in Python for
> ages, and it's always been the go-to tool for recursive traversal.
> walkdir's name suggests the same.

You still haven't explained what your problem is with the idea of an
explicitly recursive glob (as both "rglob" and "globtree" suggest).

> walkdir is a new module proposal. If its API is tedious and awkward,
> it should probably be improved *now* while it's in development.

walkdir is not yet a module proposal, there's not even a PEP for it, and
it's in a very young state.

This issue has a working patch for rglob(), which is a single, obvious,
incremental addition to the existing glob module. If you want to discuss
walkdir, I suggest you do it in a separate issue.

(and, yes, rglob() can be reimplemented using walkdir later, if there is
a point in doing so)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:15:08 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 08 Feb 2012 16:15:08 +0000
Subject: [issue13968] Add a recursive function to the glob package
In-Reply-To: <1328717232.3387.20.camel@localhost.localdomain>
Message-ID: <CAF-Rda9VVmJgc-a-qRxopXeB3SDe+C0F+ZnOxXj+-__PX0dmvw@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

>> Google "walk directory". First hit is a Rosetta code page with
>> *recursive* walking implemented in various languages. So I guess it
>> does have this connotation. Regardless, os.walk has been in Python for
>> ages, and it's always been the go-to tool for recursive traversal.
>> walkdir's name suggests the same.
>
> You still haven't explained what your problem is with the idea of an
> explicitly recursive glob (as both "rglob" and "globtree" suggest).
>

The problem is that I prefer the walkdir approach, because it solves a
more general problem and overall more useful. This is also why I don't
see how it makes sense to stop discussing it here and focus on rglob.
They are related, after all!

Anyway, I'm not sure what else I can add to the discussion. I'm
starting to repeat myself, which means that I should just shut up :)

I've stated my preference, and I understand and respect yours. So
let's just see what others think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:26:52 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 08 Feb 2012 16:26:52 +0000
Subject: [issue13736] urllib.request.urlopen leaks exceptions from socket and
	httplib.client
In-Reply-To: <1326003740.31.0.0410778534365.issue13736@psf.upfronthosting.co.za>
Message-ID: <1328718412.76.0.292031080962.issue13736@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I have stumbled upon a wrong impression as well by reading the docs, but usually in the code, I tend to catch the specific Exceptions, like timeout instead or URLError when it is known. I saw some libraries following similar pattern too. But that could be changed, if promise in the docs that URLError exception is raised is corrected. 

I think, the course of action for this bug could be.

1. raise ... from .. for the appropriate Exception in 3.3 and appropriate doc changes.
2. Doc changes in 2.7,3.2 which say indicate the possibility of other exceptions besides URLError.

Having any important information in the msg part of the Exception is a bad idea, because it is seldom relied upon and can be changed anytime.

Shall come out with a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13736>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:27:51 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Feb 2012 16:27:51 +0000
Subject: [issue13968] Add a recursive function to the glob package
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328718471.58.0.548940562316.issue13968@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm trying the patch and its behaviour is strange:

>>> list(glob.rglob('setup.py'))
['setup.py']
>>> list(glob.rglob('setu*.py'))
[]
>>> list(glob.rglob('*/setu*.py'))
['./setup.py', './Mac/Tools/Doc/setup.py', './Tools/test2to3/setup.py', './Doc/includes/setup.py', './PC/example_nt/setup.py']

I can understand the first example (although that makes the documentation slightly incorrect, since you need an explicit "*" path component for the search to be recursive), but the second one looks straight wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:27:54 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 16:27:54 +0000
Subject: [issue13915] Update tutorial/modules for PEP 3147
In-Reply-To: <1328053198.63.0.994035147287.issue13915@psf.upfronthosting.co.za>
Message-ID: <1328718474.9.0.166150445451.issue13915@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: Update Tutorial 6.1.3 for PEP 3145 -> Update tutorial/modules for PEP 3147

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13915>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:32:04 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 16:32:04 +0000
Subject: [issue13969] path name must always be string (or None)
In-Reply-To: <1328702198.23.0.695483013492.issue13969@psf.upfronthosting.co.za>
Message-ID: <1328718724.77.0.306059198948.issue13969@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hm, that function is for internal use only, and our code always passes a string, so I?m not sure a type check is useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13969>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:32:58 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 16:32:58 +0000
Subject: [issue13967] also test for an empty pathname
In-Reply-To: <1328691895.76.0.461063464523.issue13967@psf.upfronthosting.co.za>
Message-ID: <1328718778.82.0.203808568677.issue13967@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Will commit, thanks.

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13967>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:34:13 2012
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 08 Feb 2012 16:34:13 +0000
Subject: [issue13903] New shared-keys dictionary implementation
In-Reply-To: <1328711858.73.0.565565457867.issue13903@psf.upfronthosting.co.za>
Message-ID: <4F32A406.70604@hotpy.org>


Mark Shannon <mark at hotpy.org> added the comment:

Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> Looking at your latest patch, I worry about "any deletion
> +(including pop & popitem) causes a split table to become a combined table". Why wouldn't you use a dummy pointer (such as ((PyObject *) 1)) to signal deleted slots?

In fact here is no need for a dummy pointer.
When deleting from a split-table, the value can just be set to NULL,
the resulting key-NULL pair is legal in a split-table.
Your suggestion doesn't make the code any more complex, so I've included it.

In practice, it will very rare that a deletion occurs in a split table
(since they are only used for attribute dictionaries).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13903>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:34:26 2012
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 08 Feb 2012 16:34:26 +0000
Subject: [issue13903] New shared-keys dictionary implementation
In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za>
Message-ID: <1328718866.47.0.486144551406.issue13903@psf.upfronthosting.co.za>


Changes by Mark Shannon <mark at hotpy.org>:


Removed file: http://bugs.python.org/file24454/1f703b2607af.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13903>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:34:53 2012
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 08 Feb 2012 16:34:53 +0000
Subject: [issue13903] New shared-keys dictionary implementation
In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za>
Message-ID: <1328718893.82.0.479930596967.issue13903@psf.upfronthosting.co.za>


Changes by Mark Shannon <mark at hotpy.org>:


Added file: http://bugs.python.org/file24455/bc286099ce9a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13903>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:35:33 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 16:35:33 +0000
Subject: [issue13511] Specifying multiple lib and include directories on linux
In-Reply-To: <1322683661.17.0.138081414237.issue13511@psf.upfronthosting.co.za>
Message-ID: <1328718933.09.0.208079427886.issue13511@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ronald, is ?unity platforms? a typo for ?unixy platforms??  IOW, are you expressing a +1 to the feature request, despite Martin?s rejection (with which I agree)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13511>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:42:13 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 16:42:13 +0000
Subject: [issue13590] extension module builds fail with python.org OS X
	installers on OS X 10.7 and 10.6 with Xcode 4.2
In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za>
Message-ID: <1328719333.58.0.100770259129.issue13590@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Would you think it acceptable to judge that the problem is Apple?s and that we could do only a doc change with the not-so-hard envvar override?

I understand that you?d like to fix the problem for all OS X users in one go, but the new behavior seems a bit too magical for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13590>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:46:59 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 16:46:59 +0000
Subject: [issue13953] Get rid of doctests in packaging.tests.test_version
In-Reply-To: <1328554740.27.0.167211242761.issue13953@psf.upfronthosting.co.za>
Message-ID: <1328719619.12.0.0705010488302.issue13953@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The interesting line is just after the string:

  doctest.script_from_examples(comparison_doctest_string)

However it looks like there has been a problem with that line, as you can?t get the test to fail, which is strange as I did use that doctest to check #11841!  Instead of using time to figure out doctest antics, I will just use good old reliable integrated unittest.

----------
assignee: tarek -> eric.araujo
title: test_packaging: unused test? -> Get rid of doctests in packaging.tests.test_version
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13953>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:48:09 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 16:48:09 +0000
Subject: [issue13845] Use GetSystemTimeAsFileTime() to get a resolution of 100
	ns on Windows
In-Reply-To: <1327363365.73.0.00740710968562.issue13845@psf.upfronthosting.co.za>
Message-ID: <1328719689.44.0.849081100992.issue13845@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Please make sure to say ?on Windows? in NEWS and commit messages when you?re doing platform-specific changes :)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13845>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:50:11 2012
From: report at bugs.python.org (K Richard Pixley)
Date: Wed, 08 Feb 2012 16:50:11 +0000
Subject: [issue13590] extension module builds fail with python.org OS X
	installers on OS X 10.7 and 10.6 with Xcode 4.2
In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za>
Message-ID: <1328719811.08.0.26727563145.issue13590@psf.upfronthosting.co.za>


K Richard Pixley <rich at noir.com> added the comment:

I think a better solution that declaring it to be apple's bug would be to release one binary for pre-10.7, (or maybe 10.6 with the current xcode), and a different binary for post-10.7.

This isn't an apple "bug" in the sense that there's anything wrong nor in the sense that they would ever "fix" it.  It's simply a difference between xcode versions.  So the choices would seem to be a) code around it or b) release different binaries.

I'm ok with either solution.  I'm not sure what would be best as I'm not sure I know all of the concerns involved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13590>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:51:04 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 16:51:04 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>
Message-ID: <1328719864.45.0.699601346592.issue12659@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I've just updated ?test_support.py? and tested against 'default'
Do you mean that you have added more tests to the existing file?  If so, could you provide a patch this time?

> BTW: in distutils2 I get (not because of this change):
It?s a known failure that?s caused by a bug fix in 2.7.3.  I didn?t fix it because I need to check the original bug report for the failing test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12659>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:56:42 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 08 Feb 2012 16:56:42 +0000
Subject: [issue11841] Bug in the version comparison
In-Reply-To: <1302686380.66.0.407051830429.issue11841@psf.upfronthosting.co.za>
Message-ID: <1328720202.94.0.00951501022961.issue11841@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
title: Bug in the verson comparison -> Bug in the version comparison

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11841>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:58:29 2012
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 08 Feb 2012 16:58:29 +0000
Subject: [issue13903] New shared-keys dictionary implementation
In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za>
Message-ID: <1328720309.84.0.736732681837.issue13903@psf.upfronthosting.co.za>


Changes by Mark Shannon <mark at hotpy.org>:


Removed file: http://bugs.python.org/file24455/bc286099ce9a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13903>
_______________________________________

From report at bugs.python.org  Wed Feb  8 17:59:08 2012
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 08 Feb 2012 16:59:08 +0000
Subject: [issue13903] New shared-keys dictionary implementation
In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za>
Message-ID: <1328720348.24.0.7939580248.issue13903@psf.upfronthosting.co.za>


Changes by Mark Shannon <mark at hotpy.org>:


Added file: http://bugs.python.org/file24456/20702d1acf17.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13903>
_______________________________________

From report at bugs.python.org  Wed Feb  8 18:01:54 2012
From: report at bugs.python.org (Ned Deily)
Date: Wed, 08 Feb 2012 17:01:54 +0000
Subject: [issue13590] extension module builds fail with python.org OS X
	installers on OS X 10.7 and 10.6 with Xcode 4.2
In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za>
Message-ID: <1328720514.61.0.735807032351.issue13590@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

?ric, no, the problem is not Apple's in the sense that we enforce the use of the build compiler.  Without a fix along this line would mean that essentially *every* user of python.org Pythons on the latest releases of OS X would have to ensure that the environment variable override is in place for every Distutils install of an extension module.  That strikes me as unacceptable.  Distutils already does equally magical things.  I think this is the best solution at the moment.  Ronald, what's your opinion?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13590>
_______________________________________

From report at bugs.python.org  Wed Feb  8 18:08:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 17:08:07 +0000
Subject: [issue13956] add a note regarding building on recent versions of
	Debian and Ubuntu
In-Reply-To: <1328561198.71.0.464040865268.issue13956@psf.upfronthosting.co.za>
Message-ID: <1328720887.77.0.801730126623.issue13956@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> devguide doesn?t list all build dependencies

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13956>
_______________________________________

From report at bugs.python.org  Wed Feb  8 18:13:59 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 17:13:59 +0000
Subject: [issue13590] extension module builds fail with python.org OS X
	installers on OS X 10.7 and 10.6 with Xcode 4.2
In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za>
Message-ID: <1328721239.54.0.223657253078.issue13590@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> the problem is not Apple's in the sense that we enforce the use of the build compiler.
Well, yes, and this is a known limitation, so we could argue that Apple broke distutils.  But...

> Without a fix along this line would mean that essentially *every* user of python.org Pythons on
> the latest releases of OS X would have to ensure that the environment variable override is in
> place for every Distutils install of an extension module.  That strikes me as unacceptable.
> Distutils already does equally magical things.
Given that we did similar changes to support Debian multiarch instead of having people use environment variables, I change my position and support your patch.  (Comments on Rietveld.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13590>
_______________________________________

From report at bugs.python.org  Wed Feb  8 18:18:48 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Feb 2012 17:18:48 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328721528.42.0.910527627686.issue13968@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>>> list(glob.rglob('*/setu*.py'))

It looks quite strange to me that '/' should be allowed in a function that recurses down directories (see my messages above).  OTOH fnmatch is not really appropriate, contrary to my earlier feeling.

(Restoring my title change: as my messages were apparently overlooked, I assume that Eli did not revert my change on purpose but by replying to older email)

----------
title: Add a recursive function to the glob package -> Support recursive globs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 18:41:58 2012
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 08 Feb 2012 17:41:58 +0000
Subject: [issue13970] frameobject should not have f_yieldfrom attribute
Message-ID: <1328722917.98.0.121121534686.issue13970@psf.upfronthosting.co.za>


New submission from Mark Shannon <mark at hotpy.org>:

The f_yieldfrom field should not be visible at Python level, it is an internal implementation detail.

Patch attached.

----------
files: remove_f_yieldfrom.patch
keywords: patch
messages: 152895
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: frameobject should not have f_yieldfrom attribute
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24457/remove_f_yieldfrom.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13970>
_______________________________________

From report at bugs.python.org  Wed Feb  8 19:15:08 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Wed, 08 Feb 2012 18:15:08 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>
Message-ID: <1328724908.24.0.0157679914257.issue12659@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

> If so, could you provide a patch this time?
Done. The patch is against default.

what about against distutils2? Do you need also a patch for it?

----------
Added file: http://bugs.python.org/file24458/issue12659_58bd6a58365d.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12659>
_______________________________________

From report at bugs.python.org  Wed Feb  8 19:44:23 2012
From: report at bugs.python.org (umedoblock)
Date: Wed, 08 Feb 2012 18:44:23 +0000
Subject: [issue13971] format() doesn't parse str.
Message-ID: <1328726663.18.0.681265030532.issue13971@psf.upfronthosting.co.za>


New submission from umedoblock <umedoblock at gmail.com>:

format() mis understaning.
please pay attention to [0], [x].

>>> d = {0: "a", "0": "A"}
>>> 'd[0] = {0[0]}'.format(d)
'd[0] = a'
>>> 'd[0] = {0["0"]}'.format(d)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: '"0"'
>>> d2 = {"x": 100}
>>> 'd2[x] = {0[x]}'.format(d2)
'd2[x] = 100'

----------
components: Regular Expressions
messages: 152897
nosy: ezio.melotti, umedoblock
priority: normal
severity: normal
status: open
title: format() doesn't parse str.
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13971>
_______________________________________

From report at bugs.python.org  Wed Feb  8 19:45:30 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 08 Feb 2012 18:45:30 +0000
Subject: [issue13971] format() doesn't parse str.
In-Reply-To: <1328726663.18.0.681265030532.issue13971@psf.upfronthosting.co.za>
Message-ID: <1328726730.38.0.553814835499.issue13971@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13971>
_______________________________________

From report at bugs.python.org  Wed Feb  8 19:59:48 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 08 Feb 2012 18:59:48 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328727588.56.0.270894686528.issue13968@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Oops, ?ric, sorry about the title. I didn't even notice :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb  8 20:10:47 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Wed, 08 Feb 2012 19:10:47 +0000
Subject: [issue13953] Get rid of doctests in packaging.tests.test_version
In-Reply-To: <1328554740.27.0.167211242761.issue13953@psf.upfronthosting.co.za>
Message-ID: <1328728247.13.0.0670870051272.issue13953@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

Hi
here's a patch preview: it has to be re factored further but I stopped here as some tests failed: the out commented ones ... I've checked twice but I cannot see any diff, could you check that? Or, has maybe the behavior (due that bug) changed and nobody noticed?

Thanks in advance !

Francis

----------
keywords: +patch
Added file: http://bugs.python.org/file24459/issue13953_58bd6a58365d.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13953>
_______________________________________

From report at bugs.python.org  Wed Feb  8 20:29:52 2012
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 08 Feb 2012 19:29:52 +0000
Subject: [issue13719] bdist_msi upload fails
In-Reply-To: <1325855918.9.0.207720990162.issue13719@psf.upfronthosting.co.za>
Message-ID: <1328729392.03.0.208997532737.issue13719@psf.upfronthosting.co.za>


Ralf Schmitt <python-bugs at systemexit.de> added the comment:

there's a workaround in http://pypi.python.org/pypi/xdistutils#the-bdist-msi-fixed-command

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13719>
_______________________________________

From report at bugs.python.org  Wed Feb  8 20:31:41 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Feb 2012 19:31:41 +0000
Subject: [issue13970] frameobject should not have f_yieldfrom attribute
In-Reply-To: <1328722917.98.0.121121534686.issue13970@psf.upfronthosting.co.za>
Message-ID: <1328729501.5.0.554318084193.issue13970@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Interpreter Core
nosy: +ncoghlan
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13970>
_______________________________________

From report at bugs.python.org  Wed Feb  8 20:37:44 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 08 Feb 2012 19:37:44 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1328729864.24.0.274304962555.issue9750@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Marko's last patch looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9750>
_______________________________________

From report at bugs.python.org  Wed Feb  8 20:39:34 2012
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 08 Feb 2012 19:39:34 +0000
Subject: [issue13971] format() doesn't parse str.
In-Reply-To: <1328726663.18.0.681265030532.issue13971@psf.upfronthosting.co.za>
Message-ID: <1328729974.56.0.697188611771.issue13971@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

This is working as defined in PEP 3101: it calls PySequence_GetItem() or PyObject_GetItem() on the value inside the brackets. There is indeed no item in d that is the string "0" (including the quotes).

----------
assignee:  -> eric.smith
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13971>
_______________________________________

From report at bugs.python.org  Wed Feb  8 20:40:23 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 08 Feb 2012 19:40:23 +0000
Subject: [issue13970] frameobject should not have f_yieldfrom attribute
In-Reply-To: <1328722917.98.0.121121534686.issue13970@psf.upfronthosting.co.za>
Message-ID: <1328730023.76.0.80562701283.issue13970@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I agree, FWIW.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13970>
_______________________________________

From report at bugs.python.org  Wed Feb  8 21:13:34 2012
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 08 Feb 2012 20:13:34 +0000
Subject: [issue13911] test_trace  depends on dict repr() ordering
In-Reply-To: <1327880152.89.0.0711859595035.issue13911@psf.upfronthosting.co.za>
Message-ID: <1328732014.09.0.516272868018.issue13911@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

Failure occurs in test_pprint which is covered by issue 13907

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13911>
_______________________________________

From report at bugs.python.org  Wed Feb  8 21:16:29 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 08 Feb 2012 20:16:29 +0000
Subject: [issue8184] multiprocessing.managers will not fail if listening ocket
	already in use
In-Reply-To: <1269104932.24.0.802901286813.issue8184@psf.upfronthosting.co.za>
Message-ID: <E1RvDwE-0005SJ-Rz@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 434301d9f664 by Charles-Fran?ois Natali in branch 'default':
Issue #8184: multiprocessing: On Windows, don't set SO_REUSEADDR on Connection
http://hg.python.org/cpython/rev/434301d9f664

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8184>
_______________________________________

From report at bugs.python.org  Wed Feb  8 21:24:15 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 08 Feb 2012 20:24:15 +0000
Subject: [issue13965] Windows 64-bit installer actually installing a 32-bit
	version
In-Reply-To: <1328666235.95.0.56390698095.issue13965@psf.upfronthosting.co.za>
Message-ID: <1328732655.09.0.384913244021.issue13965@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

platform.architecture() and struct.calcsize("P") confirm that this build used 64-bits for pointers and 32-bits for ints.

This leaves the question of whether LLP64 is required to run Python on Windows or whether another memory model could have been selected during compilation (IOW, do we have to live with 32-bit ints on Windows)?

----------
priority: normal -> low
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13965>
_______________________________________

From report at bugs.python.org  Wed Feb  8 21:33:39 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 08 Feb 2012 20:33:39 +0000
Subject: [issue13965] Windows 64-bit installer actually installing a 32-bit
	version
In-Reply-To: <1328666235.95.0.56390698095.issue13965@psf.upfronthosting.co.za>
Message-ID: <1328733219.76.0.301967902086.issue13965@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

LLP64 is the model chosen by the Microsoft compiler: sizeof(long)==4.

I suppose someone already considered to change PyIntObject and use size_t values, but IMO it would have broken too many extensions: the pattern "if (PyInt_Check(obj)) value=PyInt_AS_LONG(obj);" is very very common.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13965>
_______________________________________

From report at bugs.python.org  Wed Feb  8 21:34:00 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 08 Feb 2012 20:34:00 +0000
Subject: [issue11689] sqlite: Incorrect unit test fails to detect failure
In-Reply-To: <1301178520.82.0.473046584416.issue11689@psf.upfronthosting.co.za>
Message-ID: <1328733240.22.0.52308545498.issue11689@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11689>
_______________________________________

From report at bugs.python.org  Wed Feb  8 21:42:45 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 08 Feb 2012 20:42:45 +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: <1328733765.65.0.752468876415.issue8033@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8033>
_______________________________________

From report at bugs.python.org  Wed Feb  8 21:48:13 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 08 Feb 2012 20:48:13 +0000
Subject: [issue13841] multiprocessing should use sys.exit() where possible
In-Reply-To: <1327345132.43.0.775594933755.issue13841@psf.upfronthosting.co.za>
Message-ID: <1328734093.52.0.0989639853269.issue13841@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's a trivial patch.
I run the testsuite on one of the Windows buildbots, and there was one failure, in test_concurrent_futures:

"""
======================================================================
FAIL: test_interpreter_shutdown (test.test_concurrent_futures.ProcessPoolShutdownTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\custom.bolen-windows7\build\lib\test\test_concurrent_futures.py", line 109, in test_interpreter_shutdown
    self.assertFalse(err)
AssertionError: b'[68326 refs]\n[68326 refs]\n[68326 refs]\n[68326 refs]\n[106059 refs]' is not false

----------------------------------------------------------------------
"""

That's simply because test.support.strip_python_stderr only strips the first occurrence of the refs count printed in debug mode at output (which didn't get printed upon ExitProcess).

The patch changes this.

----------
keywords: +needs review, patch
stage: test needed -> patch review
Added file: http://bugs.python.org/file24460/multiprocessing_exit.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13841>
_______________________________________

From report at bugs.python.org  Wed Feb  8 22:05:15 2012
From: report at bugs.python.org (Alexander Jones)
Date: Wed, 08 Feb 2012 21:05:15 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1328735115.69.0.86637794823.issue10049@psf.upfronthosting.co.za>


Alexander Jones <aj.dneg at gmail.com> added the comment:

Not having this as a standard idiom makes it very tempting to just do copy-paste coding as in hniksic's example. Who likes to invent their own library for generic language-supporting idioms?

What about an alternative of giving NoneType empty enter and exit methods? So instead of a 'null' CM you can just use "with None"?

----------
nosy: +Alexander.Jones

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Wed Feb  8 22:08:12 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 08 Feb 2012 21:08:12 +0000
Subject: [issue13965] Windows 64-bit installer actually installing a 32-bit
	version
In-Reply-To: <1328666235.95.0.56390698095.issue13965@psf.upfronthosting.co.za>
Message-ID: <1328735292.94.0.745762538967.issue13965@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

On Win64, the long type is 32-bit; the compiler does not support any other mode. So the question "whether another memory model could have been selected during compilation" must be answered as "no, the compiler does not support multiple memory models".

We could have chosen to not use long for ob_ival. However, that would have cause a massive API change, as functions such as PyLong_AsLong either would have to change their return type, or start raising exceptions even for exact int objects.

In Python 3, this issue is fixed as the int type has no range constraint anymore.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13965>
_______________________________________

From report at bugs.python.org  Wed Feb  8 22:52:48 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 08 Feb 2012 21:52:48 +0000
Subject: [issue13845] Use GetSystemTimeAsFileTime() to get a resolution of 100
	ns on Windows
In-Reply-To: <1327363365.73.0.00740710968562.issue13845@psf.upfronthosting.co.za>
Message-ID: <E1RvFRV-0006rQ-5v@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3965ed809a85 by Victor Stinner in branch 'default':
Issue #13845: Fix NEWS entry, the change is specific to Windows
http://hg.python.org/cpython/rev/3965ed809a85

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13845>
_______________________________________

From report at bugs.python.org  Wed Feb  8 23:05:58 2012
From: report at bugs.python.org (sbt)
Date: Wed, 08 Feb 2012 22:05:58 +0000
Subject: [issue13841] multiprocessing should use sys.exit() where possible
In-Reply-To: <1327345132.43.0.775594933755.issue13841@psf.upfronthosting.co.za>
Message-ID: <1328738758.27.0.249013735312.issue13841@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

I think the patch makes multiprocessing.util._exit_function() run twice in non-main processes because it is registered with atexit, and is also called in Process._bootstrap().

_exit_function() does the following:

 * terminate active daemon processes;

 * join active non-daemon processes;

 * run finalizers with non-None exit priority and clear finalizer registry.

So calling _exit_function() twice is probably harmless but should perhaps be fixed.

P.S. It also appears that _exit_function() should set the global _exiting to True, since it declares the variable as a global but does not use it.  As a result util.is_exiting() always returns False.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13841>
_______________________________________

From report at bugs.python.org  Wed Feb  8 23:31:31 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 08 Feb 2012 22:31:31 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <E1RvG30-0002HK-53@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c92f8de398ed by Antoine Pitrou in branch 'default':
Issue #13609: Add two functions to query the terminal size:
http://hg.python.org/cpython/rev/c92f8de398ed

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Wed Feb  8 23:33:53 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Feb 2012 22:33:53 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1328740433.45.0.914316301362.issue13609@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch is finally committed. Thank you Zbyszek for having been quite patient.
(according to Murphy's laws, this will surely break some buildbots)

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Wed Feb  8 23:59:30 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Wed, 08 Feb 2012 22:59:30 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1328740433.45.0.914316301362.issue13609@psf.upfronthosting.co.za>
Message-ID: <4F32FE4B.3080608@in.waw.pl>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

Thanks for merging!

I'll try to keep an eye on the buildbot results, but please add me to 
any bugs in case I miss something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Thu Feb  9 00:52:58 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Feb 2012 23:52:58 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328745178.81.0.348216396155.issue13882@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch version 13:
 - os.utime(path) sets the access and modification time using the currenet time with a subsecond resolution (e.g. microsecond resolution on Linux)
 - os.*utime*() functions uses _PyTime_t type and functions
 - add many functions to manipulate timeval, timespec and FILETIME types with _PyTime_t, add _PyTime_SetDenominator() function for that
 - coding style: follow PEP 7 rules for braces

So more functions (including os.*utime*()) "accept" Decimal, but using an implicit conversion to float.

----------
Added file: http://bugs.python.org/file24461/time_decimal-13.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Thu Feb  9 00:53:34 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Feb 2012 23:53:34 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328745214.29.0.661907719689.issue13882@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file24445/time_decimal-11.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Thu Feb  9 00:53:35 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Feb 2012 23:53:35 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328745215.41.0.073832363336.issue13882@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file24448/time_decimal-12.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Thu Feb  9 00:57:50 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 08 Feb 2012 23:57:50 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328745470.26.0.684848904942.issue13968@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I think it's important to be clear on what the walkdir API aims to be: a composable toolkit of utilities for directory tree processing. It's overall design is inspired directly by the itertools module.

Yes, it started life as a simple proposal to add shutil.filtered_walk (http://bugs.python.org/issue13229), but I soon realised that implementing this solely as a monolothic function would be foolish, since that approach isn't composable. What if you just wanted file filtering? Or depth limiting? Having it as a filtering toolkit lets you choose the exact filters you need for a given use case. walkdir.filtered_walk() is just an API for composing filtering pipelines without needing to pass the same information to multiple pipeline stages.

However, along with that itertools inspired iterator pipeline based design, I've also inherited Raymond's preference that particular *use cases* start life as recipes in the documentation.

A recursive glob is just a basic walkdir pipeline composition:

>>> from walkdir import file_paths, include_files
>>> def globtree(pattern, path='.'):
...     return file_paths(include_files(os.walk(path), pattern))
        
Since filtered_walk() is just a pipeline builder, the composition can also be written:

>>> from walkdir import file_paths, filtered_walk
>>> def globtree(pattern, path='.'):
...     return file_paths(filtered_walk(path, included_files=[pattern]))

That latter approach then suggests an alternative signature for globtree:

def globtree(*patterns, **kwds):
    kwds.setdefault("top", ".")
    return file_paths(filtered_walk(included_files=patterns, **kwds))

>>> print '\n'.join(sorted(globtree('*.rst')))
./index.rst
./py3k_binary_protocols.rst
./venv_bootstrap.rst

>>> print '\n'.join(sorted(globtree('*.rst', '*.py')))
./conf.py
./index.rst
./py3k_binary_protocols.rst
./venv_bootstrap.rst

On a somewhat related note, I'd also like to see us start concentrating higher level shell utilities in the shutil namespace so users don't have to check multiple locations for shell-related functionality quite so often (that is, I'd prefer shutil.globtree over glob.rglob).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 01:10:52 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Feb 2012 00:10:52 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328745470.26.0.684848904942.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328746083.3366.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> However, along with that itertools inspired iterator pipeline based
> design, I've also inherited Raymond's preference that particular *use
> cases* start life as recipes in the documentation.

I think it's important to remember where we are coming from. Many people
complain that using os.walk is too cumbersome. Proposing another
cumbersome solution doesn't really help.

So I'm not against walkdir *per se*, but I'm -1 on the idea that walkdir
can eliminate the need for practical functions that anybody can use
*easily*.

> >>> print '\n'.join(sorted(globtree('*.rst', '*.py')))
> ./conf.py
> ./index.rst
> ./py3k_binary_protocols.rst
> ./venv_bootstrap.rst

I think it's rather nice, but it should be available as a stdlib
function rather than a "recipe" in the documentation.

Recipes are really overrated: they aren't tested, they aren't
maintained, they aren't part of a module's docstrings or
(pydoc-generated) contents, it's not obvious what kind of quality you
can expect from them (do they handle all cases correctly), it's not
obvious which Python versions they support. Raymond may like the idea,
but that doesn't make it a "good practice" Python should follow for its
batteries.

> On a somewhat related note, I'd also like to see us start
> concentrating higher level shell utilities in the shutil namespace so
> users don't have to check multiple locations for shell-related
> functionality quite so often (that is, I'd prefer shutil.globtree over
> glob.rglob).

Well, if glob() already lived in shutil, this decision would be a
no-brainer :) Having glob() in the glob module and globtree() in the
shutil module, though, looks a bit weird.
(I agree having a separate module for glob isn't ideal)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 01:28:22 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Feb 2012 00:28:22 +0000
Subject: [issue13964] os.utimensat() and os.futimes() should accept Decimal,
	drop os.futimens()
In-Reply-To: <1328663994.2.0.189878263913.issue13964@psf.upfronthosting.co.za>
Message-ID: <1328747302.08.0.300667052924.issue13964@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

signal.sigtimedwait() API should also be changed from:
  sigtimedwait(sigset, (timeout_sec, timeout_nsec))
to:
  sigtimedwait(sigset, timeout)

where timeout can be an int, float or decimal.Decimal. The function was introduced in Python 3.3, so its API can be changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13964>
_______________________________________

From report at bugs.python.org  Thu Feb  9 01:40:24 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 09 Feb 2012 00:40:24 +0000
Subject: [issue13964] os.utimensat() and os.futimes() should accept Decimal,
	drop os.futimens()
In-Reply-To: <1328663994.2.0.189878263913.issue13964@psf.upfronthosting.co.za>
Message-ID: <1328748024.17.0.525588422343.issue13964@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Updated version of my suggestion:
os.futime(fd, (atime, mtime))
os.utime(path, (atime, mtime), flags=0)
os.utimeat(dirfd, path, (atime, mtime), flags=0)

atime and mtime could be int, float, decimal.Decimal or None.
All other os.*utime*() functions were introduced in 3.3, so they would be removed.
flags argument of os.utime() and os.utimeat() could be 0 or os.SYMLINK_NOFOLLOW.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13964>
_______________________________________

From report at bugs.python.org  Thu Feb  9 01:43:03 2012
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 09 Feb 2012 00:43:03 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1328748183.81.0.862852663063.issue1559549@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Brian, what is left for updating your patch? I'm going to need this to fix test_pydoc to not fail in my importlib bootstrap work so I can (finally) help with this. Is it just actually using the new features of the exception?

----------
assignee: brett.cannon -> brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Thu Feb  9 02:58:35 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 09 Feb 2012 01:58:35 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328752715.56.0.807425075019.issue13968@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

We do have the option of aliasing glob.iglob as shutil.glob...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 04:24:19 2012
From: report at bugs.python.org (Meador Inge)
Date: Thu, 09 Feb 2012 03:24:19 +0000
Subject: [issue13370] test_ctypes fails when building python with clang
In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za>
Message-ID: <1328757859.05.0.798292364481.issue13370@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> So perhaps as a temporary workaround, we could tweak setup.py to set
> -O0 for building ctypes with clang?

That would make the tests pass, but it still won't fix the fundamental 
issue.  clang and GCC have a difference in opinion as to when function
parameters and return values should be sign extended.  libffi follows
the GCC model.

I am talking to the LLVM folks right now to see why things are 
implemented this way.  Whether LLVM or libffi should be fixed depends
on the outcome of that discussion.

Due to this ABI difference compiling _ctypes with -O0 for clang will not
fix the problem because any ctypes code that interacts with C code that
was compiled by clang with optimizations has the potential to break just
like our test cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13370>
_______________________________________

From report at bugs.python.org  Thu Feb  9 05:10:30 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 09 Feb 2012 04:10:30 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1328760630.83.0.204863401001.issue11379@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Martin, do you find the wording I quoted (*without* the reference to a more Pythonic API) acceptable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Thu Feb  9 05:15:39 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 09 Feb 2012 04:15:39 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328760939.34.0.622108751484.issue13968@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

>> Well, if glob() already lived in shutil, this decision would be a
no-brainer :) Having glob() in the glob module and globtree() in the
shutil module, though, looks a bit weird.
(I agree having a separate module for glob isn't ideal)


Would it be feasible to deprecate the 'glob' module, moving its functionality to shutil? In some future Python version, then, the module can be removed.

The same fate would go for fnmatch, I guess. There are too many modules lying around dealing with the same problems.

On a related note, the doc of glob explicitly mentions that it is implemented with os.listdir and fnmatch. Similarly, *if* the recursive glob gets accepted it should be implemented with walkdir (once that's in).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 05:21:43 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 09 Feb 2012 04:21: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: <1328761303.65.0.306244984756.issue9257@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Eric,

Thanks for checking. I agree that this behavior is acceptable, but a documentation fix would be appropriate. The documentation of iterparse should mention the events it accepts, also saying that those are strings. 

The events are listed at http://effbot.org/zone/element-iterparse.htm

Would you like to try your hand at submitting a patch for Python 3.2? I will review and apply it to 3.2 and 3.3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9257>
_______________________________________

From report at bugs.python.org  Thu Feb  9 05:22:38 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 09 Feb 2012 04:22:38 +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: <1328761358.26.0.11783265401.issue9257@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Changing the target version(s) and adding some documentation experts to the nosy list

----------
nosy: +eric.araujo, ezio.melotti, sandro.tosi
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9257>
_______________________________________

From report at bugs.python.org  Thu Feb  9 05:32:57 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 09 Feb 2012 04:32:57 +0000
Subject: [issue1040439] Missing documentation on how to link with libpython
Message-ID: <1328761977.36.0.406346701453.issue1040439@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

ISTM that part of the doc specifically deals with Unix, so this issue can be closed as completed.

Windows is a different issue. Perhaps the documentation should have a new section on embedding on Windows, similarly to the "Building C and C++ Extensions on Windows" section in the "extending" documentation. Anyway, if there's interest in that, it should be a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040439>
_______________________________________

From report at bugs.python.org  Thu Feb  9 05:35:49 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 09 Feb 2012 04:35:49 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <1328762149.24.0.409781879709.issue11836@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Sandro, can you commit, taking Antoine's note into account?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11836>
_______________________________________

From report at bugs.python.org  Thu Feb  9 06:03:10 2012
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 09 Feb 2012 05:03:10 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1328763790.53.0.11450908532.issue1559549@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Yep, I just need to actually make use of the feature. I'll generate a new patch shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Thu Feb  9 09:16:28 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 09 Feb 2012 08:16:28 +0000
Subject: [issue13972] set and frozenset constructors don't accept multiple
	iterables
Message-ID: <1328775388.29.0.217148871947.issue13972@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

set.update() and friends accept multiple iterables. IMHO, set and frozenset constructors should, too.

----------
components: Interpreter Core
messages: 152931
nosy: petri.lehtinen
priority: normal
severity: normal
status: open
title: set and frozenset constructors don't accept multiple iterables
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13972>
_______________________________________

From report at bugs.python.org  Thu Feb  9 09:22:37 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 09 Feb 2012 08:22:37 +0000
Subject: [issue13973] urllib.parse is imported twice in xmlrpc.client
Message-ID: <1328775757.49.0.00418569487883.issue13973@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

urllib.parse is imported twice in xmlrpc.client, and it also breaks pep8

----------
components: Library (Lib)
files: duplicate-imports.patch
keywords: patch
messages: 152932
nosy: tshepang
priority: normal
severity: normal
status: open
title: urllib.parse is imported twice in xmlrpc.client
versions: Python 3.3
Added file: http://bugs.python.org/file24462/duplicate-imports.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13973>
_______________________________________

From report at bugs.python.org  Thu Feb  9 09:24:35 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 09 Feb 2012 08:24:35 +0000
Subject: [issue13974] packaging: test for set_platform()
Message-ID: <1328775875.69.0.230962367845.issue13974@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

slightly increases test coverage

----------
assignee: tarek
components: Distutils2
files: test-set-platform.patch
keywords: patch
messages: 152933
nosy: alexis, eric.araujo, tarek, tshepang
priority: normal
severity: normal
status: open
title: packaging: test for set_platform()
versions: Python 3.3
Added file: http://bugs.python.org/file24463/test-set-platform.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13974>
_______________________________________

From report at bugs.python.org  Thu Feb  9 09:29:06 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 09 Feb 2012 08:29:06 +0000
Subject: [issue13975] packaging: change_root() test for os2
Message-ID: <1328776146.47.0.653545071003.issue13975@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

increases coverage a bit

----------
assignee: tarek
components: Distutils2
files: test-change_root-in-os2.patch
keywords: patch
messages: 152934
nosy: alexis, eric.araujo, tarek, tshepang
priority: normal
severity: normal
status: open
title: packaging: change_root() test for os2
versions: Python 3.3
Added file: http://bugs.python.org/file24464/test-change_root-in-os2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13975>
_______________________________________

From report at bugs.python.org  Thu Feb  9 10:27:05 2012
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 09 Feb 2012 09:27:05 +0000
Subject: [issue13972] set and frozenset constructors don't accept multiple
	iterables
In-Reply-To: <1328775388.29.0.217148871947.issue13972@psf.upfronthosting.co.za>
Message-ID: <1328779625.32.0.399916522537.issue13972@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/issue13972>
_______________________________________

From report at bugs.python.org  Thu Feb  9 10:44:53 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 09 Feb 2012 09:44:53 +0000
Subject: [issue6005] Bug in socket example
In-Reply-To: <1242137945.24.0.461546436751.issue6005@psf.upfronthosting.co.za>
Message-ID: <E1RvQYZ-0005mb-8U@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset aa6415d1e160 by Senthil Kumaran in branch '2.7':
Fix Issue #6005: Examples in the socket library documentation use sendall,
http://hg.python.org/cpython/rev/aa6415d1e160

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6005>
_______________________________________

From report at bugs.python.org  Thu Feb  9 10:56:31 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 09 Feb 2012 09:56:31 +0000
Subject: [issue6005] Bug in socket example
In-Reply-To: <1242137945.24.0.461546436751.issue6005@psf.upfronthosting.co.za>
Message-ID: <E1RvQju-00070u-Di@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2aae44aa041a by Senthil Kumaran in branch '3.2':
Fix Issue #6005: Examples in the socket library documentation use sendall,
http://hg.python.org/cpython/rev/2aae44aa041a

New changeset e9c3df45920e by Senthil Kumaran in branch 'default':
merged from 3.2
http://hg.python.org/cpython/rev/e9c3df45920e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6005>
_______________________________________

From report at bugs.python.org  Thu Feb  9 10:57:26 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 09 Feb 2012 09:57:26 +0000
Subject: [issue6005] Bug in socket example
In-Reply-To: <1242137945.24.0.461546436751.issue6005@psf.upfronthosting.co.za>
Message-ID: <1328781446.23.0.13475545842.issue6005@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Thanks for patches. This is fixed.

----------
nosy: +orsenthil
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6005>
_______________________________________

From report at bugs.python.org  Thu Feb  9 11:23:00 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 09 Feb 2012 10:23:00 +0000
Subject: [issue9021] no copy.copy problem description
In-Reply-To: <1276816713.34.0.416523004663.issue9021@psf.upfronthosting.co.za>
Message-ID: <E1RvR9X-0001JE-AV@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0e050b38e92b by Senthil Kumaran in branch '2.7':
Issue #9021: Add an introduction to the copy module. Doc changes suggested by Terry Reedy.
http://hg.python.org/cpython/rev/0e050b38e92b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9021>
_______________________________________

From report at bugs.python.org  Thu Feb  9 11:28:07 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 09 Feb 2012 10:28:07 +0000
Subject: [issue9021] no copy.copy problem description
In-Reply-To: <1276816713.34.0.416523004663.issue9021@psf.upfronthosting.co.za>
Message-ID: <E1RvREU-0001rm-7w@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a352e24b9907 by Senthil Kumaran in branch '3.2':
Issue #9021 - Introduce copy module better. Doc changes suggested by Terry
http://hg.python.org/cpython/rev/a352e24b9907

New changeset bf6f306ad5cf by Senthil Kumaran in branch 'default':
merge from 3.2
http://hg.python.org/cpython/rev/bf6f306ad5cf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9021>
_______________________________________

From report at bugs.python.org  Thu Feb  9 11:29:15 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 09 Feb 2012 10:29:15 +0000
Subject: [issue9021] no copy.copy problem description
In-Reply-To: <1276816713.34.0.416523004663.issue9021@psf.upfronthosting.co.za>
Message-ID: <1328783355.82.0.11598382993.issue9021@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Added suggested changes to the documentation. Thanks.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9021>
_______________________________________

From report at bugs.python.org  Thu Feb  9 11:38:52 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 09 Feb 2012 10:38:52 +0000
Subject: [issue9021] no copy.copy problem description
In-Reply-To: <1276816713.34.0.416523004663.issue9021@psf.upfronthosting.co.za>
Message-ID: <1328783932.51.0.082441750152.issue9021@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Perfectionist in me says that now copy.copy theory should be diluted with examples for those who can't grasp the concept of "binding of variables", but the patch perfectly covers the original user story. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9021>
_______________________________________

From report at bugs.python.org  Thu Feb  9 12:16:34 2012
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 09 Feb 2012 11:16:34 +0000
Subject: [issue13903] New shared-keys dictionary implementation
In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za>
Message-ID: <1328786194.75.0.253325368214.issue13903@psf.upfronthosting.co.za>


Changes by Mark Shannon <mark at hotpy.org>:


Added file: http://bugs.python.org/file24465/e50db1b7ad7b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13903>
_______________________________________

From report at bugs.python.org  Thu Feb  9 12:18:43 2012
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 09 Feb 2012 11:18:43 +0000
Subject: [issue13903] New shared-keys dictionary implementation
In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za>
Message-ID: <1328786323.22.0.331729869622.issue13903@psf.upfronthosting.co.za>


Changes by Mark Shannon <mark at hotpy.org>:


Removed file: http://bugs.python.org/file24456/20702d1acf17.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13903>
_______________________________________

From report at bugs.python.org  Thu Feb  9 12:37:19 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 09 Feb 2012 11:37:19 +0000
Subject: [issue13590] extension module builds fail with python.org OS X
	installers on OS X 10.7 and 10.6 with Xcode 4.2
In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za>
Message-ID: <1328787439.04.0.0348996795836.issue13590@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

distutils would not only have to check for gcc-4.2 vs. clang, but also needs to strip "-arch ppc" from the compiler flags when it is present and it cannot use gcc-4.2.   Otherwise you cannot build extensions for the 32-bit python installer on OSX 10.7 with Xcode 4.2.

It is sadly enough not possible to create a binary installer that creates a working installation including building of extensions on all supported versions of OSX without adding special-case code to distutils/packaging.

Note that there already is some special-case code to support the universal binary builds on OSX 10.3.9 (which does not have a compiler that can build universal binaries).


W.r.t. the patch: is it really necessary to use a subshell to look for the compiler? I'd either walk os.environ['PATH'] myself or use xcodebuild to locate binaries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13590>
_______________________________________

From report at bugs.python.org  Thu Feb  9 13:07:40 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 09 Feb 2012 12:07:40 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328789260.2.0.382692841295.issue13968@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This discussion (particularly my final globtree recipe) made me realise that the exact same approach would greatly improve the usability of the all_paths, file_paths and dir_paths iterators in walkdir [1]. Accordingly, walkdir 0.4 will let you write a recursive grep for ReST and Python source files as:

    file_paths(top, included_files="*.py *.rst".split())

Scanning multiple directories will be as simple as:

    file_paths(dir1, dir2, included_files="*.py *.rst".split())

[1] https://bitbucket.org/ncoghlan/walkdir/issue/15

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 13:56:27 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Thu, 09 Feb 2012 12:56:27 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1328792187.24.0.58688620761.issue10287@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

I think I've fixed it to do as described. Alas, I have no Easynews account to test it (I mailed their support about that so maybe that'll change).

Would someone with an account mind to test, if it works? Nathan?

----------
Added file: http://bugs.python.org/file24466/nntp-retry-capas-after-login.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10287>
_______________________________________

From report at bugs.python.org  Thu Feb  9 15:08:19 2012
From: report at bugs.python.org (Yuval Greenfield)
Date: Thu, 09 Feb 2012 14:08:19 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328796499.25.0.569771001948.issue13968@psf.upfronthosting.co.za>


Yuval Greenfield <ubershmekel at gmail.com> added the comment:

Thanks for the bug find Antoine, I worked surprisingly hard trying to make this right in more edge cases and while fixing it I noticed rglob/globtree has 3 options:

* Behave like a glob for every subdirectory. Meaning that every relative path gets a '*/' prepended to it. Eg rglob('c/d') started from the directory 'a' will yield 'a/b/c/d'.

* Behave like a glob for every subdirectory of the directory in the filter string. Meaning rglob('c/d') from dir 'a' won't yield 'a/b/c/d'. It would try to walk from 'a/c' and yield nothing if the directory 'c' doesn't exist in 'a'. Note that if the directory 'c' does exist then '/a/c/f/d' would be yielded. That seems kind of quirky to me.

* Behave like a filtered walk. Meaning that in order to yield files nested in subdirectories a wildcard must be introduced. Eg rglob('c/d') started from the directory 'a' won't yield 'a/b/c/d'. For that to occur you would need to use rglob('*c/d') or rglob('*/c/d'). What's more unfortunate is that rglob('d') doesn't yield 'a/b/c/d' which seems wrong. So I think for this we should special case paths that don't have path separators and prepend the "*/". Though some may argue it's wrong that rglob('d') yields 'a/b/c/d' even though rglob('c/d') won't yield it, I think that's the correct choice for this route.

Note that absolute paths with/without wildcards don't have this ambiguity. In both rel/abs wildcards should match directories and files alike.

Which option do you guys think would be best? I already have a fixed patch for option 1 and 3 but I'd rather hear your thoughts before I introduce either.



P.s. another slight issue I ran into is the fact that fnmatch doesn't ignore os.curdir:

    >>> fnmatch.fnmatch('./a', 'a')
    False

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 15:49:54 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Feb 2012 14:49:54 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328798994.84.0.239766839673.issue13968@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I have to say that the non-obvious subtleties you point out in your rglob make me think I personally would probably opt to use Nick's module directly instead, so that I was sure what I was getting.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 16:07:18 2012
From: report at bugs.python.org (Dima Tisnek)
Date: Thu, 09 Feb 2012 15:07:18 +0000
Subject: [issue13976] threading.local doesn't support super()
Message-ID: <1328800038.58.0.378315403366.issue13976@psf.upfronthosting.co.za>


New submission from Dima Tisnek <dimaqq at gmail.com>:

import threading
import pprint


class A:
    def __init__(self, **kw):
        pprint.pprint("a")
        super(A, self).__init__()


class B(threading.local, A):
    def __init__(self, **kw):
        pprint.pprint("b")
        super(B, self).__init__()

if __name__ == "__main__":
    B()



breaks (prints only b) in python 2. tested 2.7.2

works (prints b, a) in python 3, tested 3.2.2

threading.local is before A on purpose, to have different A attribute in different threads, not shown in the example.

caveat implementor: it may be impossible to support both super().__init__ and explicit threading.local.__init__ at the same time; explicit initialization is used far and wide in legacy code.

----------
components: None
messages: 152947
nosy: Dima.Tisnek, pitrou
priority: normal
severity: normal
status: open
title: threading.local doesn't support super()
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13976>
_______________________________________

From report at bugs.python.org  Thu Feb  9 16:14:35 2012
From: report at bugs.python.org (Dima Tisnek)
Date: Thu, 09 Feb 2012 15:14:35 +0000
Subject: [issue13976] threading.local doesn't support super()
In-Reply-To: <1328800038.58.0.378315403366.issue13976@psf.upfronthosting.co.za>
Message-ID: <1328800475.64.0.822035921326.issue13976@psf.upfronthosting.co.za>


Dima Tisnek <dimaqq at gmail.com> added the comment:

ah feeling stupid only minutes later.
A has to inherit from object() and then it works fine.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13976>
_______________________________________

From report at bugs.python.org  Thu Feb  9 16:18:24 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 09 Feb 2012 15:18:24 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328798994.84.0.239766839673.issue13968@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda-2TUPwqFpe+tDTR1sYy4tJYNz=-OEpB371MFmDrd919A@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

> I have to say that the non-obvious subtleties you point out in your rglob make me think I personally would probably opt to use Nick's module directly instead, so that I was sure what I was getting.
>
> ----------

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 16:31:53 2012
From: report at bugs.python.org (Yuval Greenfield)
Date: Thu, 09 Feb 2012 15:31:53 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328801513.05.0.119266272911.issue13968@psf.upfronthosting.co.za>


Yuval Greenfield <ubershmekel at gmail.com> added the comment:

> I have to say that the non-obvious subtleties you point out in your rglob make me think I personally would probably opt to use Nick's module directly instead, so that I was sure what I was getting.

I didn't notice these corner cases initially because of their distance from the main use case. The main use-case is to glob the current directory or an absolute path tree using a wildcard, esp for finding all files of a given type. This leaves no ambiguity.

I'd like the edge cases of relative paths to behave in a documented and sensible way, but they pale in comparison to the usefulness of the proposal imho.

I believe we should decide what's the most useful and sensible behavior and have a shortcut for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 16:40:32 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Feb 2012 15:40:32 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328802032.09.0.836840743431.issue13968@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  Just to make it clear where I'm coming from, though, I should also point out that I use rdiff-backup, which uses the **/yadayada syntax, and I hate it any time I have to try to figure out what such a glob is going to actually match.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 16:46:55 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Feb 2012 15:46:55 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328796499.25.0.569771001948.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328802247.3352.17.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> * Behave like a glob for every subdirectory. Meaning that every
> relative path gets a '*/' prepended to it. Eg rglob('c/d') started
> from the directory 'a' will yield 'a/b/c/d'.

That's what I would expect. That way, rglob('__init__.py') would find
all files named __init__.py beneath the current directory.

> P.s. another slight issue I ran into is the fact that fnmatch doesn't
> ignore os.curdir:
> 
>     >>> fnmatch.fnmatch('./a', 'a')
>     False

Sounds ok. fnmatch is a low-level lexical thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 17:03:46 2012
From: report at bugs.python.org (Yuval Greenfield)
Date: Thu, 09 Feb 2012 16:03:46 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328803426.08.0.366258891075.issue13968@psf.upfronthosting.co.za>


Yuval Greenfield <ubershmekel at gmail.com> added the comment:

>> * Behave like a glob for every subdirectory. Meaning that every
>> relative path gets a '*/' prepended to it. Eg rglob('c/d') started
>> from the directory 'a' will yield 'a/b/c/d'.

> That's what I would expect. That way, rglob('__init__.py') would
> find all files named __init__.py beneath the current directory.

Perhaps we should make a single exemption for double dots eg rglob('../../__init__.py') starts the walk 2 folders out of the curdir and looks for '*/__init__.py'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 17:04:30 2012
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 09 Feb 2012 16:04:30 +0000
Subject: [issue13958] Comment _PyUnicode_FromId
In-Reply-To: <1328562481.37.0.963430075051.issue13958@psf.upfronthosting.co.za>
Message-ID: <1328803470.45.0.122109585369.issue13958@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at gmail.com> added the comment:

After clarification, the original change was backed out.

These are C Identifiers, and nothing beyond ASCII is guaranteed, but other characters are in practice possible.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13958>
_______________________________________

From report at bugs.python.org  Thu Feb  9 17:16:54 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Feb 2012 16:16:54 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328803426.08.0.366258891075.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328804044.3352.19.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> >> * Behave like a glob for every subdirectory. Meaning that every
> >> relative path gets a '*/' prepended to it. Eg rglob('c/d') started
> >> from the directory 'a' will yield 'a/b/c/d'.
> 
> > That's what I would expect. That way, rglob('__init__.py') would
> > find all files named __init__.py beneath the current directory.
> 
> Perhaps we should make a single exemption for double dots eg
> rglob('../../__init__.py') starts the walk 2 folders out of the curdir
> and looks for '*/__init__.py'.

This would be quirky. I don't think '..' should be treated specially.
(there's also the symlinks problem)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 17:18:10 2012
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 09 Feb 2012 16:18:10 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
In-Reply-To: <1328763790.53.0.11450908532.issue1559549@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W7Mz7=+GvhUN7aB--hsi8ZOoBU1cbdPPfSydLm-2KSkEg@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Thu, Feb 9, 2012 at 00:03, Brian Curtin <report at bugs.python.org> wrote:

>
> Brian Curtin <brian at python.org> added the comment:
>
> Yep, I just need to actually make use of the feature. I'll generate a new
> patch shortly.
>

If you can generate it before 17:30 EST today I can review it or at least
help use it in the codebase.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Thu Feb  9 17:27:02 2012
From: report at bugs.python.org (Yuval Greenfield)
Date: Thu, 09 Feb 2012 16:27:02 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328804822.85.0.876588316612.issue13968@psf.upfronthosting.co.za>


Yuval Greenfield <ubershmekel at gmail.com> added the comment:

> This would be quirky. I don't think '..' should be treated specially.
> (there's also the symlinks problem)

Again with 'a/b/c/d' and let's add a file 'a/b/png'.

If the curdir is 'c' and you use rglob('../pn*') you won won't find '../png' as you would be walking only in the curdir. I think that route would mean we should document double dots aren't supported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 17:30:34 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Feb 2012 16:30:34 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328804822.85.0.876588316612.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328804865.3352.22.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Again with 'a/b/c/d' and let's add a file 'a/b/png'.
> 
> If the curdir is 'c' and you use rglob('../pn*') you won won't find
> '../png' as you would be walking only in the curdir.

That depends how you implement it. If you detect that ".." exists and
glob for "pn*" inside it, you will probably find "../png".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 17:35:02 2012
From: report at bugs.python.org (Yuval Greenfield)
Date: Thu, 09 Feb 2012 16:35:02 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328805302.48.0.080403586215.issue13968@psf.upfronthosting.co.za>


Yuval Greenfield <ubershmekel at gmail.com> added the comment:

> That depends how you implement it. If you detect that ".." exists and
glob for "pn*" inside it, you will probably find "../png".

Yes, that's what I meant by a "single exemption for double dots". The solution should start the walk from wherever the double dots lead it to.

I believe we agree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 17:36:46 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Feb 2012 16:36:46 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328805302.48.0.080403586215.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328805236.3352.23.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Yes, that's what I meant by a "single exemption for double dots". The
> solution should start the walk from wherever the double dots lead it
> to.

I don't think that's a single exemption; you should use the same
algorithm for all globs (e.g. "a/*.py"), shouldn't you?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 17:45:18 2012
From: report at bugs.python.org (Paul Moore)
Date: Thu, 09 Feb 2012 16:45:18 +0000
Subject: [issue13175] packaging uses wrong line endings in RECORD files on
	Windows
In-Reply-To: <1318546022.2.0.0477576720396.issue13175@psf.upfronthosting.co.za>
Message-ID: <1328805918.78.0.877976158468.issue13175@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

Any progress on this one?

I tried to reproduce using distutils2, but don't know how distutils2 works - there's no pysetup and python -m distutils2.run doesn't work the same as python -m packaging.run.

Can we at least get packaging working in time for 3.3, even if it leaves an issue with distutils2 to sort out?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13175>
_______________________________________

From report at bugs.python.org  Thu Feb  9 17:46:39 2012
From: report at bugs.python.org (Yuval Greenfield)
Date: Thu, 09 Feb 2012 16:46:39 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328805999.5.0.49134986629.issue13968@psf.upfronthosting.co.za>


Yuval Greenfield <ubershmekel at gmail.com> added the comment:

> you should use the same algorithm for all globs (e.g. "a/*.py"), shouldn't you?

That specific string would start the walk from the current directory IIUC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 17:47:01 2012
From: report at bugs.python.org (Paul Moore)
Date: Thu, 09 Feb 2012 16:47:01 +0000
Subject: [issue13189] New bdist_simple binary distribution format for packaging
In-Reply-To: <1318775392.19.0.757483007173.issue13189@psf.upfronthosting.co.za>
Message-ID: <1328806021.53.0.247749470018.issue13189@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

We're running a bit lower on time now. Any progress? The whole discussion on python-dev around binary formats petered out with no real conclusions :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13189>
_______________________________________

From report at bugs.python.org  Thu Feb  9 17:47:59 2012
From: report at bugs.python.org (Paul Moore)
Date: Thu, 09 Feb 2012 16:47:59 +0000
Subject: [issue13123] bdist_wininst uninstaller does not remove pycache
	directories
In-Reply-To: <1318000960.21.0.140069466315.issue13123@psf.upfronthosting.co.za>
Message-ID: <1328806079.05.0.839656638066.issue13123@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

Have you had a chance to look at this yet?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13123>
_______________________________________

From report at bugs.python.org  Thu Feb  9 17:53:51 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Feb 2012 16:53:51 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328805999.5.0.49134986629.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328806262.3352.24.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > you should use the same algorithm for all globs (e.g. "a/*.py"), shouldn't you?
> 
> That specific string would start the walk from the current directory IIUC.

Yes but would it match b/a/setup.py?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 18:39:18 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Feb 2012 17:39:18 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328809158.83.0.583532730185.issue13968@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

How about having separate starting path and glob arguments, where the glob cannot contain any directory?

I'm -1 on this function as it stands.  My vote could change if the final semantics are intuitive and unambiguous.  (It's OK if getting the correct intuition requires understanding a brief explanation.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 18:42:25 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 09 Feb 2012 17:42:25 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1328809345.16.0.0838064966522.issue4356@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

On python-ideas, thread "Optional key to `bisect`'s functions?" Guido wrote "Bingo. That clinches it. We need to add key=." 'That' being the fact that values that have keys may not be comparable themselves (in py3), so that comparing (key,value) pairs may raise TypeError. This follows a reply by him yesterday saying that he has wanted this feature occasionally. I am re-opening this rather than a new issue because there is already a patch with tests.

----------
components: +Library (Lib) -Documentation
nosy: +gvanrossum
priority: low -> normal
resolution: fixed -> 
stage:  -> patch review
status: closed -> open
versions: +Python 3.3 -Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Thu Feb  9 18:44:10 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Feb 2012 17:44:10 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328809158.83.0.583532730185.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328809281.3352.26.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> My vote could change if the final semantics are intuitive and unambiguous.

How about "match the given glob from this directory and any
sub-directory"?
That sounds quite intuitive and unambiguous to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 18:48:59 2012
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 09 Feb 2012 17:48:59 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1328809739.85.0.338837997728.issue4356@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I'm +1 on adding this feature. See discussion in python-ideas.

PS. It should also be added to heapq.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Thu Feb  9 18:53:55 2012
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 09 Feb 2012 17:53:55 +0000
Subject: [issue13977] importlib simplification
Message-ID: <1328810035.88.0.967764974247.issue13977@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at gmail.com>:

http://hg.python.org/cpython/file/aba513307f78/Lib/importlib/_bootstrap.py#l974


  974     # The hell that is fromlist ...
  975     if not fromlist:
  976         # Return up to the first dot in 'name'. This is
complicated by the fact
  977         # that 'name' may be relative.
  978         if level == 0:
  979             return sys.modules[name.partition('.')[0]]
  980         elif not name:
  981             return module
  982         else:
  983             cut_off = len(name) - len(name.partition('.')[0])
  984             return sys.modules[module.__name__[:-cut_off]]

If level is 0, should name == module.__name__?

Yes.
 

If so, then I think that simplifies to

   if not name:
       return module
   genericname=module.__name__.rpartition(".")[0]
   return sys.modules[genericname]

Seems right. Can you file a bug and assign it to me?

----------
messages: 152970
nosy: Jim.Jewett, brett.cannon
priority: normal
severity: normal
status: open
title: importlib simplification

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13977>
_______________________________________

From report at bugs.python.org  Thu Feb  9 18:55:16 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 09 Feb 2012 17:55:16 +0000
Subject: [issue13977] importlib simplification
In-Reply-To: <1328810035.88.0.967764974247.issue13977@psf.upfronthosting.co.za>
Message-ID: <1328810116.79.0.105414727355.issue13977@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> brett.cannon
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13977>
_______________________________________

From report at bugs.python.org  Thu Feb  9 19:03:56 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Feb 2012 18:03:56 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328810636.02.0.0343959296017.issue13968@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

So given

  /home/a
  /home/a/k.py
  /home/a/c/j.py
  /home/b/z.py
  /home/b/c/f.py

and a current directory of /home/a, we'd have:

   pattern   matches
   -------   -------
   *.py      k.py, c/j.py
   c/*.py    c/j.py
   c*        c               [?]
   ../*.py   ?
   ../c/*.py ?

Thinking about those .. cases makes my brain hurt :)  What does it mean to match '../*.py' when I'm recursing into the c subdirectory?  What does it mean in the current directory, for that matter?

As you can see, your short explanation has left me with one case where I have a question, and one set of cases where my intuition completely fails.

--David

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 19:24:08 2012
From: report at bugs.python.org (=?utf-8?q?Javier_Jard=C3=B3n?=)
Date: Thu, 09 Feb 2012 18:24:08 +0000
Subject: [issue13978] OSError exception in multiprocessing module when using
	os.remove() on NFS
Message-ID: <1328811848.71.0.527301304196.issue13978@psf.upfronthosting.co.za>


New submission from Javier Jard?n <jjardon at gnome.org>:

I have this little test case:

import multiprocessing
 
manager = multiprocessing.Manager()
del manager

and I get this:

Traceback (most recent call last):
  File "/usr/lib/python2.7/multiprocessing/util.py", line 261, in _run_finalizers
    finalizer()
  File "/usr/lib/python2.7/multiprocessing/util.py", line 200, in __call__
    res = self._callback(*self._args, **self._kwargs)
  File "/usr/lib/python2.7/shutil.py", line 249, in rmtree
    onerror(os.remove, fullname, sys.exc_info())
  File "/usr/lib/python2.7/shutil.py", line 247, in rmtree
    os.remove(fullname)
OSError: [Errno 16] Device or resource busy: '/nfs/tmp/pymp-f7R9S6/.nfs00000000e039692f00000236'

(the TMDIR directory is in a nfs server)

----------
components: Extension Modules
messages: 152972
nosy: jjardon
priority: normal
severity: normal
status: open
title: OSError exception in multiprocessing module when using os.remove() on NFS
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13978>
_______________________________________

From report at bugs.python.org  Thu Feb  9 19:24:37 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 09 Feb 2012 18:24:37 +0000
Subject: [issue8184] multiprocessing.managers will not fail if listening ocket
	already in use
In-Reply-To: <1269104932.24.0.802901286813.issue8184@psf.upfronthosting.co.za>
Message-ID: <1328811877.7.0.970217667817.issue8184@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Committed to default.
I won't backport it to other branches, since it's more of a feature request than a bug fix.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8184>
_______________________________________

From report at bugs.python.org  Thu Feb  9 20:00:00 2012
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 09 Feb 2012 19:00:00 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1328814000.2.0.314352858465.issue1559549@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Here's an updated patch which creates two convenience functions, PyErr_SetFromImportErrorWithName and PyErr_SetFromImportErrorWithNameAndPath. I figure the two common cases are that you'll want to set just a name or you'll want a name and a path.

*WithName is all that I've applied for now, and I've only done it in import.c to allow Brett to continue with his work. I'll come back and make changes elsewhere in the code, and I'll apply the *WithNameAndPath function where I need it for #10854.

All tests pass and some IRL testing works nicely.

Note: I'm a little rushed at the moment so I have not included docs but I will surely update them. I just want to get Brett what he needs by this afternoon.

----------
Added file: http://bugs.python.org/file24467/issue1559549_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Thu Feb  9 20:11:08 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 09 Feb 2012 19:11:08 +0000
Subject: [issue13921] sqlite3: OptimizedUnicode obsolete in Py3k
In-Reply-To: <1328129858.32.0.164852943165.issue13921@psf.upfronthosting.co.za>
Message-ID: <E1RvZOd-00020r-4r@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0fc10a33eb4c by Petri Lehtinen in branch 'default':
Undocument and clean up sqlite3.OptimizedUnicode
http://hg.python.org/cpython/rev/0fc10a33eb4c

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13921>
_______________________________________

From report at bugs.python.org  Thu Feb  9 20:13:15 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 09 Feb 2012 19:13:15 +0000
Subject: [issue13921] sqlite3: OptimizedUnicode obsolete in Py3k
In-Reply-To: <1328129858.32.0.164852943165.issue13921@psf.upfronthosting.co.za>
Message-ID: <1328814795.76.0.69979871579.issue13921@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Committed the patch after moving the documentation note to a source code comment instead. Thanks for reviews.

----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13921>
_______________________________________

From report at bugs.python.org  Thu Feb  9 20:37:46 2012
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 09 Feb 2012 19:37:46 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1328816266.09.0.684404358148.issue1559549@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Thanks, Brian! I'll do a review tonight on the drive home (and maybe even write the docs up).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Thu Feb  9 20:52:09 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 09 Feb 2012 19:52:09 +0000
Subject: [issue13961] Have importlib use os.replace()
In-Reply-To: <1328624796.15.0.577971130856.issue13961@psf.upfronthosting.co.za>
Message-ID: <1328817129.29.0.228047041022.issue13961@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
keywords: +needs review, patch
stage:  -> patch review
Added file: http://bugs.python.org/file24468/importlib_replace.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13961>
_______________________________________

From report at bugs.python.org  Thu Feb  9 21:03:00 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Feb 2012 20:03:00 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1328817780.57.0.873158354857.issue1559549@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

On the drive home...are you borrowing one of Google's self driving cars? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Thu Feb  9 21:16:44 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 09 Feb 2012 20:16:44 +0000
Subject: [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>
Message-ID: <1328818604.3.0.0946249859951.issue13491@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attaching an updated patch with the following changes:

- Updated to apply on current default branch

- No examples included in the documentation now require createdb.py to be run. There were only three examples that required it, but these were refactored a bit. In the Doc/includes/sqlite3 directory there are still some scripts that require the createdb.py, so I didn't nuke the file.

- I also removed the strange "The arguments to :meth:`executescript` must be :func:`bytes` objects" sentence from the patch. I assume it was a mistake, as it's wrong.

----------
Added file: http://bugs.python.org/file24469/sqlite_code_update_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13491>
_______________________________________

From report at bugs.python.org  Thu Feb  9 21:17:41 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 09 Feb 2012 20:17:41 +0000
Subject: [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>
Message-ID: <1328818661.05.0.175873319468.issue13491@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Ah, and I added a working example of a custom text_factory function to Doc/includes/sqlite3/text_factory.py, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13491>
_______________________________________

From report at bugs.python.org  Thu Feb  9 21:21:28 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 09 Feb 2012 20:21:28 +0000
Subject: [issue13965] Windows 64-bit installer actually installing a 32-bit
	version
In-Reply-To: <1328666235.95.0.56390698095.issue13965@psf.upfronthosting.co.za>
Message-ID: <1328818888.87.0.357465270796.issue13965@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Martin, thanks for the explanation.

Hopefully, this tracker entry will serve to permanently document why Python2 on Windows behaves as it does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13965>
_______________________________________

From report at bugs.python.org  Thu Feb  9 21:36:29 2012
From: report at bugs.python.org (Yuval Greenfield)
Date: Thu, 09 Feb 2012 20:36:29 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328819789.21.0.978217887905.issue13968@psf.upfronthosting.co.za>


Yuval Greenfield <ubershmekel at gmail.com> added the comment:

Given

  /home/a
  /home/a/k.py
  /home/a/c/j.py
  /home/b/z.py
  /home/b/c/f.py

and a current directory of /home/a, we'd have:

   pattern     matches
   -------     -------
   *.py        k.py, c/j.py
   c/*.py      c/j.py
   c*          c
   ../*.py     ../a/k.py, ../a/c/j.py, ../b/z.py, ../b/c/f.py
   ../c/*.py   ../b/c/f.py, ../a/c/j.py

For relative paths the double dots decide where to start walking and from then on you can imagine a glob on every subdir. In the last 2 examples the glob would have been '*.py' and 'c/*.py' respectively.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 21:39:31 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 09 Feb 2012 20:39:31 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1328819971.32.0.869570995288.issue4356@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Already on tracker as
#13742 Add a key parameter (like sorted) to heapq.merge

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Thu Feb  9 21:39:38 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 09 Feb 2012 20:39:38 +0000
Subject: [issue13742] Add a key parameter (like sorted) to heapq.merge
In-Reply-To: <1326105342.42.0.0197399269422.issue13742@psf.upfronthosting.co.za>
Message-ID: <1328819978.84.0.351005756287.issue13742@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

FWIW, Guido approves of the idea, msg152969 in #4356

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13742>
_______________________________________

From report at bugs.python.org  Thu Feb  9 21:47:13 2012
From: report at bugs.python.org (Tim Lesher)
Date: Thu, 09 Feb 2012 20:47:13 +0000
Subject: [issue11620] winsound.PlaySound() with SND_MEMORY should accept bytes
	instead of strings
In-Reply-To: <1300667681.04.0.269037633009.issue11620@psf.upfronthosting.co.za>
Message-ID: <1328820433.2.0.0182196705886.issue11620@psf.upfronthosting.co.za>


Tim Lesher <tlesher at gmail.com> added the comment:

This patch should both correct the incorrect acceptance of strings and the incorrect rejection of buffer objects when using SND_MEMORY.

----------
keywords: +patch
Added file: http://bugs.python.org/file24470/11620-PlaySound.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11620>
_______________________________________

From report at bugs.python.org  Thu Feb  9 21:49:21 2012
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 09 Feb 2012 20:49:21 +0000
Subject: [issue11620] winsound.PlaySound() with SND_MEMORY should accept bytes
	instead of strings
In-Reply-To: <1300667681.04.0.269037633009.issue11620@psf.upfronthosting.co.za>
Message-ID: <1328820561.51.0.128649806531.issue11620@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
assignee:  -> brian.curtin
keywords: +needs review
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11620>
_______________________________________

From report at bugs.python.org  Thu Feb  9 22:01:05 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Feb 2012 21:01:05 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328821265.89.0.813404517248.issue13968@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, in that case I would expect that the argument 'c/*.py' would start walking in the c directory, but I definitely did not get that impression from Antoine's explanation of how the function works.

I again advocate separating the starting path specification from the glob specification, with the latter not allowing directories.  A two argument function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 22:07:45 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Thu, 09 Feb 2012 21:07:45 +0000
Subject: [issue13953] Get rid of doctests in packaging.tests.test_version
In-Reply-To: <1328554740.27.0.167211242761.issue13953@psf.upfronthosting.co.za>
Message-ID: <1328821665.03.0.478786108862.issue13953@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

I've done some cleanups

----------
Added file: http://bugs.python.org/file24471/issue13953_bf6f306ad5cf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13953>
_______________________________________

From report at bugs.python.org  Thu Feb  9 22:10:08 2012
From: report at bugs.python.org (David Goulet)
Date: Thu, 09 Feb 2012 21:10:08 +0000
Subject: [issue13979] Automatic *libc.so loading behaviour
Message-ID: <1328821808.41.0.811189579105.issue13979@psf.upfronthosting.co.za>


New submission from David Goulet <dgoulet at efficios.com>:

I'm working with the LTTng (Linux Tracing) team and we came across a problem with our user-space tracer and Python default behaviour. We provide a libc wrapper that instrument free() and malloc() and is usable with a simple LD_PRELOAD.

This lib *was* named "liblttng-ust-libc.so" and we came across python software registering to our trace registry daemon (meaning that somehow the python binary is using our in-process library). We dig a bit and found this:

Lib/ctypes/utils.py:

def _findLib_ldconfig(name):
       # XXX assuming GLIBC's ldconfig (with option -p)
       expr = r'/[^\(\)\s]*lib%s\.[^\(\)\s]*' % re.escape(name)
       res = re.search(expr,
                       os.popen('/sbin/ldconfig -p 2>/dev/null').read())

and, at least, also found in _findLib_gcc(name) and _findSoname_ldconfig(name).

This cause Python to use any library ending with "libc.so" to be loaded....

I don't know the reasons behind this but we are concerned about "future issues" with this kind of behaviour.

Thanks

----------
components: ctypes
messages: 152988
nosy: dgoulet
priority: normal
severity: normal
status: open
title: Automatic *libc.so loading behaviour
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13979>
_______________________________________

From report at bugs.python.org  Thu Feb  9 22:36:24 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 09 Feb 2012 21:36:24 +0000
Subject: [issue13782] xml.etree.ElementTree: Element.append doesn't type-check
	its argument
In-Reply-To: <1326502453.32.0.206779556991.issue13782@psf.upfronthosting.co.za>
Message-ID: <1328823384.23.0.819017514936.issue13782@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Actuallly, the assertions were commented in the upstream repository.

https://bitbucket.org/effbot/et-2009-provolone/src/9e9e7f2710aa/elementtree/CHANGES#cl-46

> (1.3a6 released)
> - Removed most assert statements from the Element and ElementTree code.


It looks more useful to me to have a consistent behavior between C and Python version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13782>
_______________________________________

From report at bugs.python.org  Thu Feb  9 22:41:09 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Feb 2012 21:41:09 +0000
Subject: [issue13979] Automatic *libc.so loading behaviour
In-Reply-To: <1328821808.41.0.811189579105.issue13979@psf.upfronthosting.co.za>
Message-ID: <1328823669.24.0.185905627966.issue13979@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +meador.inge
stage:  -> needs patch
versions: +Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13979>
_______________________________________

From report at bugs.python.org  Thu Feb  9 23:10:02 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 09 Feb 2012 22:10:02 +0000
Subject: [issue1528593] Printing: No print dialog or page setup
Message-ID: <1328825402.73.0.109908195613.issue1528593@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/issue1528593>
_______________________________________

From report at bugs.python.org  Thu Feb  9 23:12:42 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 09 Feb 2012 22:12:42 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328825562.58.0.703388057948.issue13968@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Given the complexities proposed for the dir matching, I'm shifting back to a solid -1 on this. Trying to match multi-part directories with globs is a nightmare and I currently don't allow it at all in walkdir. Instead, dir filtering and file filtering are expressed separately.

In 0.4, walkdir will allow the following to search the current directory for all Python source files in subdirectories named 'c':

    walk_files(included_files=["*.py"], included_dirs="c")

This discussion does mean I plan to add path filtering though, that works on the "dirpath" value directly (and *will* allow multi-part matches). So the "Python source files in subdirectories named 'd' of directories named 'c'" will be written something like:

    walk_files(included_files=["*.py"], included_paths="*/c/d")

I also plan to explore options to make the pattern matching function configurable (i.e. so you can pass in something like "match=re.search")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 23:12:58 2012
From: report at bugs.python.org (fif0)
Date: Thu, 09 Feb 2012 22:12:58 +0000
Subject: [issue13980] getcwd problem
Message-ID: <1328825578.61.0.813080767189.issue13980@psf.upfronthosting.co.za>


New submission from fif0 <hendrik.schneider at xantrum.de>:

Please take a look at the detached file.

At the first call of the methode foo(), path and the second getcwd are the same. After the directory change, the default value path is not the the current working directory.

----------
components: Interpreter Core
files: maybe_a_bug.py
messages: 152991
nosy: fif0
priority: normal
severity: normal
status: open
title: getcwd problem
versions: Python 2.7
Added file: http://bugs.python.org/file24472/maybe_a_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13980>
_______________________________________

From report at bugs.python.org  Thu Feb  9 23:18:02 2012
From: report at bugs.python.org (fif0)
Date: Thu, 09 Feb 2012 22:18:02 +0000
Subject: [issue13980] getcwd problem does not return cwd
In-Reply-To: <1328825578.61.0.813080767189.issue13980@psf.upfronthosting.co.za>
Message-ID: <1328825882.87.0.0332740246508.issue13980@psf.upfronthosting.co.za>


Changes by fif0 <hendrik.schneider at xantrum.de>:


----------
title: getcwd problem -> getcwd problem does not return cwd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13980>
_______________________________________

From report at bugs.python.org  Thu Feb  9 23:31:40 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 09 Feb 2012 22:31:40 +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: <1328826700.4.0.049140051429.issue7433@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Closing, since it's fixed in #10181.

----------
dependencies:  -Problems with Py_buffer management in memoryobject.c (and elsewhere?)
resolution:  -> duplicate
stage: needs patch -> committed/rejected
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/issue7433>
_______________________________________

From report at bugs.python.org  Thu Feb  9 23:33:54 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 09 Feb 2012 22:33:54 +0000
Subject: [issue8305] memoview[0] creates an invalid view if ndim != 1
In-Reply-To: <1270308282.65.0.542260907353.issue8305@psf.upfronthosting.co.za>
Message-ID: <1328826834.83.0.387372150958.issue8305@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Fixed in #10181.

----------
dependencies:  -Problems with Py_buffer management in memoryobject.c (and elsewhere?)
resolution:  -> duplicate
stage: needs patch -> committed/rejected
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/issue8305>
_______________________________________

From report at bugs.python.org  Thu Feb  9 23:37:30 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Feb 2012 22:37:30 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328825562.58.0.703388057948.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328826880.3422.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> This discussion does mean I plan to add path filtering though, that
> works on the "dirpath" value directly (and *will* allow multi-part
> matches). So the "Python source files in subdirectories named 'd' of
> directories named 'c'" will be written something like:
> 
>     walk_files(included_files=["*.py"], included_paths="*/c/d")

That's not different from rglobbing "*/c/d/*.py", is it? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 23:40:51 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Feb 2012 22:40:51 +0000
Subject: [issue13980] getcwd problem does not return cwd
In-Reply-To: <1328825578.61.0.813080767189.issue13980@psf.upfronthosting.co.za>
Message-ID: <1328827251.52.0.299973335773.issue13980@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That's just how function definitions in Python work.  The prototype is evaluated when the function is defined, not when it is run, so the default value of path will always be the value of getcwd at the time the function *defintion* is done (which will generally be the CWD when python starts, unless you are defining functions at runtime).

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13980>
_______________________________________

From report at bugs.python.org  Thu Feb  9 23:42:31 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 09 Feb 2012 22:42:31 +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: <1328827351.01.0.046760450917.issue9990@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I ran the demo in the pep-3118 repo, and it is fixed (see #10181):

$ ./bufrel 
Accessing buffer directly...
Accessing buffer through a memory view...
Done.

----------
dependencies:  -Problems with Py_buffer management in memoryobject.c (and elsewhere?)
resolution:  -> duplicate
stage: patch review -> committed/rejected
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/issue9990>
_______________________________________

From report at bugs.python.org  Thu Feb  9 23:45:55 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 09 Feb 2012 22:45:55 +0000
Subject: [issue10211] BufferObject doesn't support new buffer interface
In-Reply-To: <1288169352.49.0.219368546772.issue10211@psf.upfronthosting.co.za>
Message-ID: <1328827555.7.0.291779970311.issue10211@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/issue10211>
_______________________________________

From report at bugs.python.org  Thu Feb  9 23:48:17 2012
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 09 Feb 2012 22:48:17 +0000
Subject: [issue8754] quote bad module name in ImportError-like messages
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1328827697.57.0.626729294202.issue8754@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

With issue1559549 adding a 'name' argument, I'm going to push to have it gain a reasonable default __str__ if 'name' is set but nothing else. That patch also contains some helper functions which should simplify Eric's patch.

----------
dependencies: +ImportError needs attributes for module and file name

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Thu Feb  9 23:48:50 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Feb 2012 22:48:50 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328827730.46.0.969112517812.issue13968@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't know, is it?  From what has been said so far I'd expect */c/d/*.py to look for *.py files in all c/d subdirectories of direct subdirectories of the current directory, and subdirectories of those c/d directories.  But I wouldn't expect the c/d matching to go any deeper than that one level.  Whereas with Nick's formulation, I would.  And I know at a glance, without reading any documentation, what Nick's formulation does, whereas I very much don't with rglob.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Thu Feb  9 23:50:52 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Feb 2012 22:50:52 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328827730.46.0.969112517812.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328827681.3422.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I don't know, is it?  From what has been said so far I'd expect
> */c/d/*.py to look for *.py files in all c/d subdirectories of direct
> subdirectories of the current directory, and subdirectories of those
> c/d directories.  But I wouldn't expect the c/d matching to go any
> deeper than that one level.

That would be a normal glob, not a recursive glob. We already have
glob.glob().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Fri Feb 10 00:00:34 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Feb 2012 23:00:34 +0000
Subject: [issue13981] time.sleep() should use nanosleep() if available
Message-ID: <1328828434.41.0.993247720876.issue13981@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

With the PEP 410, it is possible to store timestamps with a resolution of 1 nanosecond. Python should use nanosleep() if the function is available for time.sleep().

This issue depends on issue #13882.

----------
components: Library (Lib)
messages: 153000
nosy: haypo
priority: normal
severity: normal
status: open
title: time.sleep() should use nanosleep() if available
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13981>
_______________________________________

From report at bugs.python.org  Fri Feb 10 00:00:37 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Feb 2012 23:00:37 +0000
Subject: [issue13981] time.sleep() should use nanosleep() if available
In-Reply-To: <1328828434.41.0.993247720876.issue13981@psf.upfronthosting.co.za>
Message-ID: <1328828437.52.0.797162140425.issue13981@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies: +PEP 410: Use decimal.Decimal type for timestamps

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13981>
_______________________________________

From report at bugs.python.org  Fri Feb 10 00:01:07 2012
From: report at bugs.python.org (Yuval Greenfield)
Date: Thu, 09 Feb 2012 23:01:07 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328828467.18.0.256026948091.issue13968@psf.upfronthosting.co.za>


Yuval Greenfield <ubershmekel at gmail.com> added the comment:

As R. David Murray has suggested I think there may be a middle ground.

    def rglob(fn_filter, root='.'):

That would mean the default use case is still easy to remember as rglob('*.py') and also there aren't any explanations needed for how this function works.

Though I'm not sure which of these API's I like better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Fri Feb 10 00:08:36 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Feb 2012 23:08:36 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328828916.12.0.156054342567.issue13968@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

@antoine: no, my description involves recursion.  It assumes that the path portion of the glob specifies the directories to *start* from, but that the filename glob portion then applies recursively to any of those start directories.

The alternative interpretation of the pattern, that it is fully matched against the CWD, takes you back to having to explain what '..' means when matched against a given location in the recursion, starting with the CWD.  I clearly don't have a good intuition about that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Fri Feb 10 00:09:44 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Feb 2012 23:09:44 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328828984.78.0.839141782365.issue13968@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Oh, yeah, and there's still the question of whether or not directories are matched by the terminal glob pattern, which I would naively expect they would be, in either interpretation, but I wouldn't be sure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Fri Feb 10 00:10:29 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Feb 2012 23:10:29 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328828916.12.0.156054342567.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328828859.3422.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The alternative interpretation of the pattern, that it is fully
> matched against the CWD, takes you back to having to explain what '..'
> means when matched against a given location in the recursion, starting
> with the CWD.  I clearly don't have a good intuition about that.

My alternative interpretation is that the pattern is being matched
against whatever subdir of the current dir (and the current dir itself).
The matching is not different from glob()'s.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Fri Feb 10 00:47:22 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Feb 2012 23:47:22 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328831242.83.0.88963307892.issue13968@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, OK, so what you are saying is that rglob returns the concatenation of the results of running ls with the argument glob in each subdirectory of a walk starting with the current directory, except that the returned names have paths anchored in the current directory?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Fri Feb 10 01:42:46 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 10 Feb 2012 00:42:46 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328831242.83.0.88963307892.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328834396.3422.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Ah, OK, so what you are saying is that rglob returns the concatenation
> of the results of running ls with the argument glob in each
> subdirectory of a walk starting with the current directory, except
> that the returned names have paths anchored in the current directory?

Yup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Fri Feb 10 02:48:24 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Feb 2012 01:48:24 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328838504.3.0.446726939976.issue13882@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch version 14:

 - rewrite the conversion from float to _PyTime_t: use base 2 with high precision and then simplify the fraction. The conversion from decimal.Decimal uses base 10 and do also simplify the fraction.
 - write tests on functions converting _PyTime_t using _testcapi
 - add timestamp argument to signal.getitimer(), signal.setitimer(), resource.getrusage()
 - signal.sigtimedwait() uses _PyTime_t and now expects a number and no more a tuple (function added to Python 3.3, so no backward compatibility issue). See also the issue #13964
 - time.sleep() uses _PyTime_t. See also the issue #13981 (use nanosleep())
 - datetime.datetime.now() and datetime.datetime.utcnow() uses _PyTime_t
 - catch integer overflow on _PyTime_AsTimeval(), _PyTime_AsTimespec() and more

This patch gives you an overview of the whole PEP 410 implementation, but it should not be applied in one shot. It would be better to commit it step by step:

 - add _PyTime_t API
 - use _PyTime_t for the time module
 - use _PyTime_t for the os module
 - use _PyTime_t for the more modules
 - etc.

We can start by adding the API and use it in the time module, and then rediscuss changes on other modules.

----------
Added file: http://bugs.python.org/file24473/time_decimal-14.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Fri Feb 10 02:49:11 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Feb 2012 01:49:11 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1328838551.25.0.561042223279.issue13882@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file24461/time_decimal-13.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Fri Feb 10 04:38:23 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 10 Feb 2012 03:38:23 +0000
Subject: [issue13782] xml.etree.ElementTree: Element.append doesn't type-check
	its argument
In-Reply-To: <1326502453.32.0.206779556991.issue13782@psf.upfronthosting.co.za>
Message-ID: <1328845103.38.0.763314131841.issue13782@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

>> It looks more useful to me to have a consistent behavior between C and Python version.

I agree, especially is we now consider to expose the C API by default, leaving the Python API as a fallback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13782>
_______________________________________

From report at bugs.python.org  Fri Feb 10 04:42:05 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Feb 2012 03:42:05 +0000
Subject: [issue13123] bdist_wininst uninstaller does not remove pycache
	directories
In-Reply-To: <1318000960.21.0.140069466315.issue13123@psf.upfronthosting.co.za>
Message-ID: <1328845325.53.0.845892683891.issue13123@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

No, I worked on other things in my Python time.  I did get a Windows image, but failed to configure the VM*.  I?ve found some doc and will try again, or go back to the idea of giving you a patch to test.

  * (It gives a BSOD at boot, so one could argue that it counts as ?working?
  for Windows :)

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13123>
_______________________________________

From report at bugs.python.org  Fri Feb 10 04:50:25 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 10 Feb 2012 03:50:25 +0000
Subject: [issue13981] time.sleep() should use nanosleep() if available
In-Reply-To: <1328828434.41.0.993247720876.issue13981@psf.upfronthosting.co.za>
Message-ID: <1328845825.28.0.812531366746.issue13981@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/issue13981>
_______________________________________

From report at bugs.python.org  Fri Feb 10 04:53:32 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Feb 2012 03:53:32 +0000
Subject: [issue13189] New bdist_simple binary distribution format for packaging
In-Reply-To: <1318775392.19.0.757483007173.issue13189@psf.upfronthosting.co.za>
Message-ID: <1328846012.78.0.952432265021.issue13189@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I initially had a lot of things to reply to but then though it would be unpractical to reply, then the usual life/work/time thing got in the way and I busied myself with easier issues.

As Nick said on python-ideas, I should write a PEP, which would probably be a better support to summarize the requirements, issues and choices.

The feature deadline is June, so there?s still a bit of time to work on that bdist format, decide if we agree on one of bdist_wininst/bdist_msi/new-shiny-bdist-for-windows-by-jkloth, and in parallel to that packaging could also be documented as experimental (the solution suggested by Guido when ruling on the __preview__ package PEP).  And in the worst case a PyPI-relased bdist_simple would be dead-easy to install and register with packaging (we don?t have auto-discovery of commands, but easy registration is here).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13189>
_______________________________________

From report at bugs.python.org  Fri Feb 10 04:56:52 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Feb 2012 03:56:52 +0000
Subject: [issue13175] packaging uses wrong line endings in RECORD files on
	Windows
In-Reply-To: <1318546022.2.0.0477576720396.issue13175@psf.upfronthosting.co.za>
Message-ID: <1328846212.0.0.614782090302.issue13175@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I tried to reproduce using distutils2, but don't know how distutils2
> works - there's no pysetup and python -m distutils2.run doesn't work
> the same as python -m packaging.run.

Maybe you?re using the old PyPI release or Tarek?s outdated Bitbucket repository.  http://hg.python.org/distutils is current, contains pysetup and supports -m distutils2.run.

I?ll port your patch to d2 this week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13175>
_______________________________________

From report at bugs.python.org  Fri Feb 10 04:57:29 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Feb 2012 03:57:29 +0000
Subject: [issue13198] Remove duplicate definition of write_record_file
In-Reply-To: <1318857154.54.0.641953188635.issue13198@psf.upfronthosting.co.za>
Message-ID: <1328846249.62.0.46135445719.issue13198@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Mike, if you don?t have the time to finish this shortly, I will do it, as I need this fixed for another bug.  Just let me know if you?d like to do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13198>
_______________________________________

From report at bugs.python.org  Fri Feb 10 05:03:37 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Feb 2012 04:03:37 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328846617.54.0.972770483787.issue13968@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FTR, packaging has an extended glob function (not my code) which supports sets (with { , }) and recursivity (**).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Fri Feb 10 05:05:00 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Feb 2012 04:05:00 +0000
Subject: [issue13975] packaging: change_root() test for os2
In-Reply-To: <1328776146.47.0.653545071003.issue13975@psf.upfronthosting.co.za>
Message-ID: <1328846700.37.0.0428411751952.issue13975@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

OS/2 is not supported by 3.3; someone said on python-dev they wanted to take over maintenance but they wanted to use a different compiler toolchain, which would effectively change the platform definition, so it?s not clear at this point that OS/2 support will continue.  In this light, I?m rejecting your patch (with thanks for your work nonetheless), and will reopen if the situation change.

(I?ll remove the now-obsolete comment later.)

----------
assignee: tarek -> eric.araujo
priority: normal -> 
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13975>
_______________________________________

From report at bugs.python.org  Fri Feb 10 05:05:39 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Feb 2012 04:05:39 +0000
Subject: [issue13974] packaging: test for set_platform()
In-Reply-To: <1328775875.69.0.230962367845.issue13974@psf.upfronthosting.co.za>
Message-ID: <1328846739.04.0.898347020322.issue13974@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is the effect of the set_platform call permanent?  If yes, there needs to be a line like self.addCleanup(util.set_platform, util.get_platform()) to make sure the test restores its environment.

----------
assignee: tarek -> eric.araujo
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13974>
_______________________________________

From report at bugs.python.org  Fri Feb 10 05:11:20 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Feb 2012 04:11:20 +0000
Subject: [issue13462] Improve code and tests for Mixin2to3
In-Reply-To: <1322066341.39.0.436349182896.issue13462@psf.upfronthosting.co.za>
Message-ID: <E1RvhpN-0000vs-DS@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b024621a1be6 by ?ric Araujo in branch 'default':
Start improving 2to3 code (#13462).
http://hg.python.org/distutils2/rev/b024621a1be6

New changeset cc0f4d208193 by ?ric Araujo in branch 'python3':
Merge fixes for #13462 and others from default
http://hg.python.org/distutils2/rev/cc0f4d208193

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13462>
_______________________________________

From report at bugs.python.org  Fri Feb 10 05:11:20 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Feb 2012 04:11:20 +0000
Subject: [issue9442] Update sys.version doc
In-Reply-To: <1280605593.44.0.301230771819.issue9442@psf.upfronthosting.co.za>
Message-ID: <E1RvhpN-0000vs-EV@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0cc1fbbb473d by ?ric Araujo in branch 'default':
Use sys.version_info instead of sys.version.
http://hg.python.org/distutils2/rev/0cc1fbbb473d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9442>
_______________________________________

From report at bugs.python.org  Fri Feb 10 05:13:07 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Feb 2012 04:13:07 +0000
Subject: [issue13462] Improve code and tests for Mixin2to3
In-Reply-To: <1322066341.39.0.436349182896.issue13462@psf.upfronthosting.co.za>
Message-ID: <E1Rvhr6-00018F-Kv@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7243c3f18769 by ?ric Araujo in branch 'default':
Start improving 2to3 code in packaging (#13462).
http://hg.python.org/cpython/rev/7243c3f18769

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13462>
_______________________________________

From report at bugs.python.org  Fri Feb 10 05:21:01 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Feb 2012 04:21:01 +0000
Subject: [issue9442] Update sys.version doc
In-Reply-To: <1280605593.44.0.301230771819.issue9442@psf.upfronthosting.co.za>
Message-ID: <E1Rvhyl-0001jA-Qg@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6fdcfe348435 by ?ric Araujo in branch 'default':
Use sys.version_info instead of sys.version in packaging.
http://hg.python.org/cpython/rev/6fdcfe348435

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9442>
_______________________________________

From report at bugs.python.org  Fri Feb 10 05:25:32 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Feb 2012 04:25:32 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1328847932.07.0.955435788451.issue13193@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Bumping up to release blocker, as I don?t want the next bugfixes to go out without reverting the last changeset (but won?t right know as I need to fix the bug there was on Windows).

----------
nosy: +benjamin.peterson, georg.brandl
priority: high -> release blocker
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Fri Feb 10 05:26:44 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Feb 2012 04:26:44 +0000
Subject: [issue13813] "sysconfig.py" and "distutils/util.py" redundancy
In-Reply-To: <1326859118.01.0.584725172013.issue13813@psf.upfronthosting.co.za>
Message-ID: <1328848004.27.0.668662460695.issue13813@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See also #9841.

What situation do you want background on?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13813>
_______________________________________

From report at bugs.python.org  Fri Feb 10 05:32:27 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Feb 2012 04:32:27 +0000
Subject: [issue13865] distutils documentation says Extension has "optional"
	argument
In-Reply-To: <1327525493.46.0.373823292504.issue13865@psf.upfronthosting.co.za>
Message-ID: <E1Rvi9j-0002T4-3o@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset cf1c466ee9e0 by ?ric Araujo in branch '2.7':
distutils 2.7?s Extension does not support optional (#13865).
http://hg.python.org/cpython/rev/cf1c466ee9e0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13865>
_______________________________________

From report at bugs.python.org  Fri Feb 10 05:36:23 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Feb 2012 04:36:23 +0000
Subject: [issue13865] distutils documentation says Extension has "optional"
	argument
In-Reply-To: <1327525493.46.0.373823292504.issue13865@psf.upfronthosting.co.za>
Message-ID: <1328848583.93.0.108665331138.issue13865@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Fixed, cheers!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13865>
_______________________________________

From report at bugs.python.org  Fri Feb 10 06:13:51 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 10 Feb 2012 05:13:51 +0000
Subject: [issue13782] xml.etree.ElementTree: Element.append doesn't type-check
	its argument
In-Reply-To: <1326502453.32.0.206779556991.issue13782@psf.upfronthosting.co.za>
Message-ID: <1328850831.21.0.239214853843.issue13782@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Option 1 is to fix the regression in the 2.7/3.2 Python versions and change the C version to conform to the doc and older Python versions., even though it is the wrong error, and even though Python asserts disappear with -O (which is why it is the wrong error).

Option 2 is to leave cET alone with the correct error and fix 2.7/3.2 and the docs to conform.

Option 3 is to leave cET alone and leave 2.7/3.2 alone as done deals, even if bad. Change 3.3 Python and docs to TypeError. We would need a version-changed note, but perhaps should mention the 3.2 behavior so as to not give a mis-impression.

I think I favor 3, but after presenting the trilemma on pydev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13782>
_______________________________________

From report at bugs.python.org  Fri Feb 10 06:18:33 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 10 Feb 2012 05:18:33 +0000
Subject: [issue13782] xml.etree.ElementTree: Element.append doesn't type-check
	its argument
In-Reply-To: <1326502453.32.0.206779556991.issue13782@psf.upfronthosting.co.za>
Message-ID: <1328851113.96.0.068631461316.issue13782@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Terry, I agree with 3. The "regression" here is insignificant enough in my view to warrant mucking with already released versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13782>
_______________________________________

From report at bugs.python.org  Fri Feb 10 07:17:57 2012
From: report at bugs.python.org (Shivam)
Date: Fri, 10 Feb 2012 06:17:57 +0000
Subject: [issue13982] python returning errorneous value for sqrt
Message-ID: <1328854677.42.0.867049948528.issue13982@psf.upfronthosting.co.za>


New submission from Shivam <shivam.agarwal at aricent.com>:

On mips64 biit machine running linux I have installed python2.4_2.4.4 from link "http://archive.debian.net/etch/python2.4" using below commands:

./configure ?enable-shared
make 
make install  

But when I check value of sqrt(9.0) on python, python returns:?4.9406564584124654e-324? rather than ?3.0?. 

Can anybody let me know what may be the reason for this.

Regards
Shivam Agarwal

----------
messages: 153026
nosy: shivam_python_issues
priority: normal
severity: normal
status: open
title: python returning errorneous value for sqrt
type: behavior
versions: 3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13982>
_______________________________________

From report at bugs.python.org  Fri Feb 10 07:45:05 2012
From: report at bugs.python.org (Shivam)
Date: Fri, 10 Feb 2012 06:45:05 +0000
Subject: [issue13983] make test giving bus error
Message-ID: <1328856305.29.0.849660995129.issue13983@psf.upfronthosting.co.za>


New submission from Shivam <shivam.agarwal at aricent.com>:

Hi All,
   On mips64 biit machine running linux I have installed python2.4_2.4.4 from link "http://archive.debian.net/etch/python2.4" using below commands:

./configure ?enable-shared
make
make install  

But make test fails with bus error, below is the log for same:

octeon:~/depend_resolv/python2.4-2.4.4.orig# make test
case $MAKEFLAGS in \
        *-s*) LD_LIBRARY_PATH=/root/depend_resolv/python2.4-2.4.4.orig: CC='gcc -pthread' LDSHARED='gcc -pthread
 -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \
        *) LD_LIBRARY_PATH=/root/depend_resolv/python2.4-2.4.4.orig: CC='gcc -pthread' LDSHARED='gcc -pthread -s
hared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \
        esac
running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers
building 'dbm' extension
gcc -pthread -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -fno-strict-aliasing -DHAVE_NDBM_H -I. -I/root/depe
nd_resolv/python2.4-2.4.4.orig/./Include -I/usr/local/include -I/root/depend_resolv/python2.4-2.4.4.orig/Include
 -I/root/depend_resolv/python2.4-2.4.4.orig -c /root/depend_resolv/python2.4-2.4.4.orig/Modules/dbmmodule.c -o b
uild/temp.linux-mips64-2.4/dbmmodule.o
gcc -pthread -shared build/temp.linux-mips64-2.4/dbmmodule.o -L/usr/local/lib -o build/lib.linux-mips64-2.4/dbm.
so
*** WARNING: renaming "dbm" since importing it failed: build/lib.linux-mips64-2.4/dbm.so: undefined symbol: dbm_
error
running build_scripts
find ./Lib -name '*.py[co]' -print | xargs rm -f
LD_LIBRARY_PATH=/root/depend_resolv/python2.4-2.4.4.orig: ./python -E -tt ./Lib/test/regrtest.py -l 
make: *** [test] Bus error
LD_LIBRARY_PATH=/root/depend_resolv/python2.4-2.4.4.orig: ./python -E -tt ./Lib/test/regrtest.py -l 
test_grammar
test_opcodes
test_operations
test_builtin
make: *** [test] Bus error

----------
messages: 153027
nosy: shivam_python_issues
priority: normal
severity: normal
status: open
title: make test giving bus error
type: compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13983>
_______________________________________

From report at bugs.python.org  Fri Feb 10 07:50:14 2012
From: report at bugs.python.org (Eric Snow)
Date: Fri, 10 Feb 2012 06:50:14 +0000
Subject: [issue13961] Have importlib use os.replace()
In-Reply-To: <1328624796.15.0.577971130856.issue13961@psf.upfronthosting.co.za>
Message-ID: <1328856614.64.0.290460156775.issue13961@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13961>
_______________________________________

From report at bugs.python.org  Fri Feb 10 07:51:49 2012
From: report at bugs.python.org (Eric Snow)
Date: Fri, 10 Feb 2012 06:51:49 +0000
Subject: [issue13977] importlib simplification
In-Reply-To: <1328810035.88.0.967764974247.issue13977@psf.upfronthosting.co.za>
Message-ID: <1328856709.76.0.0463353293151.issue13977@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13977>
_______________________________________

From report at bugs.python.org  Fri Feb 10 07:58:31 2012
From: report at bugs.python.org (Paul Moore)
Date: Fri, 10 Feb 2012 06:58:31 +0000
Subject: [issue13175] packaging uses wrong line endings in RECORD files on
	Windows
In-Reply-To: <1328846212.0.0.614782090302.issue13175@psf.upfronthosting.co.za>
Message-ID: <CACac1F-i5rfXh4pcPipH1zBfUVR3bWpi5HasgLyzKyE_FwFEAg@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

> Maybe you?re using the old PyPI release or Tarek?s outdated Bitbucket repository. ?http://hg.python.org/distutils is current, contains pysetup and supports -m distutils2.run.

I just did pip install distutils2 in a virtualenv. If that doesn't
work then yes, I got the wrong one :-(

Do I need to hg clone then do some magic pip incantation to get it
installed? I'm new to pip/viirtualenv. I'll have a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13175>
_______________________________________

From report at bugs.python.org  Fri Feb 10 08:02:44 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 10 Feb 2012 07:02:44 +0000
Subject: [issue13982] python returning errorneous value for sqrt
In-Reply-To: <1328854677.42.0.867049948528.issue13982@psf.upfronthosting.co.za>
Message-ID: <1328857364.29.0.10650987503.issue13982@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Python 2.4 is no longer maintained.

----------
nosy: +loewis
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13982>
_______________________________________

From report at bugs.python.org  Fri Feb 10 08:03:50 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 10 Feb 2012 07:03:50 +0000
Subject: [issue13983] make test giving bus error
In-Reply-To: <1328856305.29.0.849660995129.issue13983@psf.upfronthosting.co.za>
Message-ID: <1328857430.74.0.20585818612.issue13983@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Python 2.4 is no longer maintained.

----------
nosy: +loewis
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13983>
_______________________________________

From report at bugs.python.org  Fri Feb 10 09:07:36 2012
From: report at bugs.python.org (Shivam)
Date: Fri, 10 Feb 2012 08:07:36 +0000
Subject: [issue13984] Python2.6 compilation breaking on mips64 bit machine
Message-ID: <1328861256.08.0.514487145098.issue13984@psf.upfronthosting.co.za>


New submission from Shivam <shivam.agarwal at aricent.com>:

Hi All,
  I am getting follwoing error when compiling Python2.6 on mips 64.

"
Failed to find the necessary bits to build these modules:
_bsddb             _tkinter           bsddb185        
bz2                dl                 imageop         
readline           sunaudiodev        zlib            
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
_ctypes            datetime           dbm             
"

----------
components: None
messages: 153031
nosy: shivam_python_issues
priority: normal
severity: normal
status: open
title: Python2.6 compilation breaking on mips64 bit machine
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13984>
_______________________________________

From report at bugs.python.org  Fri Feb 10 09:10:05 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 10 Feb 2012 08:10:05 +0000
Subject: [issue13960] Handling of broken comments in HTMLParser
In-Reply-To: <1328615796.36.0.0693404155355.issue13960@psf.upfronthosting.co.za>
Message-ID: <1328861405.1.0.291648854864.issue13960@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'll fix this for 3.x non-strict and then see if it can be backported to 2.7 (there are still other fixes that should be backported to 2.7 before this can be applied).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13960>
_______________________________________

From report at bugs.python.org  Fri Feb 10 09:14:19 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 10 Feb 2012 08:14:19 +0000
Subject: [issue13984] Python2.6 compilation breaking on mips64 bit machine
In-Reply-To: <1328861256.08.0.514487145098.issue13984@psf.upfronthosting.co.za>
Message-ID: <1328861659.48.0.183114791129.issue13984@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Python 2.6 is in a mode where only security issues get fixed. Please use Python 2.7 or Python 3.2.

----------
nosy: +loewis
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13984>
_______________________________________

From report at bugs.python.org  Fri Feb 10 09:16:07 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 10 Feb 2012 08:16:07 +0000
Subject: [issue13984] Python2.6 compilation breaking on mips64 bit machine
In-Reply-To: <1328861256.08.0.514487145098.issue13984@psf.upfronthosting.co.za>
Message-ID: <1328861767.75.0.868472813369.issue13984@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Also understand that this output does not indicate an error. It just means that it couldn't build these modules. Python itself works just fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13984>
_______________________________________

From report at bugs.python.org  Fri Feb 10 09:51:07 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Feb 2012 08:51:07 +0000
Subject: [issue13960] Handling of broken comments in HTMLParser
In-Reply-To: <1328615796.36.0.0693404155355.issue13960@psf.upfronthosting.co.za>
Message-ID: <E1RvmC9-0006FF-J0@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 242b697449d8 by Ezio Melotti in branch '3.2':
#13960: HTMLParser is now able to handle broken comments when strict=False.
http://hg.python.org/cpython/rev/242b697449d8

New changeset 44366541dd86 by Ezio Melotti in branch 'default':
#13960: merge with 3.2.
http://hg.python.org/cpython/rev/44366541dd86

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13960>
_______________________________________

From report at bugs.python.org  Fri Feb 10 09:52:03 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 10 Feb 2012 08:52:03 +0000
Subject: [issue13960] Handling of broken comments in HTMLParser
In-Reply-To: <1328615796.36.0.0693404155355.issue13960@psf.upfronthosting.co.za>
Message-ID: <1328863923.62.0.240882843145.issue13960@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is now fixed in 3.2/3.3, I'll wait for 2.7 before closing it.
On a side note, the empty <!> comment doesn't seem to be valid in HTML5.
HTMLParser just ignores it, and doesn't report it as an empty comment (so this should be fine).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13960>
_______________________________________

From report at bugs.python.org  Fri Feb 10 11:50:23 2012
From: report at bugs.python.org (marc dechico)
Date: Fri, 10 Feb 2012 10:50:23 +0000
Subject: [issue13985] Menu.tk_popup : menu doesn't disapear when main window
	is iconified.
Message-ID: <1328871022.99.0.882272597763.issue13985@psf.upfronthosting.co.za>


New submission from marc dechico <marc.dechico at gmail.com>:

actions do discover the bug  with the source I have given:

pushing the right button to get the pop-up menu .

going out of the popup_menu  still pushing the right button.

the menu doesn't disapear when releasing the button.

and still doesn't disapear when iconnifying the main window.

I suppose the pop up_menu  should behave in a transient way.

when doing such a thing with google-chrome I first have my popup menu disapear and I need to click again to iconify.

perhaps we should have the choice and have access to a transient function.

----------
components: Tkinter
files: popupmenu.py
messages: 153037
nosy: marc.dechico
priority: normal
severity: normal
status: open
title: Menu.tk_popup  : menu doesn't disapear when main window is iconified.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file24474/popupmenu.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13985>
_______________________________________

From report at bugs.python.org  Fri Feb 10 11:51:10 2012
From: report at bugs.python.org (Paul Moore)
Date: Fri, 10 Feb 2012 10:51:10 +0000
Subject: [issue13189] New bdist_simple binary distribution format for packaging
In-Reply-To: <1318775392.19.0.757483007173.issue13189@psf.upfronthosting.co.za>
Message-ID: <1328871070.1.0.375061491818.issue13189@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

I'm writing a PEP, also as a result of Nick's suggestion on python-ideas. I don't think it will be too hard to get the basic framework of the PEP in place. When I'm done, would you like to see it and comment before I post to the wider python-dev, or should I just post it and see what happens?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13189>
_______________________________________

From report at bugs.python.org  Fri Feb 10 12:43:58 2012
From: report at bugs.python.org (Shivam)
Date: Fri, 10 Feb 2012 11:43:58 +0000
Subject: [issue13986] ValueError: cannot convert float NaN to integer
Message-ID: <1328874238.47.0.897260032056.issue13986@psf.upfronthosting.co.za>


New submission from Shivam <shivam.agarwal at aricent.com>:

Hi Team,
   Kindly help me in resolving below issue which arises when we do "make install" as it is show stopper for us.

Listing /usr/local/lib/python2.7 ...
Compiling /usr/local/lib/python2.7/BaseHTTPServer.py ...
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/compileall.py", line 213, in <module>
    exit_status = int(not main())
  File "/usr/local/lib/python2.7/compileall.py", line 200, in main
    force, rx, quiet):
  File "/usr/local/lib/python2.7/compileall.py", line 50, in compile_dir
    if not compile_file(fullname, ddir, force, rx, quiet):
  File "/usr/local/lib/python2.7/compileall.py", line 99, in compile_file
    ok = py_compile.compile(fullname, None, dfile, True)
  File "/usr/local/lib/python2.7/py_compile.py", line 108, in compile
    timestamp = long(os.fstat(f.fileno()).st_mtime)
ValueError: cannot convert float NaN to integer
make: *** [libinstall] Error 1


Addtionaly:
-----------
At the time of make below message is flashed as well:

Failed to build these modules:
datetime           dbm

----------
components: Build
messages: 153039
nosy: shivam_python_issues
priority: normal
severity: normal
status: open
title: ValueError: cannot convert float NaN to integer
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13986>
_______________________________________

From report at bugs.python.org  Fri Feb 10 12:57:44 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 10 Feb 2012 11:57:44 +0000
Subject: [issue13986] ValueError: cannot convert float NaN to integer
In-Reply-To: <1328874238.47.0.897260032056.issue13986@psf.upfronthosting.co.za>
Message-ID: <1328875064.31.0.816670152696.issue13986@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13986>
_______________________________________

From report at bugs.python.org  Fri Feb 10 13:00:14 2012
From: report at bugs.python.org (Shivam)
Date: Fri, 10 Feb 2012 12:00:14 +0000
Subject: [issue13986] ValueError: cannot convert float NaN to integer
In-Reply-To: <1328874238.47.0.897260032056.issue13986@psf.upfronthosting.co.za>
Message-ID: <1328875214.76.0.851783822814.issue13986@psf.upfronthosting.co.za>


Shivam <shivam.agarwal at aricent.com> added the comment:

Hi Team,
   I am having this issue on mips 64bit machine running debian.

Regards
Shivam Agarwal

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13986>
_______________________________________

From report at bugs.python.org  Fri Feb 10 13:09:27 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Feb 2012 12:09:27 +0000
Subject: [issue13590] extension module builds fail with python.org OS X
	installers on OS X 10.7 and 10.6 with Xcode 4.2
In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za>
Message-ID: <E1RvpI6-0001vD-10@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 29507a2acdb5 by Ned Deily in branch '2.7':
Issue #13590: On OS X 10.7 and 10.6 with Xcode 4.2, building
http://hg.python.org/cpython/rev/29507a2acdb5

New changeset 5c784b0f263d by Ned Deily in branch '3.2':
Issue #13590: On OS X 10.7 and 10.6 with Xcode 4.2, building
http://hg.python.org/cpython/rev/5c784b0f263d

New changeset 35bd40b16a91 by Ned Deily in branch 'default':
Issue #13590: merge
http://hg.python.org/cpython/rev/35bd40b16a91

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13590>
_______________________________________

From report at bugs.python.org  Fri Feb 10 13:26:47 2012
From: report at bugs.python.org (Ned Deily)
Date: Fri, 10 Feb 2012 12:26:47 +0000
Subject: [issue13590] extension module builds fail with python.org OS X
	installers on OS X 10.7 and 10.6 with Xcode 4.2
In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za>
Message-ID: <1328876807.38.0.417133098497.issue13590@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

?ric: I've replied to your review comments in Rietveld.  Thanks.

Ronald: "distutils would not only have to check for gcc-4.2 vs. clang, but also needs to strip "-arch ppc" from the compiler flags when it is present and it cannot use gcc-4.2.   Otherwise you cannot build extensions for the 32-bit python installer on OSX 10.7 with Xcode 4.2."

The 32-bit-only installers uses gcc-4.0, not -4.2 and it uses the 10.4u SDK, neither of which is available with Xcode 4.*.  The patch does not currently attempt to support building extensions for the 32-bit-only installers.  Besides stripping arch ppc, it would also have to substitute an available SDK (10.6 is the oldest SDK shipping with Xcode 4.2).  CFLAGS and LDFLAGS would also have to be edited to remove ppc and the use of 10.3 as a deployment target results in warning messages:
  #warning Building for Intel with Mac OS X Deployment Target < 10.4 is invalid
even though for simple cases it seems to work.

But I think trying to automatically support the 32-bit-only configuration is too intrusive and unnecessary for most users.  There are disadvantages to trying to use the old 32-bit-only configuration on newer systems, such as using the older, more broken, or less feature-rich system APIs.  One reasonable use case I can think of is for app developers who want to distribute Python-based apps on OS X that run on a range of systems, say 10.4 to 10.7.  For those presumably more sophisticated users, documenting the unsupported environment variable settings to override when attempting to build with Xcode 4 should be sufficient.  (The safer options of building with Xcode 3 on 10.6 (or earlier) or building their own custom Pythons remain, of course.)

"W.r.t. the patch: is it really necessary to use a subshell to look for the compiler? I'd either walk os.environ['PATH'] myself or use xcodebuild to locate binaries."

I suppose that could be done.  I've tried to minimize the performance impact by only performing the check the first time it is needed and caching the result so it's only done once per Python invocation.  I'm concerned about the added complexity of getting the PATH parsing and semantics right; I don't know of any Python code in the standard library that does this.  My immediate concern is for the imminent code cutoffs for Python 3.2.3 and 2.7.3 so I've committed the patch, updated for other review comments, for them.

I'm deferring looking at doing a PATH walk for the 3.3 version of the code which is needed along with corresponding changes to packaging.  There also should be some OS X installer README and/or other documentation of this and other 10.7 and 10.6 issues.  I'm considering how to handle that.

----------
priority: release blocker -> deferred blocker
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13590>
_______________________________________

From report at bugs.python.org  Fri Feb 10 14:20:48 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 10 Feb 2012 13:20:48 +0000
Subject: [issue13986] ValueError: cannot convert float NaN to integer
In-Reply-To: <1328874238.47.0.897260032056.issue13986@psf.upfronthosting.co.za>
Message-ID: <1328880048.27.0.843099972337.issue13986@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/issue13986>
_______________________________________

From report at bugs.python.org  Fri Feb 10 14:22:07 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 10 Feb 2012 13:22:07 +0000
Subject: [issue13982] python returning errorneous value for sqrt
In-Reply-To: <1328854677.42.0.867049948528.issue13982@psf.upfronthosting.co.za>
Message-ID: <1328880127.08.0.477891640803.issue13982@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/issue13982>
_______________________________________

From report at bugs.python.org  Fri Feb 10 14:45:58 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 10 Feb 2012 13:45:58 +0000
Subject: [issue13987] Handling of broken markup in HTMLParser on 2.7
Message-ID: <1328881558.78.0.634398241399.issue13987@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

The attached patch fixes a few problems with HTMLParser on 2.7.
Instead of raising error when invalid markup is detected, the parser now consumes the invalid input and proceeds.  This patch is a partial backport of #1486713.

After this two more patches will follow.
The first will get rid of errors raised while parsing declarations and should also solve #13576:
     def unknown_decl(self, data):
-        self.error("unknown declaration: %r" % (data,))
+        pass

The second will take care of "bogus comments" (see #13960).

Once this is done HTMLParser should be able to parse (almost) everything.  I'm planning to commit this before the release of 2.7.3.

----------
assignee: ezio.melotti
components: Library (Lib)
files: issue13987.diff
keywords: patch
messages: 153043
nosy: benjamin.peterson, eric.araujo, ezio.melotti, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Handling of broken markup in HTMLParser on 2.7
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file24475/issue13987.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13987>
_______________________________________

From report at bugs.python.org  Fri Feb 10 14:46:39 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 10 Feb 2012 13:46:39 +0000
Subject: [issue13987] Handling of broken markup in HTMLParser on 2.7
In-Reply-To: <1328881558.78.0.634398241399.issue13987@psf.upfronthosting.co.za>
Message-ID: <1328881599.53.0.249256798202.issue13987@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/issue13987>
_______________________________________

From report at bugs.python.org  Fri Feb 10 14:50:12 2012
From: report at bugs.python.org (Christophe Kalt)
Date: Fri, 10 Feb 2012 13:50:12 +0000
Subject: [issue13966] Add disable_interspersed_args() to
	argparse.ArgumentParser
In-Reply-To: <1328687368.18.0.265955669963.issue13966@psf.upfronthosting.co.za>
Message-ID: <1328881812.81.0.610803269489.issue13966@psf.upfronthosting.co.za>


Christophe Kalt <kalt at taranis.org> added the comment:

nice, thank you!

----------
nosy: +kalt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13966>
_______________________________________

From report at bugs.python.org  Fri Feb 10 14:52:12 2012
From: report at bugs.python.org (Christophe Kalt)
Date: Fri, 10 Feb 2012 13:52:12 +0000
Subject: [issue13922] argparse handling multiple "--" in args improperly
In-Reply-To: <1328132556.72.0.92385645061.issue13922@psf.upfronthosting.co.za>
Message-ID: <1328881932.22.0.532822066802.issue13922@psf.upfronthosting.co.za>


Christophe Kalt <kalt at taranis.org> added the comment:

Hah.. was just about to report this.  I'm in the midst of converting a bunch of scripts from optparse to argparse, and this is one of the problems I'm hitting.

----------
nosy: +kalt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13922>
_______________________________________

From report at bugs.python.org  Fri Feb 10 14:58:30 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 10 Feb 2012 13:58:30 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1328882310.12.0.743271583497.issue10049@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

FWIW, it's likely I'll be adding contextlib.ContextStack (see [1]) for 3.3. While it's far from the primary use case, that API also serves as a "no-op" context manager (if you never register any contexts or callbacks, the __exit__ impl does nothing).

[1] http://contextlib2.readthedocs.org/en/latest/index.html#contextlib2.ContextStack

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Fri Feb 10 15:40:44 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 10 Feb 2012 14:40:44 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1328884844.63.0.623388285876.issue1559549@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The patch looks fine for its current semantics except for the fact that the macro doesn't work under clang; ##macro_var is supposed to be used only when concatenating parts of a string to create a complete identifier, not concatenating two identifiers next to each other (e.g. gooblede##gook is fine, but self->##gook isn't because '->' is its own identifier).

But one issue is that for my purposes I need 'name' to be the full name of the module, not just the tail of the full name. The reason is that pydoc needs a way to tell when a module import failed because the module isn't there vs. when a module had an actual error itself. Using the tail end of the name doesn't help me because it means I can't tell if an import of a module named 'bunk' containing the line 'import test.bunk' fails because the module 'bunk' doesn't exist or because the import line failed since in both cases name == 'bunk'. But if name == 'test.bunk' there is no ambiguity. Pydoc used to do this by inspecting the stack and seeing where the exception was thrown which is just nasty and brittle (i.e. doesn't work with importlib since the stack goes much farther until ImportError is thrown).

IOW I don't think we should be tossing out valuable data just because historically modules that didn't exist only returned the tail end of the full module name. Anyone object to switching to using the full name of the module triggering the exception? The message wouldn't change to use the full name (unfortunately) for backwards-compatibility reasons of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Fri Feb 10 15:41:19 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 10 Feb 2012 14:41:19 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1328884879.77.0.345596745695.issue1559549@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

And to answer David's joke, I carpool from Toronto to Waterloo four days a week so I have an hour each direction to work on stuff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Fri Feb 10 15:45:25 2012
From: report at bugs.python.org (Alexander Jones)
Date: Fri, 10 Feb 2012 14:45:25 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1328885125.49.0.275397962257.issue10049@psf.upfronthosting.co.za>


Alexander Jones <aj.dneg at gmail.com> added the comment:

That's very reassuring. Thanks, Nick!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Fri Feb 10 15:46:47 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 10 Feb 2012 14:46:47 +0000
Subject: [issue13947] gdbm reorganize() leaves hanging file descriptor
In-Reply-To: <1328501616.08.0.882414908885.issue13947@psf.upfronthosting.co.za>
Message-ID: <1328885207.86.0.827947557968.issue13947@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I can't reproduce. Sorry.

Reading the GDBM documentation, all filedescriptors management seem to be inside gdbm, not Python. Anyway, if I can't reproduce, I can not diagnose neither patch. Sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13947>
_______________________________________

From report at bugs.python.org  Fri Feb 10 15:46:51 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 10 Feb 2012 14:46:51 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1328885211.23.0.953102982986.issue1559549@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Oh, and there are no forward declarations for the new functions added to errors.c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Fri Feb 10 15:52:57 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 10 Feb 2012 14:52:57 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
Message-ID: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

Following the discussion on python-dev [1], this issue will track the re-organization of Lib/xml/etree to expose the C implementation (_elementtree) by default when importing ElementTree. The test suite will also have to be updated - it's required that it exercises both the C and the Python implementations.

I would like to make the import "magic" simple. Thus, the idea I currently plan to pursue is:

* xml/etree/ElementTree.py will be a simple facade that attempts to 'import *' from _elementtree, and on failure does 'import *' from pyElementTree
* The current contents of xml/etree/ElementTree.py will move to xml/etree/pyElementTree.py
* xml/etree/cElementTree.py disappears.

The test suite will be modified accordingly.


I'll be working on creating a patch for this. Any help, ideas, comments and discussions are more than welcome.


[1] http://mail.python.org/pipermail/python-dev/2012-February/116278.html

----------
components: Library (Lib)
messages: 153052
nosy: effbot, eli.bendersky, flox, scoder
priority: normal
severity: normal
status: open
title: Expose the C implementation of ElementTree by default when importing ElementTree
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Fri Feb 10 15:54:11 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 10 Feb 2012 14:54:11 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328885651.7.0.586977649079.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Oh, and not to forget: the documentation has to be updated to just not mention cElementTree any longer. For the user, the fact that a fast C library is invoked underneath should be invisible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Fri Feb 10 15:55:55 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 10 Feb 2012 14:55:55 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1328885755.24.0.519040387506.issue1559549@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Attached is Brian's patch with the macro fix and forward declarations.

----------
Added file: http://bugs.python.org/file24476/importerror.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Fri Feb 10 16:30:01 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 10 Feb 2012 15:30:01 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1328887801.93.0.211512923408.issue13703@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

So modulo my (small) review comments, David's patches are ready to go in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Fri Feb 10 16:37:17 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 10 Feb 2012 15:37:17 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <4F35399A.90408@users.sourceforge.net>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Eli Bendersky, 10.02.2012 15:52:
> * The current contents of xml/etree/ElementTree.py will move to xml/etree/pyElementTree.py

IIRC, there is a well specified way how accelerator modules should be used
by Python modules. I recall a lengthy discussion on python-dev (or the py3k
list?) back in the old pre-3.0 days, maybe there's even a PEP?

> * xml/etree/cElementTree.py disappears.

Careful with backwards compatibility here. It's the accelerator module
(_elementtree.so, IIRC) which is to be moved behind ElementTree.py.

I don't see a compelling enough reason to break imports in existing code by
removing the cElementTree module, so we should not do that.

Stefan

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Fri Feb 10 16:43:15 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 10 Feb 2012 15:43:15 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328888595.21.0.138106417039.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

>> IIRC, there is a well specified way how accelerator modules should be used
by Python modules. I recall a lengthy discussion on python-dev (or the py3k
list?) back in the old pre-3.0 days, maybe there's even a PEP?

If there's a convention, I'll happily follow it. It would be great if someone could dig up the relevant details (I'll try to look for them myself).

>> I don't see a compelling enough reason to break imports in existing code by
removing the cElementTree module, so we should not do that.

Agreed. Perhaps it should just be deprecated?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Fri Feb 10 16:46:01 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 10 Feb 2012 15:46:01 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328888761.18.0.11296719831.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Hmm, that may be PEP 399:

  If an acceleration module is provided it is to be named the same as the module it is accelerating with an underscore attached as a prefix, e.g., _warnings for warnings. The common pattern to access the accelerated code from the pure Python implementation is to import it with an import *, e.g., from _warnings import *. This is typically done at the end of the module to allow it to overwrite specific Python objects with their accelerated equivalents. 

However, it's hardly a rule, just describing a "common pattern". I wonder why this approach is preferable to the one I proposed (explicit facade module)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Fri Feb 10 16:55:23 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 10 Feb 2012 15:55:23 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328888595.21.0.138106417039.issue13988@psf.upfronthosting.co.za>
Message-ID: <4F353DD9.5020307@users.sourceforge.net>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Eli Bendersky, 10.02.2012 16:43:
>>> I don't see a compelling enough reason to break imports in existing code by
>>> removing the cElementTree module, so we should not do that.
> 
> Agreed. Perhaps it should just be deprecated?

Given that its mere existence is currently almost undocumented (except for
one tiny sentence in the docs), I vote for clearly documenting it as
deprecated, yes, with a mention to the fact that it's automatically used by
xml.etree.ElementTree starting with 3.3.

I wouldn't want to see more than that done, though, specifically not a
visible warning when it's being imported. There's far too much code out
there that uses it in previous Python versions. Such a warning would strike
even if it's only being imported conditionally with a try-except, which is
the most common way of doing it. So it would hit most users and require an
awful lot of code to be touched to fix it, for basically zero benefit.

Stefan

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Fri Feb 10 17:00:39 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 10 Feb 2012 16:00:39 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1328889640.0.0.565414851357.issue1559549@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So I just tried to pass fullname in import.c and it didn't work (of course). Looks like even when I try to use fullname in find_module_path_list() and load_next() it is still leaving out the package name. Ugh. That means either refactoring import.c to get the full name in all places, not get the full name (and thus I'm still screwed), have importlib do something different than import.c in hopes that importlib replaces import.c before this goes public, or add a full_name attribute for importlib to fill in with the full details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Fri Feb 10 17:07:44 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 10 Feb 2012 16:07:44 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328890064.46.0.759313791473.issue13988@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

A note in the doc is easy to miss IMHO, and since DeprecationWarnings are silenced by default, I don't think they will affect the final users.

A different "problem" is that developers will have to check for the Python version if they want to use ElementTree on Python >=3.3 and keep using cElementTree on <3.3 (unless another way is provided).

If possible I would avoid pyElementTree, and keep ElementTree that imports from _elementtree and the deprecated cElementTree (until it can be removed).

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Fri Feb 10 17:12:22 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 10 Feb 2012 16:12:22 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328890342.05.0.718645565166.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

> If possible I would avoid pyElementTree,

I suppose it's possible, but I'm genuinely interested in a technical reason for doing so. The approach suggested in PEP 399 is useful for module in which part of the functionality is implemented in C, and then augmented in Python. ElementTree is different - it's pretty much two separate implementations of the same API.

So, I think there's little question in terms of simplicity and clarity. Having pyElementTree and cElementTree (keeping it for backwards compat), and a facade named ElementTree that chooses between them is simple, clean and intuitive.

>From a performance point of view, consider the (by far) common case - where _elementtree *is* successfully imported. 

Option 1: from _elementtree import *, at the end of the Python implementation in ElementTree.py - so for each invocation, the whole import of the Python code has to be done, just to reach the overriding import * at the end.

Option 2: ElementTree is a facade that attempts to import _elementtree first. So the Python implementation in pyElementTree doesn't even have to be parsed and imported

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Fri Feb 10 17:30:11 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 10 Feb 2012 16:30:11 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328891411.04.0.0153696831269.issue13988@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

> If possible I would avoid pyElementTree,

Me too:
 - __name__ and __qualname__ would be less confusing
 - the cElementTree accelerator uses large parts of Python implementation

> ElementTree is different - it's pretty much two separate implementations of the same API.

Not fully separated... there's some python code hidden in the C module.

> From a performance point of view, consider the (by far) common case
> - where _elementtree *is* successfully imported.
> ... for each invocation, the whole import of the Python code has
> to be done, just to reach the overriding import * at the end.

This point is wrong... the _elementtree.c accelerator imports Python ElementTree already.

As you can see on lines 2938 to 2945, the change could lead to an import cycle:
http://hg.python.org/cpython/file/705b56512287/Modules/_elementtree.c#l2938

Trying to sort this out, it already gives me a headache.
I would like to remove the Python bootstrap code from the C module and try to do it differently, in a more standard way.

----------
stage:  -> needs patch
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Fri Feb 10 17:37:27 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 10 Feb 2012 16:37:27 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328891411.04.0.0153696831269.issue13988@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda93fxa+0DyMhR40AzoX9uzV=AZJYFjtopb2GG9MtYiTDw@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

>> From a performance point of view, consider the (by far) common case
>> - where _elementtree *is* successfully imported.
>> ... for each invocation, the whole import of the Python code has
>> to be done, just to reach the overriding import * at the end.
>
> This point is wrong... the _elementtree.c accelerator imports Python ElementTree already.
>
> As you can see on lines 2938 to 2945, the change could lead to an import cycle:
> http://hg.python.org/cpython/file/705b56512287/Modules/_elementtree.c#l2938
>
> Trying to sort this out, it already gives me a headache.
> I would like to remove the Python bootstrap code from the C module and try to do it differently, in a more standard way.
>

The Python code inside _elementtree could be moved to Python code,
which would then import the Python stuff it needs from pyElementTree.
Since pyElementTree doesn't import _elementtree, there will be
circular dependencies.

So this is a point *in favor* of pyElementTree being pure-Python :-)

In other words:

In xml/etree there is:

- ElementTree: tries to import cElementTree. On success, done. On
ImportError, imports pyElementTree
- pyElementTree: the pure Python implementation
- cElementTree: sets up the bootstrap Python code and tries to import
_elementtree. In case of an error, propagates an ImportError up.

Would that work?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Fri Feb 10 17:38:40 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 10 Feb 2012 16:38:40 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328891920.18.0.825949994708.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Oops, in last message:

s/there will be circular dependencies/there will not be circular dependencies/

----------
stage: needs patch -> 
type: performance -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Fri Feb 10 17:46:24 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 10 Feb 2012 16:46:24 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328892384.82.0.513733843252.issue13988@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> In xml/etree there is:
> - ElementTree: tries to import cElementTree. On success, done. On
>   ImportError, imports pyElementTree
> - pyElementTree: the pure Python implementation
> - cElementTree: sets up the bootstrap Python code and tries to import
>   _elementtree. In case of an error, propagates an ImportError up.

What I had in mind is more like:
 - ElementTree: defines the python code and if _elementtree is available overrides part of it with the functions imported from it;
 - cElementTree: at this point it could just be a deprecated alias for ElementTree

----------
stage:  -> needs patch
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Fri Feb 10 18:07:35 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 10 Feb 2012 17:07:35 +0000
Subject: [issue4010] configure options don't trickle down to distutils
In-Reply-To: <1222879433.22.0.765704464081.issue4010@psf.upfronthosting.co.za>
Message-ID: <1328893655.17.0.337667999045.issue4010@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/issue4010>
_______________________________________

From report at bugs.python.org  Fri Feb 10 18:14:54 2012
From: report at bugs.python.org (Peter)
Date: Fri, 10 Feb 2012 17:14:54 +0000
Subject: [issue13989] gzip always returns byte strings, no text mode
Message-ID: <1328894094.18.0.18729195074.issue13989@psf.upfronthosting.co.za>


New submission from Peter <p.j.a.cock at googlemail.com>:

Consider the following example where I have a gzipped text file,

$ python3
Python 3.2 (r32:88445, Feb 28 2011, 17:04:33) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import gzip
>>> with gzip.open("ex1.sam.gz") as handle:
...     line = handle.readline()
... 
>>> line
b'EAS56_57:6:190:289:82\t69\tchr1\t100\t0\t*\t=\t100\t0\tCTCAAGGTTGTTGCAAGGGGGTCTATGTGAACAAA\t<<<7<<<;<<<<<<<<8;;<7;4<;<;;;;;94<;\tMF:i:192\n'

Notice the file was opened in binary mode ("rb" is the default for gzip.open which is surprising given "t" is the default for open on Python 3), and a byte string is returned.

Now try explicitly using non-binary reading "r", and again you get bytes rather than a (unicode) string as I would expect:

>>> with gzip.open("ex1.sam.gz", "r") as handle:
...     line = handle.readline()
... 
>>> line
b'EAS56_57:6:190:289:82\t69\tchr1\t100\t0\t*\t=\t100\t0\tCTCAAGGTTGTTGCAAGGGGGTCTATGTGAACAAA\t<<<7<<<;<<<<<<<<8;;<7;4<;<;;;;;94<;\tMF:i:192\n'


Now try and use "t" or "rt" to be even more explicit that text mode is desired,

>>> with gzip.open("ex1.sam.gz", "t") as handle:
...     line = handle.readline()
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/pjcock/lib/python3.2/gzip.py", line 46, in open
    return GzipFile(filename, mode, compresslevel)
  File "/Users/pjcock/lib/python3.2/gzip.py", line 157, in __init__
    fileobj = self.myfileobj = builtins.open(filename, mode or 'rb')
ValueError: can't have text and binary mode at once


>>> with gzip.open("ex1.sam.gz", "rt") as handle:
...     line = handle.readline()
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/pjcock/lib/python3.2/gzip.py", line 46, in open
    return GzipFile(filename, mode, compresslevel)
  File "/Users/pjcock/lib/python3.2/gzip.py", line 157, in __init__
    fileobj = self.myfileobj = builtins.open(filename, mode or 'rb')
ValueError: can't have text and binary mode at once


See also Issue #5148 which is perhaps somewhat related.

----------
components: None
messages: 153067
nosy: maubp
priority: normal
severity: normal
status: open
title: gzip always returns byte strings, no text mode
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13989>
_______________________________________

From report at bugs.python.org  Fri Feb 10 18:26:52 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 10 Feb 2012 17:26:52 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328892384.82.0.513733843252.issue13988@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda9RXekbeWWCOeVWbF3aunNtM22H3NEi7yH8d+Pdt5SJ2Q@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

> What I had in mind is more like:
> ?- ElementTree: defines the python code and if _elementtree is available overrides part of it with the functions imported from it;

The problem with this is the bootstrap Python code executed by
_elementtree. That should not be executed when _elementtree (the C
parts) can't be imported. Keeping this code in ElementTree will
probably complicate matters since it will add import conditions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Fri Feb 10 18:32:34 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Fri, 10 Feb 2012 17:32:34 +0000
Subject: [issue13990] Benchmarks: 2to3 failures on the py3 side
Message-ID: <1328895154.39.0.105937484663.issue13990@psf.upfronthosting.co.za>


New submission from Francisco Mart?n Brugu? <francismb at email.de>:

Steps to reproduce:
after following the usage instructions from make_perf3.sh go to the the py3 benchmarks directory and run the lib/2to3 tests (python3.2 test.py). The result are 3 failures and 17 errors. The equivalent procedure in the py2 benchmarks directory succeeds (python2.7 test.py).

A summary is attached (the whole paste at http://pastebin.com/PAAhGsdR)

Cheers,
francis

----------
assignee: collinwinter
components: 2to3 (2.x to 3.x conversion tool), Benchmarks
files: FailuresErrors.txt
messages: 153069
nosy: collinwinter, francismb
priority: normal
severity: normal
status: open
title: Benchmarks: 2to3 failures on the py3 side
versions: Python 3.2
Added file: http://bugs.python.org/file24477/FailuresErrors.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13990>
_______________________________________

From report at bugs.python.org  Fri Feb 10 18:49:20 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 10 Feb 2012 17:49:20 +0000
Subject: [issue13989] gzip always returns byte strings, no text mode
In-Reply-To: <1328894094.18.0.18729195074.issue13989@psf.upfronthosting.co.za>
Message-ID: <1328896160.2.0.893301415714.issue13989@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13989>
_______________________________________

From report at bugs.python.org  Fri Feb 10 18:56:41 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 10 Feb 2012 17:56:41 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1328896601.04.0.404636061761.issue1559549@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

However you do it, I'm very much in favor of having the full name available.  I either wrote or fixed (I can't remember which) that stack walk in pydoc, and you are right, it is very very ugly.  This would also be a big benefit for unittest, which currently *doesn't* do the stack walk and therefore generates incorrect error messages when sub-imports fail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Fri Feb 10 19:23:49 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 10 Feb 2012 18:23:49 +0000
Subject: [issue13961] Have importlib use os.replace()
In-Reply-To: <1328624796.15.0.577971130856.issue13961@psf.upfronthosting.co.za>
Message-ID: <1328898229.07.0.627752799767.issue13961@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13961>
_______________________________________

From report at bugs.python.org  Fri Feb 10 19:42:53 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 10 Feb 2012 18:42:53 +0000
Subject: [issue13978] OSError exception in multiprocessing module when using
	os.remove() on NFS
In-Reply-To: <1328811848.71.0.527301304196.issue13978@psf.upfronthosting.co.za>
Message-ID: <1328899373.09.0.69517773885.issue13978@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

"""
OSError: [Errno 16] Device or resource busy: '/nfs/tmp/pymp-f7R9S6/.nfs00000000e039692f00000236'
"""

That's because the temporary directory is removed while a file inside is still open.
And that's really likely the unix socket used by the server's listener.

What happens if you do this instead:
"""
import multiprocessing
 
manager = multiprocessing.Manager()
manager.shutdown()
del manager
"""

You should shutdown the manager before it gets garbage collected.

> (the TMDIR directory is in a nfs server)

Bad idea, for the following reasons:
- you're actually lucky Linux allows binding unix sockets over NFS filesystems, some Unix flavors don't
- you're likely to run into similar problems, because code which removes a temporary directory while having still an open FD is quite common, and will break with a tmp dir over NFS
- mkstemp() and friends use O_EXCL to create a temporary file securely, and some NFS implementations of O_EXCL are unsafe (should be OK with NFSv3 and later though)
- it's not a good idea performance wise

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13978>
_______________________________________

From report at bugs.python.org  Fri Feb 10 19:46:05 2012
From: report at bugs.python.org (Eric Talevich)
Date: Fri, 10 Feb 2012 18:46:05 +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: <1328899565.96.0.384982046394.issue9257@psf.upfronthosting.co.za>


Eric Talevich <eric.talevich at gmail.com> added the comment:

Well, this is not the best month for me to try digging into a new codebase... I would not mind if someone else did the patch for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9257>
_______________________________________

From report at bugs.python.org  Fri Feb 10 20:02:50 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 10 Feb 2012 19:02:50 +0000
Subject: [issue13990] Benchmarks: 2to3 failures on the py3 side
In-Reply-To: <1328895154.39.0.105937484663.issue13990@psf.upfronthosting.co.za>
Message-ID: <1328900570.08.0.499644931951.issue13990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

It looks like 2to3 isn't being converted properly. Benjamin, is lib2to3 supposed to work on itself and result in a sane output? If not then the benchmark should probably drop its internal copy of lib2to3.

Antoine (since you last looked at the benchmark suite for Python 3), do you know anything about this?

----------
assignee: collinwinter -> benjamin.peterson
nosy: +benjamin.peterson, brett.cannon, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13990>
_______________________________________

From report at bugs.python.org  Fri Feb 10 20:05:46 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 10 Feb 2012 19:05:46 +0000
Subject: [issue13990] Benchmarks: 2to3 failures on the py3 side
In-Reply-To: <1328895154.39.0.105937484663.issue13990@psf.upfronthosting.co.za>
Message-ID: <1328900746.68.0.455290813358.issue13990@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/issue13990>
_______________________________________

From report at bugs.python.org  Fri Feb 10 20:23:57 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 10 Feb 2012 19:23:57 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1328887801.93.0.211512923408.issue13703@psf.upfronthosting.co.za>
Message-ID: <CAGE7PNJ7B+xR14oDEWeFD8SJD6AMnzcu0WC7EWTYh2Xoqv4GOg@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

Thanks for reviewing Benjamin.  I'm also reviewing this today.  Sorry
for the delay!

BTW, like Schadenfreude?  A hash collision DOS issue "fix" patch for
PHP5 was done poorly and introduced a new security vulnerability that
was just used to let script kiddies root many servers all around the
web:  http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-0830

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Fri Feb 10 21:43:29 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 10 Feb 2012 20:43:29 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328906609.99.0.242117228035.issue13988@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

>>  - ElementTree: defines the python code and if _elementtree is 
>>  available overrides part of it with the functions imported from it;

> The problem with this is the bootstrap Python code executed by
_elementtree.

This might become unnecessary if ElementTree becomes the main module and _elementtree only contains a few faster functions/classes that are supposed to replace the ones written in Python.
So basically you only have a single fully functional Python module (ElementTree) plus an optional C module (_elementtree) that only provides faster replacements for ElementTree.

> That should not be executed when _elementtree (the C parts) can't be
> imported.

We are assuming that _elementtree might be missing, but what are the cases where this might actually happen? Other implementations like PyPy? Exotic platforms that can't compile _elementtree?

> Keeping this code in ElementTree will probably complicate 
> matters since it will add import conditions.

Wouldn't that as simple as having in ElementTree.py:
...
full python code here...
...
try:
    # override a few functions/classes with the faster versions
    from _elementtree import *
except ImportError:
    # _elementtree is missing, so we just keep the "slow" versions
    pass
else:
    # do the rest here if at all needed (e.g. plug the faster
    # versions in the right places)

I'm not familiar with ElementTree (I just looked at the bootstrap bit quickly), so what I'm saying might not be applicable here, but I've seen other modules doing something similar to what I'm proposing (json, heapq, maybe even warning and others).

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Fri Feb 10 21:53:23 2012
From: report at bugs.python.org (andrea crotti)
Date: Fri, 10 Feb 2012 20:53:23 +0000
Subject: [issue13991] namespace packages depending on order
Message-ID: <1328907203.29.0.677752935093.issue13991@psf.upfronthosting.co.za>


New submission from andrea crotti <andrea.crotti.0 at gmail.com>:

I am not really sure that it is a bug, but for me it's at least not the expected behaviour.
In short supposing I have two namespace packages ab and ac (as seen in the tar file), this works perfectly:

import sys
from os import path
sys.path.append(path.abspath('ab'))
sys.path.append(path.abspath('ac'))

from a.b import api as api_ab
from a.c import api as api_ac


But this doesn't:
import sys
from os import path
sys.path.append(path.abspath('ab'))

from a.b import api as api_ab

sys.path.append(path.abspath('ac'))
from a.c import api as api_ac

And raises an ImportError
from a.c import api as api_ac
ImportError: No module named c

Which means that if you actually append all the paths containing package resources before trying to import something it works, but if you interleave the path mangling, it won't..

Is this a bug or maybe I'm doing something wrong?

----------
assignee: tarek
components: Distutils
files: namespace.tar.gz
messages: 153076
nosy: andrea.crotti, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: namespace packages depending on order
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file24478/namespace.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13991>
_______________________________________

From report at bugs.python.org  Fri Feb 10 22:17:45 2012
From: report at bugs.python.org (Mike Hoy)
Date: Fri, 10 Feb 2012 21:17:45 +0000
Subject: [issue13198] Remove duplicate definition of write_record_file
In-Reply-To: <1328846249.62.0.46135445719.issue13198@psf.upfronthosting.co.za>
Message-ID: <CADpHpMNqbCbn2VMd=kqP00jwVLnjgxsX75ugkLkffFOFDfskpg@mail.gmail.com>


Mike Hoy <mhoy09 at gmail.com> added the comment:

I am unable to work on this issue at this time.

On Thu, Feb 9, 2012 at 8:57 PM, ?ric Araujo <report at bugs.python.org> wrote:

>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Mike, if you don?t have the time to finish this shortly, I will do it, as
> I need this fixed for another bug.  Just let me know if you?d like to do it.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13198>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13198>
_______________________________________

From report at bugs.python.org  Fri Feb 10 22:39:52 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 10 Feb 2012 21:39:52 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328909992.28.0.0977817823254.issue13988@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

The first step is to strip out the cElementTree bootstrap code from the C module.
I did it in the attached patch (plus removal of obsolete code for copy() in Python 2.4).
This passes the unmodified tests "test_xml_etree" and "test_xml_etree_c".

Then I think the right approach is to fold completely cElementTree behind ElementTree.
The cElementTree alias can be simply declared in Lib/xml/etree/__init__.py.

----------
keywords: +patch
Added file: http://bugs.python.org/file24479/issue13988_prepare_pep399.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Fri Feb 10 22:52:53 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 10 Feb 2012 21:52:53 +0000
Subject: [issue13974] packaging: test for set_platform()
In-Reply-To: <1328775875.69.0.230962367845.issue13974@psf.upfronthosting.co.za>
Message-ID: <1328910773.78.0.962921130598.issue13974@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

It indeed was permanent. The new patch fixes the issue.

----------
Added file: http://bugs.python.org/file24480/test-set-platform-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13974>
_______________________________________

From report at bugs.python.org  Fri Feb 10 23:34:39 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Feb 2012 22:34:39 +0000
Subject: [issue13619] Add a new codec: "locale", the current locale encoding
In-Reply-To: <1324102425.92.0.741478756596.issue13619@psf.upfronthosting.co.za>
Message-ID: <1328913279.55.0.634099259688.issue13619@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

According to the discussion on the python-dev mailing list, such codec would add too much confusion to users and so it is better to not add it.
http://mail.python.org/pipermail/python-dev/2012-February/116272.html

I close the issue as wont fix.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13619>
_______________________________________

From report at bugs.python.org  Sat Feb 11 00:02:00 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Feb 2012 23:02:00 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1328914920.6.0.417185276952.issue13703@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Review of add-randomization-(...).patch:
 - there is a missing ")" in the doc, near "the types covered by the :option:`-R` option (or its equivalent, :envvar:`PYTHONHASHRANDOMIZATION`."
 - get_hash() in test_hash.py fails completly on Windows: Windows requires some environment variables. Just use env=os.environ.copy() instead of env={}.
 - PYTHONHASHSEED doc is not clear: it should be mentionned that the variable is ignored if PYTHONHASHRANDOMIZATION is not set
 - (Python 2.6) test_hash fails because of "[xxx refs]" in stderr if Python is compiled in debug mode. Add strip_python_stderr() to test_support.py and use it in get_hash().

def strip_python_stderr(stderr):
    """Strip the stderr of a Python process from potential debug output
    emitted by the interpreter.

    This will typically be run on the result of the communicate() method
    of a subprocess.Popen object.
    """
    stderr = re.sub(br"\[\d+ refs\]\r?\n?$", b"", stderr).strip()
    return stderr

Except these minor nits, the patches (2.6 and 3.1) looks good. I didn't read the tests patches: just run the tests to test them :-) (Or our buildbots will do the work for you.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Sat Feb 11 00:35:44 2012
From: report at bugs.python.org (Eric Snow)
Date: Fri, 10 Feb 2012 23:35:44 +0000
Subject: [issue13991] namespace packages depending on order
In-Reply-To: <1328907203.29.0.677752935093.issue13991@psf.upfronthosting.co.za>
Message-ID: <1328916944.39.0.801015687242.issue13991@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13991>
_______________________________________

From report at bugs.python.org  Sat Feb 11 00:49:17 2012
From: report at bugs.python.org (Jim Jewett)
Date: Fri, 10 Feb 2012 23:49:17 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1328914920.6.0.417185276952.issue13703@psf.upfronthosting.co.za>
Message-ID: <CA+OGgf5WC9s5bvpFBJwZMZNiK1bBPEf3xdsNMuf3daoguPxYfA@mail.gmail.com>


Jim Jewett <jimjjewett at gmail.com> added the comment:

On Fri, Feb 10, 2012 at 6:02 PM, STINNER Victor

> ?- PYTHONHASHSEED doc is not clear: it should be mentionned
> that the variable is ignored if PYTHONHASHRANDOMIZATION
> is not set

*That* is why this two-envvar solution bothers me.

PYTHONHASHSEED has to be a string anyhow, so why not just get rid of
PYTHONHASHRANDOMIZATION?

Use PYTHONHASHSEED=random to use randomization.

Other values that cannot be turned into an integer will be (currently)
undefined.  (You may want to raise a fatal error, on the assumption
that errors should not pass silently.)

A missing PYTHONHASHSEED then has the pleasant interpretation of
defaulting to "0" for backwards compatibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Sat Feb 11 01:31:31 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 11 Feb 2012 00:31:31 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1328920291.22.0.36711091553.issue10227@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Kristj?n, I ran the benchmarks from http://bugs.python.org/issue10227#msg143731
in the current cpython and pep-3118 repos. In both cases the differences between
Linux and Windows are far less pronounced than they used to be. All benchmarks
were run with the x64 builds.

I also ran the profile guided optimization build for Visual Studio. The
results are equal to (or better than) the non-pgo gcc results. In my
experience Visual Studio relies heavily on PGO for x64 builds. The
default optimizer is just not as good as gcc's.


If you can reproduce similar results, I think we can close this issue.


./python -m timeit -n 10000000 -s "x = ((b'x'*10000))" "x[:100]"

linux-cpython (4244e4348362):             0.102 usec
linux-pep-3118 (memoryview:534f6bbe5422): 0.098 usec

windows-cpython:       0.109 usec
windows-pep-3118:      0.112 usec usec
windows-pep-3118-pgo:  0.103 usec


./python -m timeit -n 10000000 -s "x = (bytearray(b'x'*10000))" "x[:100]"

linux-cpython (4244e4348362):             0.107 usec
linux-pep-3118 (memoryview:534f6bbe5422): 0.109 usec

windows-cpython:      0.127 usec
windows-pep-3118:     0.128 usec
windows-pep-3118-pgo: 0.106 usec


./python -m timeit -n 10000000 -s "x = memoryview(bytearray(b'x'*10000))" "x[:100]"

linux-cpython (4244e4348362):             0.127 usec
linux-pep-3118 (memoryview:534f6bbe5422): 0.12 usec

windows-cpython:      0.145 usec
windows-pep-3118:     0.14 usec
windows-pep-3118-pgo: 0.0984 usec

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10227>
_______________________________________

From report at bugs.python.org  Sat Feb 11 01:56:48 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 11 Feb 2012 00:56:48 +0000
Subject: [issue13972] set and frozenset constructors don't accept multiple
	iterables
In-Reply-To: <1328775388.29.0.217148871947.issue13972@psf.upfronthosting.co.za>
Message-ID: <1328921808.75.0.453073594517.issue13972@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

It is present in union and intersection because chained operations are reasonably common.  I don't think it makes much sense in the constructors because it doesn't correspond to how people think of (make this a set).

----------
assignee:  -> rhettinger
nosy: +rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13972>
_______________________________________

From report at bugs.python.org  Sat Feb 11 02:00:19 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 11 Feb 2012 01:00:19 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1328922019.05.0.999776199007.issue13968@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I would like to see this one API remain simple and leave more complex tasks to os.walk et al.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Sat Feb 11 04:34:51 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 11 Feb 2012 03:34:51 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328931291.95.0.141909437249.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Ezio,

>> We are assuming that _elementtree might be missing, but what are the cases where this might actually happen? Other implementations like PyPy? Exotic platforms that can't compile _elementtree?

I guess both. To make the stdlib work on PyPy without changes, it has to be able to load the pure Python modules in a fallback.

As for platforms that can't compile _elementtree, keep in mind that there's also expat which _elementtree uses, so it's a lot of code to compile. Python works on some embedded systems, I'm not sure all of them can compile this code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sat Feb 11 04:46:47 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 03:46:47 +0000
Subject: [issue13959] Re-implement parts of imp in pure Python
In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za>
Message-ID: <1328932007.28.0.578955509867.issue13959@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/issue13959>
_______________________________________

From report at bugs.python.org  Sat Feb 11 04:48:32 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 03:48:32 +0000
Subject: [issue13966] Add disable_interspersed_args() to
	argparse.ArgumentParser
In-Reply-To: <1328687368.18.0.265955669963.issue13966@psf.upfronthosting.co.za>
Message-ID: <1328932112.53.0.20900067397.issue13966@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> bethard
nosy: +bethard
type:  -> enhancement
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13966>
_______________________________________

From report at bugs.python.org  Sat Feb 11 04:54:09 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 11 Feb 2012 03:54:09 +0000
Subject: [issue13966] Add disable_interspersed_args() to
	argparse.ArgumentParser
In-Reply-To: <1328687368.18.0.265955669963.issue13966@psf.upfronthosting.co.za>
Message-ID: <1328932449.28.0.740621664392.issue13966@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

The idea and patch seem okay to me. Needs tests though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13966>
_______________________________________

From report at bugs.python.org  Sat Feb 11 04:59:53 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 03:59:53 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1328932793.26.0.0755325120628.issue9750@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Petri, I think you can go ahead.

Lucas, thanks for your help, even though your patch is not used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9750>
_______________________________________

From report at bugs.python.org  Sat Feb 11 05:06:00 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 11 Feb 2012 04:06:00 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328933160.4.0.295458153774.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Florent, thanks for the patch - at this point code is more useful than talk :-)

Anyhow, I tried to apply it and a few tests in test_xml_etree_c fail, because it can't find fromstring and fromstringlist. This gets fixed when I import fromstringlist in cElementTree.py from ElementTree, and in the same file assign:

  fromstring = XML

Which is similar to what ElementTree itself does.

In general, I agree that a good first step would be to refactor the code to extract the boostrapping from _elementtree.c to cElementTree.py. As long as the tests pass, this can be committed regardless of this issue's original intent.

However, why did you leave some bootstrapping code inside? Can't all of it go away?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sat Feb 11 05:24:01 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 11 Feb 2012 04:24:01 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328934241.54.0.583151782615.issue13988@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/issue13988>
_______________________________________

From report at bugs.python.org  Sat Feb 11 05:24:44 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 11 Feb 2012 04:24:44 +0000
Subject: [issue13959] Re-implement parts of imp in pure Python
In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za>
Message-ID: <1328934284.77.0.542865420063.issue13959@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/issue13959>
_______________________________________

From report at bugs.python.org  Sat Feb 11 05:27:28 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 11 Feb 2012 04:27:28 +0000
Subject: [issue13981] time.sleep() should use nanosleep() if available
In-Reply-To: <1328828434.41.0.993247720876.issue13981@psf.upfronthosting.co.za>
Message-ID: <1328934448.18.0.139267921945.issue13981@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/issue13981>
_______________________________________

From report at bugs.python.org  Sat Feb 11 05:44:24 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 04:44:24 +0000
Subject: [issue13123] bdist_wininst uninstaller does not remove pycache
	directories
In-Reply-To: <1318000960.21.0.140069466315.issue13123@psf.upfronthosting.co.za>
Message-ID: <1328935464.94.0.205624052711.issue13123@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

So I had a quick look at the code and found the lines in need of a fix.  The problem comes as usual from our friend ?path + optimize and 'o' or 'c'?.  I can read some C, so I tried to replace that with imp.cache_from_source, but a real C programmer should take it from here, especially if they find themselves on Windows so that they can recompile the wininst*.exe file and test the fix :)

----------
keywords: +patch
nosy: +mhammond
Added file: http://bugs.python.org/file24481/bdist_wininst-pycache-removal.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13123>
_______________________________________

From report at bugs.python.org  Sat Feb 11 05:47:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 04:47:07 +0000
Subject: [issue11254] distutils doesn't byte-compile .py files to __pycache__
	during installation
In-Reply-To: <1298195698.48.0.330644441328.issue11254@psf.upfronthosting.co.za>
Message-ID: <1328935627.11.0.883683566166.issue11254@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See also #13123 for the same bug in bdist_wininst.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11254>
_______________________________________

From report at bugs.python.org  Sat Feb 11 05:56:32 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 04:56:32 +0000
Subject: [issue13953] Get rid of doctests in packaging.tests.test_version
In-Reply-To: <1328554740.27.0.167211242761.issue13953@psf.upfronthosting.co.za>
Message-ID: <1328936192.43.0.44236998698.issue13953@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks, I?ve got it from that point.

Notes for future patches:
- Tests should not check the exact contents of error messages, as they are not part of the language
- Don?t use assertEqual(..., True) but assertTrue, or if you?re testing comparisons, use assertGreater and friends (or check the result of sorted(somelist) to compare a bunch of objects at once)

----------
Added file: http://bugs.python.org/file24482/cleanup-test_version.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13953>
_______________________________________

From report at bugs.python.org  Sat Feb 11 05:59:24 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 04:59:24 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>
Message-ID: <1328936364.65.0.748935933918.issue12659@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> BTW: in distutils2 I get (not because of this change):
Actually I did fix that, but depending on your Python version the conditional in the test may be wrong.  What?s the Python version you used?

>> If so, could you provide a patch this time?
> Done. The patch is against default.
packaging is only in default, so yeah :)  Thanks.

> what about against distutils2? Do you need also a patch for it?
I can port from p7g to d2, no worries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12659>
_______________________________________

From report at bugs.python.org  Sat Feb 11 06:12:14 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 05:12:14 +0000
Subject: [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>
Message-ID: <1328937134.2.0.177722215774.issue13491@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> No examples included in the documentation now require createdb.py to be run.
Cool!  These fixes should make it to 2.7 too; I can propose a patch if you don?t want to backport yourself.

> In the Doc/includes/sqlite3 directory there are still some scripts that require the
> createdb.py, so I didn't nuke the file.
Do these scripts (or a README file) explain about createdb.py?

> I also removed the strange "The arguments to :meth:`executescript` must be :func:`bytes`
> objects" sentence from the patch. I assume it was a mistake, as it's wrong.
Why not change it so that it?s correct?  (Maybe looking at the file history would show where the mistake comes from.)

> Ah, and I added a working example of a custom text_factory function
Nice.

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13491>
_______________________________________

From report at bugs.python.org  Sat Feb 11 06:16:25 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 05:16:25 +0000
Subject: [issue13180] pysetup silently ignores invalid entries in setup.cfg
In-Reply-To: <1318614439.75.0.304667021355.issue13180@psf.upfronthosting.co.za>
Message-ID: <1328937385.56.0.0372029826908.issue13180@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

A side effect of this change will be the removal of the Extension class, which was only useful to do some typechecks/conversions on its arguments.  In Python code it will be replaced by a dict (with keys 'name', 'sources', 'optional', etc.), and when building this dict from a setup.cfg the config parser will validate/convert the values read.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13180>
_______________________________________

From report at bugs.python.org  Sat Feb 11 06:17:38 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 05:17:38 +0000
Subject: [issue13972] set and frozenset constructors don't accept multiple
	iterables
In-Reply-To: <1328775388.29.0.217148871947.issue13972@psf.upfronthosting.co.za>
Message-ID: <1328937458.29.0.906381692756.issue13972@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

As a set user (not developer), I think that the proposed feature is not needed, and the change would make set/frozenset less similar to list and tuple, which would be a bad thing.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13972>
_______________________________________

From report at bugs.python.org  Sat Feb 11 06:23:11 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 05:23:11 +0000
Subject: [issue12297] Clarifications to atexit.register and unregister doc
In-Reply-To: <1307634551.41.0.658857259056.issue12297@psf.upfronthosting.co.za>
Message-ID: <1328937791.91.0.510141217287.issue12297@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Maybe one of you gentlemen would like to review this.

----------
nosy: +ezio.melotti, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12297>
_______________________________________

From report at bugs.python.org  Sat Feb 11 06:25:58 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 05:25:58 +0000
Subject: [issue11122] bdist_rpm fails
In-Reply-To: <1296854362.61.0.538085175842.issue11122@psf.upfronthosting.co.za>
Message-ID: <1328937958.8.0.112289473935.issue11122@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Given that we?ve made changes to distutils for Debian multiarch or Mac OS X compiler breakage, I now think that switching distutils to only use rpmbuild would be reasonable.

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11122>
_______________________________________

From report at bugs.python.org  Sat Feb 11 06:27:46 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 05:27:46 +0000
Subject: [issue1051216] make distutils.core.run_setup re-entrant
Message-ID: <1328938066.14.0.635075879968.issue1051216@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ll reopen this report if someone can provide an example that triggers the bug.

----------
resolution:  -> wont fix
status: open -> closed
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1051216>
_______________________________________

From report at bugs.python.org  Sat Feb 11 06:32:24 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 05:32:24 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328938344.35.0.897611983362.issue13988@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I strongly feel that existing code importing ElementTree or cElementTree should not be broken.  Let?s add transparent import from _elementtree to ElementTree without breaking existing uses of cET.

I think that 3.2 and 2.7 should get a doc note about cET, do we have a bug for this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sat Feb 11 06:43:11 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 05:43:11 +0000
Subject: [issue13991] namespace packages depending on order
In-Reply-To: <1328907203.29.0.677752935093.issue13991@psf.upfronthosting.co.za>
Message-ID: <1328938991.05.0.895269839941.issue13991@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Are you using pure-stdlib namespace packages, i.e. things using distutils and pkgutil.extend_path, or setuptools? notion of namespace packages?  (I didn?t check your archive, in general we dislike binary files on this tracker and use text all the time.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13991>
_______________________________________

From report at bugs.python.org  Sat Feb 11 06:44:09 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 05:44:09 +0000
Subject: [issue13974] packaging: test for set_platform()
In-Reply-To: <1328775875.69.0.230962367845.issue13974@psf.upfronthosting.co.za>
Message-ID: <1328939049.37.0.810085702295.issue13974@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

:) Will commit.

----------
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13974>
_______________________________________

From report at bugs.python.org  Sat Feb 11 06:45:06 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 05:45:06 +0000
Subject: [issue13198] Remove duplicate definition of write_record_file
In-Reply-To: <1318857154.54.0.641953188635.issue13198@psf.upfronthosting.co.za>
Message-ID: <1328939106.2.0.93922800238.issue13198@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

OK.  Thanks for your help!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13198>
_______________________________________

From report at bugs.python.org  Sat Feb 11 06:48:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 05:48:07 +0000
Subject: [issue13175] packaging uses wrong line endings in RECORD files on
	Windows
In-Reply-To: <1318546022.2.0.0477576720396.issue13175@psf.upfronthosting.co.za>
Message-ID: <1328939287.71.0.742015489171.issue13175@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I just did pip install distutils2 in a virtualenv. If that doesn't work then yes,
> I got the wrong one :-(
You need to get a development repo to make patches, not a released version, just like for CPython.

> Do I need to hg clone then do some magic pip incantation to get it installed?
Why would you want to install it?  Clone it, hack on it in place, run tests in place.  :)

FTR, ?bin/pip install -e .? is the command to ?install? a project in develop (or editable) mode with pip in a virtualenv.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13175>
_______________________________________

From report at bugs.python.org  Sat Feb 11 06:55:14 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 05:55:14 +0000
Subject: [issue13952] mimetypes doesn't recognize .csv
In-Reply-To: <1328550236.31.0.476108753678.issue13952@psf.upfronthosting.co.za>
Message-ID: <1328939714.48.0.573848287288.issue13952@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve been one to argue that additions to the mimetypes registry are clearly new features.  Now if two senior devs like you think otherwise, I?m reconsidering.  These additions can?t possibly break code, can they?  So I can agree with a viewpoint that mimetypes should match what the IANA publishes and that adding missing types is a bugfix.  (It?s less disturbing than updating HTMLParser for example, and I agree with that.)  Georg?s inclusion of a registry addition for IIRC 3.2.2 would also indicate RM support for this viewpoint.

About Antoine?s remark: mimetypes already reads mime.types files, so even if our internal registry is not up-to-date the module should know about all types present in /etc/mime.types.

----------
nosy: +eric.araujo, sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13952>
_______________________________________

From report at bugs.python.org  Sat Feb 11 06:57:27 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 05:57:27 +0000
Subject: [issue13719] bdist_msi upload fails
In-Reply-To: <1325855918.9.0.207720990162.issue13719@psf.upfronthosting.co.za>
Message-ID: <1328939847.67.0.32302068275.issue13719@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t know if the bdist_msi command runs without user interaction.  If so, then the test in the attached patch should pass on Windows.  Can you please test it?

----------
Added file: http://bugs.python.org/file24483/fix-bdist_msi-upload-with-test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13719>
_______________________________________

From report at bugs.python.org  Sat Feb 11 07:20:03 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Feb 2012 06:20:03 +0000
Subject: [issue13193] packaging.tests.test_manifest and
	distutils.tests.test_filelist failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1328941203.23.0.889430095801.issue13193@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Attached is Vinay?s fix as a diff.  Can someone test this patch on Windows or any of the other OSes that showed failures?

----------
keywords: +patch
title: test_packaging and test_distutils failures -> packaging.tests.test_manifest and distutils.tests.test_filelist failures
Added file: http://bugs.python.org/file24484/fix-packaging-manifest.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Sat Feb 11 08:41:29 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 11 Feb 2012 07:41:29 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328938344.35.0.897611983362.issue13988@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda9tr1HFRZU86iJDMJ6cqh-Y4kQMSiGXJPwccKi2V=SaPw@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

> I strongly feel that existing code importing ElementTree or cElementTree should not be broken. ?Let?s add transparent import from _elementtree to ElementTree without breaking existing uses of cET.
>

AFAICS there's currently no disagreement on this point. The import
from cElementTree will keep working in 3.3 as it always had. However,
the explicit mention of cElementTree should be removed from the
documentation of ElementTree. The only remaining question is whether a
silent deprecation warning should be added in cElementTree.

> I think that 3.2 and 2.7 should get a doc note about cET, do we have a bug for this?
>

What doc note? Something in the spirit of: "Note that in 3.3, the
accelerated C implementation will be provided by default when
importing ElementTree" - or do you mean something else?

I don't think there's an open bug for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sat Feb 11 08:54:18 2012
From: report at bugs.python.org (Warren Turkal)
Date: Sat, 11 Feb 2012 07:54:18 +0000
Subject: [issue13922] argparse handling multiple "--" in args improperly
In-Reply-To: <1328132556.72.0.92385645061.issue13922@psf.upfronthosting.co.za>
Message-ID: <1328946858.91.0.00159536282519.issue13922@psf.upfronthosting.co.za>


Changes by Warren Turkal <wt at penguintechs.org>:


----------
versions: +Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13922>
_______________________________________

From report at bugs.python.org  Sat Feb 11 09:08:56 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 11 Feb 2012 08:08:56 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328947736.89.0.0896137937775.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

The more I think about it, the more the bootstrap code in _elementtree.c annoys me. It's the only instance of calling PyRun_String in Modules/ !

It's hackish and causes ugly import problems. If the C code needs stdlib functionality like copy.deepcopy, it should use PyImport_ImportModule like everyone else and not through a PyRun_String hack.

Since we've already decided to do some refactoring, I suggest all trace of the bootstrap is removed from _elementtree.c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sat Feb 11 09:39:15 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 11 Feb 2012 08:39:15 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328947736.89.0.0896137937775.issue13988@psf.upfronthosting.co.za>
Message-ID: <4F362922.9090100@users.sourceforge.net>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Eli Bendersky, 11.02.2012 09:08:
> The more I think about it, the more the bootstrap code in _elementtree.c
> annoys me. It's the only instance of calling PyRun_String in Modules/ !
> 
> It's hackish and causes ugly import problems. If the C code needs stdlib
> functionality like copy.deepcopy, it should use PyImport_ImportModule
> like everyone else and not through a PyRun_String hack.

I find it perfectly legitimate to run Python code from a C module.
Certainly not a hack. We all know that most non-trivial functionality can
be expressed much easier in Python than in C, that's why we use Python
after all. In particular, defining a class with attributes and methods is a
couple of lines of code in Python, but a huge amount of code in C. Avoiding
the complexity of writing everything in C, or even of splitting the code in
a harder to understand way, is worth it.

That being said, I think it's worth removing any clear *redundancy* with
ET.py, as Florent's patch did. The goal is to keep _elementtree.c a pure
accelerator module that improves plain ElementTree, and redundancy is
counterproductive in this context. But if the implementation differs for
some reason, I would tend towards leaving it as is.

Stefan

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sat Feb 11 09:58:00 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 11 Feb 2012 08:58:00 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328950680.67.0.791108024566.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

>> I find it perfectly legitimate to run Python code from a C module.
Certainly not a hack. We all know that most non-trivial functionality can
be expressed much easier in Python than in C, that's why we use Python
after all. In particular, defining a class with attributes and methods is a couple of lines of code in Python, but a huge amount of code in C. Avoiding the complexity of writing everything in C, or even of splitting the code in a harder to understand way, is worth it.
<<

There can be arguments both way, but if we follow the lead of existing standard extension modules, the tendency is clearly not to use PyRun_String. Many C extensions use functionality from Python, but none does it the "bootstrap way". Why is that? Is there a good reason, or is it just convention?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sat Feb 11 10:20:16 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Sat, 11 Feb 2012 09:20:16 +0000
Subject: [issue13953] Get rid of doctests in packaging.tests.test_version
In-Reply-To: <1328936192.43.0.44236998698.issue13953@psf.upfronthosting.co.za>
Message-ID: <4F36331E.7090909@email.de>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

Thank you for the review. Just some questions:

Isn't that what the previous code (doctest code) did?

I thought that the code should be ported as far backwards as possible 
and that's why I used the plain assertEqual (I don't know exactly in 
with version the other assert methods were introduced. Unittest2?)

Can one use all the new unittest2 methods to test packaging (distutils2)
code?

> ----------
> Added file: http://bugs.python.org/file24482/cleanup-test_version.diff
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue13953>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13953>
_______________________________________

From report at bugs.python.org  Sat Feb 11 10:23:49 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 11 Feb 2012 09:23:49 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328952229.25.0.343240220028.issue13988@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

> Anyhow, I tried to apply it and a few tests in test_xml_etree_c fail,
> because it can't find fromstring and fromstringlist.

Ooops, I cut some redundancy after running the tests, and I forgot to re-add the import. You're right.

> However, why did you leave some bootstrapping code inside?
> It's the only instance of calling PyRun_String in Modules/

I just tried to cut the import cycle and import it the other way.
I think it was done like that historically, for some reason, when
the module was first developped (for Python 1.5 maybe ...)
It is not necessary to remove all the Python code at once, and I am better at Python than at C.
We can delay this additional clean-up at a later time, it does not
block the PEP399 implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sat Feb 11 10:35:22 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 11 Feb 2012 09:35:22 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328952922.76.0.327314224812.issue13988@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Updated patch:
 - fixed missing import and missing alias
 - moved the XMLTreeBuilder alias to the Python module

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sat Feb 11 10:37:29 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 11 Feb 2012 09:37:29 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328953049.6.0.25661758133.issue13988@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Added file: http://bugs.python.org/file24485/issue13988_prepare_pep399_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sat Feb 11 10:42:19 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Sat, 11 Feb 2012 09:42:19 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1328936364.65.0.748935933918.issue12659@psf.upfronthosting.co.za>
Message-ID: <4F36384F.7010705@email.de>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

On 02/11/2012 05:59 AM, ?ric Araujo wrote:

>> BTW: in distutils2 I get (not because of this change):
> Actually I did fix that, but depending on your Python version the conditional in the test may be wrong.  What?s the Python version you used?

I did:
python2.7 runtests.py

The exact version is: python2.7 -V -->
Python 2.7.2+

and the machine is a Debian: uname -a -->
Linux random 3.1.0-1-amd64 #1 SMP Tue Jan 10 05:01:58 UTC 2012 x86_64 
GNU/Linux

Thanks for your time as mentor!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12659>
_______________________________________

From report at bugs.python.org  Sat Feb 11 10:55:35 2012
From: report at bugs.python.org (Paul Moore)
Date: Sat, 11 Feb 2012 09:55:35 +0000
Subject: [issue13123] bdist_wininst uninstaller does not remove pycache
	directories
In-Reply-To: <1328935464.94.0.205624052711.issue13123@psf.upfronthosting.co.za>
Message-ID: <CACac1F9WWdogtyGm8U71XZTCb0NPb35j2VQg0CW6x4K3n5nz0w@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

I'll try to take a look over the next couple of days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13123>
_______________________________________

From report at bugs.python.org  Sat Feb 11 10:57:36 2012
From: report at bugs.python.org (Paul Moore)
Date: Sat, 11 Feb 2012 09:57:36 +0000
Subject: [issue13175] packaging uses wrong line endings in RECORD files on
	Windows
In-Reply-To: <1328939287.71.0.742015489171.issue13175@psf.upfronthosting.co.za>
Message-ID: <CACac1F9+MJFpjDUp9in1eYtVouScKrr9FeO1swuJJrpmQ8ZWJw@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

>> Do I need to hg clone then do some magic pip incantation to get it installed?
> Why would you want to install it? ?Clone it, hack on it in place, run tests in place. ?:)
>
> FTR, ?bin/pip install -e .? is the command to ?install? a project in develop (or editable) mode with pip in a virtualenv.

Thanks, that's what I needed. I'm new to pip and know little more than
"pip install" :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13175>
_______________________________________

From report at bugs.python.org  Sat Feb 11 11:29:55 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 11 Feb 2012 10:29:55 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <E1RwADK-0006Iv-46@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 31dfb4be934d by Florent Xicluna in branch 'default':
Issue #13988: move the python bootstrap code to cElementTree.py, and remove obsolete code for Python 2.4 and 2.5.
http://hg.python.org/cpython/rev/31dfb4be934d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sat Feb 11 11:39:17 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 11 Feb 2012 10:39:17 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328956757.66.0.539247367144.issue13988@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I've pushed this first part, which is just a code refactoring.

I tried to work out a patch for the second part.
The tricky thing is because of xml.etree still using doctests.
The patch for the tests seems to be enough small and readable.

We have small differences between C and Python, about the warnings beeing raised. In general the C implementation do not raise the deprecation warnings. IMHO, this could be fixed later.

Still missing is the patch for the documentation.

----------
Added file: http://bugs.python.org/file24486/issue13988_fold_cET_behind_ET.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sat Feb 11 12:15:27 2012
From: report at bugs.python.org (andrea crotti)
Date: Sat, 11 Feb 2012 11:15:27 +0000
Subject: [issue13991] namespace packages depending on order
In-Reply-To: <1328907203.29.0.677752935093.issue13991@psf.upfronthosting.co.za>
Message-ID: <1328958927.34.0.321805124635.issue13991@psf.upfronthosting.co.za>


andrea crotti <andrea.crotti.0 at gmail.com> added the comment:

There is nothing binary in the archive, just a simple example of namespace packages, which was the minimal example that I could create to make things fail.

I use the standard pkg_resources way to do things:
__import__('pkg_resources').declare_namespace(__name__)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13991>
_______________________________________

From report at bugs.python.org  Sat Feb 11 12:59:42 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 11 Feb 2012 11:59:42 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328961582.94.0.571683586793.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Another random cleanup idea:

ElementTree.py has this code:

try:
    from . import ElementPath
except ImportError:
    ElementPath = _SimpleElementPath()

Since in the stdlib ElementPath.py is always there, this is meaningless, so I'd say this try... except ImportError contraption can be removed, as well as _SimpleElementPath, and just replaced by:

from . import ElementPath

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sat Feb 11 13:55:53 2012
From: report at bugs.python.org (Aaron Staley)
Date: Sat, 11 Feb 2012 12:55:53 +0000
Subject: [issue13992] Segfault in PyTrash_destroy_chain
Message-ID: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za>


New submission from Aaron Staley <usaar33 at gmail.com>:

Am frequently getting segmentation faults with my python program.  I am utilizing heavy use of threading and sockets.

All sorts of ones are showing in syslog:

kernel: [7763578.475590] python[10097]: segfault at 88e5a0 ip 000000000088e5a0 sp 00007f640efd4028 error 15 in python2.7[833000+69000]
Feb 11 11:39:41 ip-10-8-197-187 kernel: [7762910.806782] python[6228]: segfault at 16 ip 0000000000000016 sp 00007fe488fb0028 error 14 in python2.7[400000+233000]
Feb 11 07:36:09 ip-10-8-197-187 kernel: [7748298.747145] python[11376]: segfault at 16 ip 0000000000000016 sp 00007f28767ab028 error 14 in python2.7[400000+233000]

Managed to capture one coredump:

Program terminated with signal 11, Segmentation fault.
#0  0x0000000000000009 in ?? ()
(gdb) where
#0  0x0000000000000009 in ?? ()
#1  0x000000000046670f in _PyTrash_destroy_chain () at ../Objects/object.c:2448
#2  0x00000000004bd0df in PyEval_EvalCodeEx (co=<optimized out>, globals=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kws=<optimized out>, kwcount=0, defs=0x0, defcount=0, closure=
    (<cell at remote 0x293ef68>, <cell at remote 0x21c78d8>, <cell at remote 0x239e168>, <cell at remote 0x219ef30>, <cell at remote 0x2397a28>, <cell at remote 0x2129868>, <cell at remote 0x2397590>, <cell at remote 0x2397be8>, <cell at remote 0x2397fa0>)) at ../Python/ceval.c:3264
#3  0x00000000004b6a5b in fast_function (nk=<optimized out>, na=0, n=<optimized out>, pp_stack=0x7f778ef9c1b0, func=<function at remote 0x20afa28>) at ../Python/ceval.c:4117
#4  call_function (oparg=<optimized out>, pp_stack=0x7f778ef9c1b0) at ../Python/ceval.c:4042
#5  PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at ../Python/ceval.c:2666
#6  0x00000000004bcd2d in PyEval_EvalCodeEx (co=0x168f6b0, globals=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kws=<optimized out>, kwcount=0, defs=0x169f260, defcount=2, closure=
    0x0) at ../Python/ceval.c:3253
#7  0x00000000004b6a5b in fast_function (nk=<optimized out>, na=3, n=<optimized out>, pp_stack=0x7f778ef9c3a0, func=<function at remote 0x16a00c8>) at ../Python/ceval.c:4117
#8  call_function (oparg=<optimized out>, pp_stack=0x7f778ef9c3a0) at ../Python/ceval.c:4042
#9  PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at ../Python/ceval.c:2666
#10 0x00000000004bd325 in PyEval_EvalCodeEx (co=0x168f8b0, globals=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kws=<optimized out>, kwcount=5, defs=0x169a6c8, defcount=5, closure=
    0x0) at ../Python/ceval.c:3253
#11 0x00000000004b6a5b in fast_function (nk=<optimized out>, na=1, n=<optimized out>, pp_stack=0x7f778ef9c590, func=<function at remote 0x16a0140>) at ../Python/ceval.c:4117
#12 call_function (oparg=<optimized out>, pp_stack=0x7f778ef9c590) at ../Python/ceval.c:4042
#13 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at ../Python/ceval.c:2666
#14 0x00000000004bcd2d in PyEval_EvalCodeEx (co=0x168a130, globals=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kws=<optimized out>, kwcount=0, defs=0x1684d28, defcount=1, closure=
    0x0) at ../Python/ceval.c:3253
#15 0x00000000004b6a5b in fast_function (nk=<optimized out>, na=2, n=<optimized out>, pp_stack=0x7f778ef9c780, func=<function at remote 0x1763758>) at ../Python/ceval.c:4117
#16 call_function (oparg=<optimized out>, pp_stack=0x7f778ef9c780) at ../Python/ceval.c:4042
#17 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at ../Python/ceval.c:2666
#18 0x00000000004b6d77 in fast_function (nk=<optimized out>, na=<optimized out>, n=<optimized out>, pp_stack=0x7f778ef9c8c0, func=<function at remote 0x1ebf050>) at ../Python/ceval.c:4107
#19 call_function (oparg=<optimized out>, pp_stack=0x7f778ef9c8c0) at ../Python/ceval.c:4042
#20 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at ../Python/ceval.c:2666
#21 0x00000000004b6d77 in fast_function (nk=<optimized out>, na=<optimized out>, n=<optimized out>, pp_stack=0x7f778ef9ca00, func=<function at remote 0xc5f5f0>) at ../Python/ceval.c:4107
#22 call_function (oparg=<optimized out>, pp_stack=0x7f778ef9ca00) at ../Python/ceval.c:4042
#23 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at ../Python/ceval.c:2666
#24 0x00000000004bcd2d in PyEval_EvalCodeEx (co=0xc0d9b0, globals=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kws=<optimized out>, kwcount=0, defs=0x0, defcount=0, closure=0x0)
    at ../Python/ceval.c:3253
#25 0x0000000000448edf in function_call (func=<function at remote 0xc5f500>, arg=
    (<ProvisionThread(_Thread__ident=140151476573952, _Thread__block=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x33d2fd0>, acquire=<built-in method acquire of thread.lock object at remote 0x33d2fd0>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x33d2fd0>) at remote 0x327a790>, _Thread__name='Thread-193', _Thread__daemonic=True, _Thread__started=<_Event(_Verbose__verbose=False, _Event__flag=True, _Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x33d2b10>, acquire=<built-in method acquire of thread.lock object at remote 0x33d2b10>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x33d2b10>) at remote 0x327ab10>) at remote 0x33a6350>, _Thread__stderr=<file at remote 0x7f77cffb0270>, instance=<Instance(kernel=u'aki-825ea7eb', root_device_type=u'ebs', private_dns_name=u'ip-10-64-50-6.ec2.internal', previous_state=None, spot_instance_request_id=None, hypervis...(truncated), kw=0x0) at ../Objects/funcobject.c:526
#26 0x000000000041ad2a in PyObject_Call (func=<function at remote 0xc5f500>, arg=<optimized out>, kw=<optimized out>) at ../Objects/abstract.c:2529
#27 0x000000000043074e in instancemethod_call (func=<function at remote 0xc5f500>, arg=
    (<ProvisionThread(_Thread__ident=140151476573952, _Thread__block=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x33d2fd0>, acquire=<built-in method acquire of thread.lock object at remote 0x33d2fd0>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x33d2fd0>) at remote 0x327a790>, _Thread__name='Thread-193', _Thread__daemonic=True, _Thread__started=<_Event(_Verbose__verbose=False, _Event__flag=True, _Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x33d2b10>, acquire=<built-in method acquire of thread.lock object at remote 0x33d2b10>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x33d2b10>) at remote 0x327ab10>) at remote 0x33a6350>, _Thread__stderr=<file at remote 0x7f77cffb0270>, instance=<Instance(kernel=u'aki-825ea7eb', root_device_type=u'ebs', private_dns_name=u'ip-10-64-50-6.ec2.internal', previous_state=None, spot_instance_request_id=None, hypervis...(truncated), kw=0x0) at ../Objects/classobject.c:2578
#28 0x000000000041ad2a in PyObject_Call (func=<instancemethod at remote 0x34fa320>, arg=<optimized out>, kw=<optimized out>) at ../Objects/abstract.c:2529
#29 0x00000000004b5d76 in PyEval_CallObjectWithKeywords (func=<instancemethod at remote 0x34fa320>, arg=(), kw=<optimized out>) at ../Python/ceval.c:3890
#30 0x00000000004f06c0 in t_bootstrap (boot_raw=<optimized out>) at ../Modules/threadmodule.c:614
#31 0x00007f77cfbafefc in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#32 0x00007f77cea4789d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#33 0x0000000000000000 in ?? ()

----------
components: Interpreter Core
messages: 153123
nosy: Aaron.Staley
priority: normal
severity: normal
status: open
title: Segfault in PyTrash_destroy_chain
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13992>
_______________________________________

From report at bugs.python.org  Sat Feb 11 14:29:54 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 11 Feb 2012 13:29:54 +0000
Subject: [issue13193] packaging.tests.test_manifest and
	distutils.tests.test_filelist failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1328966994.0.0.883499168994.issue13193@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

All tests pass with the patch applied, on both Windows 7 and Ubuntu 11.10.

I notice that the patch only changes Lib/packaging/manifest.py; does
Lib/distutils/filelist.py perhaps also need to be updated? Changeset
64485e0700ba modified both of these files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Sat Feb 11 14:48:49 2012
From: report at bugs.python.org (Aaron Staley)
Date: Sat, 11 Feb 2012 13:48:49 +0000
Subject: [issue13992] Segfault in PyTrash_destroy_chain
In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za>
Message-ID: <1328968129.06.0.12726403881.issue13992@psf.upfronthosting.co.za>


Aaron Staley <usaar33 at gmail.com> added the comment:

For some more context:

Python 2.7.2
Running on Amazon EC2
Linux 3.0.0-14-virtual x86_64 in ubuntu 11.10
170 threads in this particular core dump (another similar crash has 135)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13992>
_______________________________________

From report at bugs.python.org  Sat Feb 11 14:49:58 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 11 Feb 2012 13:49:58 +0000
Subject: [issue13993] Handling of broken end tags in HTMLParser
Message-ID: <1328968197.87.0.293618482144.issue13993@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

The attached patch fixes the parser to handle broken end tags like:
</label</p>
</div end tmAd-leaderBoard>
</<h4>
</li class="unit">
</li\r\n\t\t\t\t\t\t</ul>
</><

----------
assignee: ezio.melotti
components: Library (Lib)
files: issue13993.diff
keywords: patch
messages: 153126
nosy: eric.araujo, ezio.melotti
priority: normal
severity: normal
stage: commit review
status: open
title: Handling of broken end tags in HTMLParser
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24487/issue13993.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13993>
_______________________________________

From report at bugs.python.org  Sat Feb 11 14:51:38 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 11 Feb 2012 13:51:38 +0000
Subject: [issue5148] gzip.open breaks with  'U' flag
In-Reply-To: <1233709542.39.0.638969424034.issue5148@psf.upfronthosting.co.za>
Message-ID: <1328968298.2.0.135322652612.issue5148@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5148>
_______________________________________

From report at bugs.python.org  Sat Feb 11 14:55:56 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 11 Feb 2012 13:55:56 +0000
Subject: [issue13989] gzip always returns byte strings, no text mode
In-Reply-To: <1328894094.18.0.18729195074.issue13989@psf.upfronthosting.co.za>
Message-ID: <1328968556.95.0.350896733783.issue13989@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

The problem here is that gzip.GzipFile does not support text mode, only
binary mode. Unfortunately, its __init__ method doesn't handle unexpected
mode strings sensibly, so you get a confusing error message.

If you need to open a compressed file in text mode in Python 3.2, use
io.TextIOWrapper:

    with io.TextIOWrapper(gzip.open("ex1.sam.gz", "r")) as f:
        line = f.readline()

In 3.3, it would be nice for gzip.open to do this transparently when mode
is "rt"/"wt"/"at". However, binary mode will still need to be the default
(for modes "r", "w" and "a"), to ensure backward compatibility.

In the meanwhile, I'll add a note to the documentation about this
limitation, and fix GzipFile.__init__ to produce a more sensible error
message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13989>
_______________________________________

From report at bugs.python.org  Sat Feb 11 15:54:10 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 11 Feb 2012 14:54:10 +0000
Subject: [issue13992] Segfault in PyTrash_destroy_chain
In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za>
Message-ID: <1328972050.63.0.469315846571.issue13992@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The crash occurs in an oject's destructor.
Are you using any third-party module (lsof/pmap can help)?

Also, it'd help if you tried reproducing the crash with a debug build (./configure --with-pydebug && make).

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13992>
_______________________________________

From report at bugs.python.org  Sat Feb 11 16:05:53 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 11 Feb 2012 15:05:53 +0000
Subject: [issue13993] Handling of broken end tags in HTMLParser
In-Reply-To: <1328968197.87.0.293618482144.issue13993@psf.upfronthosting.co.za>
Message-ID: <1328972753.46.0.356347890131.issue13993@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file24488/issue13993-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13993>
_______________________________________

From report at bugs.python.org  Sat Feb 11 16:06:16 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 11 Feb 2012 15:06:16 +0000
Subject: [issue13952] mimetypes doesn't recognize .csv
In-Reply-To: <1328939714.48.0.573848287288.issue13952@psf.upfronthosting.co.za>
Message-ID: <1328972599.3364.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> About Antoine?s remark: mimetypes already reads mime.types files, so
> even if our internal registry is not up-to-date the module should know
> about all types present in /etc/mime.types.

The point was about systems which don't have a /etc/mime.types
(Windows).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13952>
_______________________________________

From report at bugs.python.org  Sat Feb 11 17:41:56 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 11 Feb 2012 16:41:56 +0000
Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of
	customize_compiler
Message-ID: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

While final testing Distutils changes for Issue13590, I noticed that a few tests were failing unexpectedly on 2.7.x but passing on 3.2.x.  Upon further investigation, I discovered that in 2.7 there are two copies of "customize_compiler", the function being modified in Issue13590.  It appears that at one point prior to the decision to make no feature changes to Distutils, that customize_compiler was moved from distutils.sysconfig to distutils.ccompiler (fa69e891edf4).  Then, when the decision was made to revert changes and proceed with a new Distutils2/packaging, feature changes were reverted in 2.7 but, for unexplained reasons, only part of the changes were reverted (ad22bc22dddc).  Perhaps a clue is in the commit message:
  "reverting partially distutils to its 2.6.x state so 2.7a4 looks more
   like the 2.7b1 in this. the whole revert will occur after a4 is tagged "

>From the change logs, I see no evidence that the whole revert ever happened.  This has left 2.7 Distutils with two virtually identical versions of customize_compiler with some commands and tests calling one and others calling the other.  (In 3.2.x, the only version is in distutils.sysconfig.)  They *were* virtually identically until Issue13590 changed one and missed the other.

Patch to follow which completes the revert for customize_compiler and brings 2.7.x and 3.2.2 back into sync with respect to this.  This patch is needed immediately for the upcoming 2.7.3 release.  I strongly urge a more complete audit for other discrepancies between the 2.7.x and 3.2.x versions of Distutils; this isn't the first time we've been burned recently by the effects of the reverts in 2.7.

----------
assignee: tarek
components: Distutils
messages: 153130
nosy: benjamin.peterson, eric.araujo, ned.deily, tarek
priority: release blocker
severity: normal
stage: needs patch
status: open
title: incomplete revert in 2.7 Distutils left two copies of customize_compiler
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13994>
_______________________________________

From report at bugs.python.org  Sat Feb 11 17:45:55 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 11 Feb 2012 16:45:55 +0000
Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of
	customize_compiler
In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za>
Message-ID: <1328978755.55.0.878875446304.issue13994@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
keywords: +patch
stage: needs patch -> commit review
Added file: http://bugs.python.org/file24489/issue13994_27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13994>
_______________________________________

From report at bugs.python.org  Sat Feb 11 19:28:33 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 11 Feb 2012 18:28:33 +0000
Subject: [issue5411] add xz compression support to shutil
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1328984913.38.0.797072619928.issue5411@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> This not-so-bad patch adds lzma compression support to the shutil functions, under the 'xztar' name.  Please review.

Functionally, the patch looks good to me. There are some docstrings that
should probably be updated, though:

- _make_tarball (the 'compress' argument)
- make_archive
- _unpack_tarfile
- unpack_archive


> Ideally, tarfile should have an attribute to expose what compression formats are available, then shutil would reuse that, and packaging would just call shutil.

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5411>
_______________________________________

From report at bugs.python.org  Sat Feb 11 20:18:31 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 11 Feb 2012 19:18:31 +0000
Subject: [issue13878] test_sched failures on Windows buildbot
In-Reply-To: <1327597038.78.0.0899603043053.issue13878@psf.upfronthosting.co.za>
Message-ID: <1328987911.63.0.319219760247.issue13878@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Patch looks good, but you might want to make this change to test_priority:

             l = []
             fun = lambda x: l.append(x)
             scheduler = sched.scheduler(time.time, time.sleep)
    +        now = time.time()
             for priority in [1, 2, 3, 4, 5]:
    -            z = scheduler.enterabs(0.01, priority, fun, (priority,))
    +            z = scheduler.enterabs(now + 0.01, priority, fun, (priority,))
             scheduler.run()
             self.assertEqual(l, [1, 2, 3, 4, 5])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13878>
_______________________________________

From report at bugs.python.org  Sat Feb 11 20:29:26 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 11 Feb 2012 19:29:26 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1328988566.45.0.390751096385.issue13988@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sat Feb 11 20:42:38 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 11 Feb 2012 19:42:38 +0000
Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of
	customize_compiler
In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za>
Message-ID: <E1RwIqD-0005zp-0k@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6240ff5dfebe by Ned Deily in branch '2.7':
Issue #13994: Earler partial revert of Distutils enhancements in 2.7
http://hg.python.org/cpython/rev/6240ff5dfebe

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13994>
_______________________________________

From report at bugs.python.org  Sat Feb 11 20:44:41 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 11 Feb 2012 19:44:41 +0000
Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of
	customize_compiler
In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za>
Message-ID: <1328989481.03.0.533002507362.issue13994@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

With the release manager's concurrence, I've applied this patch prior to the freeze for 2.7.3.

----------
assignee: tarek -> ned.deily
priority: release blocker -> normal
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13994>
_______________________________________

From report at bugs.python.org  Sat Feb 11 20:58:25 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 11 Feb 2012 19:58:25 +0000
Subject: [issue13990] Benchmarks: 2to3 failures on the py3 side
In-Reply-To: <1328895154.39.0.105937484663.issue13990@psf.upfronthosting.co.za>
Message-ID: <1328990305.86.0.875656660619.issue13990@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine (since you last looked at the benchmark suite for Python 3), do 
> you know anything about this?

I don't know. It works here. It may depend on the version of 2to3 used for the conversion, try passing PYTHON=some_newer_python when running make_perf.sh.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13990>
_______________________________________

From report at bugs.python.org  Sat Feb 11 21:16:17 2012
From: report at bugs.python.org (Matthew Woodcraft)
Date: Sat, 11 Feb 2012 20:16:17 +0000
Subject: [issue13995] sqlite3 Cursor.rowcount documentation for old sqlite bug
Message-ID: <1328991377.3.0.315009784222.issue13995@psf.upfronthosting.co.za>


New submission from Matthew Woodcraft <matthew at woodcraft.me.uk>:

The documentation for the sqlite3 module contains the following statement, under 'Cursor.rowcount':

  For DELETE statements, SQLite reports rowcount as 0 if you make a DELETE FROM table without any condition.

This doesn't happen for me (with sqlite 3.7.9): rowcount returns the correct value in this case.

According to http://www.sqlite.org/lang_delete.html#truncateopt , this was a bug that was fixed in SQLite 3.6.5 (in 2008).

So I think the Python documentation should either omit this paragraph, or else explain that it only applies to older versions of SQLite.


Also, the first example under 'Using shortcut methods' has code to work around this bug, which should perhaps be removed.

----------
assignee: docs at python
components: Documentation
messages: 153136
nosy: docs at python, mattheww
priority: normal
severity: normal
status: open
title: sqlite3 Cursor.rowcount documentation for old sqlite bug

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13995>
_______________________________________

From report at bugs.python.org  Sat Feb 11 21:59:57 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 11 Feb 2012 20:59:57 +0000
Subject: [issue2636] Adding a new regex module (compatible with re)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1328993997.41.0.962478545991.issue2636@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Feb 11 22:04:27 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Feb 2012 21:04:27 +0000
Subject: [issue13952] mimetypes doesn't recognize .csv
In-Reply-To: <1328550236.31.0.476108753678.issue13952@psf.upfronthosting.co.za>
Message-ID: <1328994267.88.0.731560134458.issue13952@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

On Windows we do (now) read from the registry as well.  My guess is there are a lot more Windows systems out there with outdated registries then there are unix systems with outdated /etc/mime files, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13952>
_______________________________________

From report at bugs.python.org  Sat Feb 11 22:11:09 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 11 Feb 2012 21:11:09 +0000
Subject: [issue13996] "What's New in Python" should have initial release date
	on heading
Message-ID: <1328994669.43.0.0878472757687.issue13996@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

As an example, the date near the top of this document http://docs.python.org/py3k/whatsnew/3.0.html matches that of today, which can be misleading (it appears as if the thing was released today).

Also, by initial release, I mean the first "final", not the point release. Maybe any other date mentioned would perhaps be the date the docs were updated, *not* the date they were rebuilt.

----------
assignee: docs at python
components: Documentation
messages: 153138
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: "What's New in Python" should have initial release date on heading
type: enhancement
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/issue13996>
_______________________________________

From report at bugs.python.org  Sat Feb 11 22:25:41 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 11 Feb 2012 21:25:41 +0000
Subject: [issue13996] "What's New in Python" should have initial release date
	on heading
In-Reply-To: <1328994669.43.0.0878472757687.issue13996@psf.upfronthosting.co.za>
Message-ID: <1328995541.31.0.52289934449.issue13996@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +eric.araujo, ezio.melotti, georg.brandl, terry.reedy
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13996>
_______________________________________

From report at bugs.python.org  Sat Feb 11 23:06:32 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 11 Feb 2012 22:06:32 +0000
Subject: [issue13989] gzip always returns byte strings, no text mode
In-Reply-To: <1328894094.18.0.18729195074.issue13989@psf.upfronthosting.co.za>
Message-ID: <E1RwL5S-0005Q8-Ph@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4b32309631da by Nadeem Vawda in branch '3.2':
Issue #13989: Document that GzipFile does not support text mode.
http://hg.python.org/cpython/rev/4b32309631da

New changeset 8dbe8faea0e7 by Nadeem Vawda in branch 'default':
Merge: #13989: Document that GzipFile does not support text mode.
http://hg.python.org/cpython/rev/8dbe8faea0e7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13989>
_______________________________________

From report at bugs.python.org  Sun Feb 12 00:09:29 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Sat, 11 Feb 2012 23:09:29 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <CA+OGgf5WC9s5bvpFBJwZMZNiK1bBPEf3xdsNMuf3daoguPxYfA@mail.gmail.com>
Message-ID: <1329001725.2149.10.camel@surprise>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

I'm not quite sure how that would interact with the -R command-line
option for enabling randomization.

The changes to the docs in the latest patch clarifies the meaning of
what I've implemented (I hope).

My view is that we should simply enable hash randomization by default in
3.3

At that point, PYTHONHASHRANDOMIZATION and the -R option become
meaningless (and could be either removed, or silently ignored), and you
have to set PYTHONHASHSEED=0 to get back the old behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Sun Feb 12 00:06:24 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Sat, 11 Feb 2012 23:06:24 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1328914920.6.0.417185276952.issue13703@psf.upfronthosting.co.za>
Message-ID: <1329001532.2149.7.camel@surprise>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

On Fri, 2012-02-10 at 23:02 +0000, STINNER Victor wrote:
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> Review of add-randomization-(...).patch:
>  - there is a missing ")" in the doc, near "the types covered by the :option:`-R` option (or its equivalent, :envvar:`PYTHONHASHRANDOMIZATION`."
>  - get_hash() in test_hash.py fails completly on Windows: Windows requires some environment variables. Just use env=os.environ.copy() instead of env={}.
>  - PYTHONHASHSEED doc is not clear: it should be mentionned that the variable is ignored if PYTHONHASHRANDOMIZATION is not set
>  - (Python 2.6) test_hash fails because of "[xxx refs]" in stderr if Python is compiled in debug mode. Add strip_python_stderr() to test_support.py and use it in get_hash().

I'm attaching revised versions of the "add-randomization" patches
incorporating review feedback:
  add-randomization-to-2.6-dmalcolm-2012-02-11-001.patch
  add-randomization-to-3.1-dmalcolm-2012-02-11-001.patch

The other pair of patches are unchanged from before:
  fix-broken-tests-on-2.6-dmalcolm-2012-02-06-001.patch
  fix-broken-tests-on-3.1-dmalcolm-2012-02-06-001.patch

Changes relative to *-2012-02-06-001.patch:
  * changed the wording of the docs relating to PYTHONHASHSEED in
Doc/using/cmdline.rst to:
    * clarify the interaction with PYTHONHASHRANDOMIZATION and -R
    * mentioning another possible use case: "to allow a cluster of
python processes to share hash values." (as per
http://bugs.python.org/issue13703#msg152344 )
    * rewording the awkward "overrides the other setting"
  * I've added a description of PYTHONHASHSEED back to the man page and
to the --help text
  * grammar fixes for "Fail to" in 2.6 version of the patch (were
already fixed in 3.1)
  * restored __VMS randomization, by porting vms_urandom from
Modules/posixmodule.c to Python/random.c (though I have no way of
testing this)
  * changed env = {} to env = os.environ.copy() in get_hash() as noted
by haypo
  * fixed test_hash --with-pydebug as noted by haypo (and test_os),
adding strip_python_stderr from 2.7

I haven't enabled randomization in the Makefile.pre.in

----------
Added file: http://bugs.python.org/file24490/add-randomization-to-2.6-dmalcolm-2012-02-11-001.patch
Added file: http://bugs.python.org/file24491/add-randomization-to-3.1-dmalcolm-2012-02-11-001.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________
-------------- next part --------------
diff -r 9a4131ada792 Doc/library/sys.rst
--- a/Doc/library/sys.rst	Fri Jan 27 09:42:45 2012 +0100
+++ b/Doc/library/sys.rst	Sat Feb 11 17:59:19 2012 -0500
@@ -289,6 +289,8 @@
    +------------------------------+------------------------------------------+
    | :const:`bytes_warning`       | -b                                       |
    +------------------------------+------------------------------------------+
+   | :const:`hash_randomization`  | -R                                       |
+   +------------------------------+------------------------------------------+
 
    .. versionadded:: 2.6
 
diff -r 9a4131ada792 Doc/reference/datamodel.rst
--- a/Doc/reference/datamodel.rst	Fri Jan 27 09:42:45 2012 +0100
+++ b/Doc/reference/datamodel.rst	Sat Feb 11 17:59:19 2012 -0500
@@ -1273,6 +1273,8 @@
       modules are still available at the time when the :meth:`__del__` method is
       called.
 
+   See also the :option:`-R` command-line option.
+
 
 .. method:: object.__repr__(self)
 
diff -r 9a4131ada792 Doc/using/cmdline.rst
--- a/Doc/using/cmdline.rst	Fri Jan 27 09:42:45 2012 +0100
+++ b/Doc/using/cmdline.rst	Sat Feb 11 17:59:19 2012 -0500
@@ -21,7 +21,7 @@
 
 When invoking Python, you may specify any of these options::
 
-    python [-BdEiOQsStuUvVWxX3?] [-c command | -m module-name | script | - ] [args]
+    python [-BdEiOQsRStuUvVWxX3?] [-c command | -m module-name | script | - ] [args]
 
 The most common use case is, of course, a simple invocation of a script::
 
@@ -239,6 +239,30 @@
       :pep:`238` -- Changing the division operator
 
 
+.. cmdoption:: -R
+
+   Turn on hash randomization, so that the :meth:`__hash__` values of str,
+   bytes and datetime objects are "salted" with an unpredictable random value.
+   Although they remain constant within an individual Python process, they
+   are not predictable between repeated invocations of Python.
+
+   This is intended to provide protection against a denial-of-service
+   caused by carefully-chosen inputs that exploit the worst case performance
+   of a dict lookup, O(n^2) complexity.  See:
+
+       http://www.ocert.org/advisories/ocert-2011-003.html
+
+   for details.
+
+   Changing hash values affects the order in which keys are retrieved from
+   a dict.  Although Python has never made guarantees about this ordering
+   (and it typically varies between 32-bit and 64-bit builds), enough
+   real-world code implicitly relies on this non-guaranteed behavior that
+   the randomization is disabled by default.
+
+   See also :envvar:`PYTHONHASHRANDOMIZATION`.
+
+
 .. cmdoption:: -s
 
    Don't add user site directory to sys.path
@@ -501,6 +525,30 @@
 
    .. versionadded:: 2.6
 
+.. envvar:: PYTHONHASHRANDOMIZATION
+
+   If this is set to a non-empty string it is equivalent to specifying the
+   :option:`-R` option.
+
+
+.. envvar:: PYTHONHASHSEED
+
+   This environment variable only has an effect when hash randomization has
+   been enabled (via the :option:`-R` option, or its equivalent environment
+   variable, :envvar:`PYTHONHASHRANDOMIZATION`).
+
+   If :envvar:`PYTHONHASHSEED` is set, it is used as a fixed seed for
+   generating the hash() of the types covered by the hash randomization.
+
+   Its purpose is to allow repeatable hashing, such as for selftests for the
+   interpreter itself, or to allow a cluster of python processes to share hash
+   values.
+
+   It should be a decimal number in the range [0; 4294967295].  Specifying
+   the value 0 will lead to the same hash values as when hash randomization
+   is disabled.
+
+
 .. envvar:: PYTHONIOENCODING
 
    Overrides the encoding used for stdin/stdout/stderr, in the syntax
diff -r 9a4131ada792 Include/object.h
--- a/Include/object.h	Fri Jan 27 09:42:45 2012 +0100
+++ b/Include/object.h	Sat Feb 11 17:59:19 2012 -0500
@@ -506,6 +506,12 @@
 PyAPI_FUNC(long) _Py_HashDouble(double);
 PyAPI_FUNC(long) _Py_HashPointer(void*);
 
+typedef struct {
+    long prefix;
+    long suffix;
+} _Py_HashSecret_t;
+PyAPI_DATA(_Py_HashSecret_t) _Py_HashSecret;
+
 /* Helper for passing objects to printf and the like */
 #define PyObject_REPR(obj) PyString_AS_STRING(PyObject_Repr(obj))
 
diff -r 9a4131ada792 Include/pydebug.h
--- a/Include/pydebug.h	Fri Jan 27 09:42:45 2012 +0100
+++ b/Include/pydebug.h	Sat Feb 11 17:59:19 2012 -0500
@@ -26,6 +26,7 @@
 PyAPI_DATA(int) _Py_QnewFlag;
 /* Warn about 3.x issues */
 PyAPI_DATA(int) Py_Py3kWarningFlag;
+PyAPI_DATA(int) Py_HashRandomizationFlag;
 
 /* this is a wrapper around getenv() that pays attention to
    Py_IgnoreEnvironmentFlag.  It should be used for getting variables like
diff -r 9a4131ada792 Include/pythonrun.h
--- a/Include/pythonrun.h	Fri Jan 27 09:42:45 2012 +0100
+++ b/Include/pythonrun.h	Sat Feb 11 17:59:19 2012 -0500
@@ -168,6 +168,8 @@
 PyAPI_FUNC(PyOS_sighandler_t) PyOS_getsig(int);
 PyAPI_FUNC(PyOS_sighandler_t) PyOS_setsig(int, PyOS_sighandler_t);
 
+/* Random */
+PyAPI_FUNC(int) _PyOS_URandom (void *buffer, Py_ssize_t size);
 
 #ifdef __cplusplus
 }
diff -r 9a4131ada792 Lib/os.py
--- a/Lib/os.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/os.py	Sat Feb 11 17:59:19 2012 -0500
@@ -742,22 +742,3 @@
                      _make_statvfs_result)
 except NameError: # statvfs_result may not exist
     pass
-
-if not _exists("urandom"):
-    def urandom(n):
-        """urandom(n) -> str
-
-        Return a string of n random bytes suitable for cryptographic use.
-
-        """
-        try:
-            _urandomfd = open("/dev/urandom", O_RDONLY)
-        except (OSError, IOError):
-            raise NotImplementedError("/dev/urandom (or equivalent) not found")
-        try:
-            bs = b""
-            while n - len(bs) >= 1:
-                bs += read(_urandomfd, n - len(bs))
-        finally:
-            close(_urandomfd)
-        return bs
diff -r 9a4131ada792 Lib/test/test_cmd_line.py
--- a/Lib/test/test_cmd_line.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_cmd_line.py	Sat Feb 11 17:59:19 2012 -0500
@@ -103,6 +103,20 @@
             self.exit_code('-c', 'pass'),
             0)
 
+    def test_hash_randomization(self):
+        # Verify that -R enables hash randomization:
+        self.verify_valid_flag('-R')
+        hashes = []
+        for i in range(2):
+            code = 'print(hash("spam"))'
+            data = self.start_python('-R', '-c', code)
+            hashes.append(data)
+        self.assertNotEqual(hashes[0], hashes[1])
+
+        # Verify that sys.flags contains hash_randomization
+        code = 'import sys; print(sys.flags)'
+        data = self.start_python('-R', '-c', code)
+        self.assertTrue('hash_randomization=1' in data)
 
 def test_main():
     test.test_support.run_unittest(CmdLineTest)
diff -r 9a4131ada792 Lib/test/test_hash.py
--- a/Lib/test/test_hash.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_hash.py	Sat Feb 11 17:59:19 2012 -0500
@@ -3,10 +3,15 @@
 #
 # Also test that hash implementations are inherited as expected
 
+import os
+import struct
+import subprocess
+import sys
 import unittest
 from test import test_support
 from collections import Hashable
 
+IS_64BIT = (struct.calcsize('l') == 8)
 
 class HashEqualityTestCase(unittest.TestCase):
 
@@ -133,10 +138,85 @@
         for obj in self.hashes_to_check:
             self.assertEqual(hash(obj), _default_hash(obj))
 
+class HashRandomizationTests(unittest.TestCase):
+
+    # Each subclass should define a field "repr_", containing the repr() of
+    # an object to be tested
+
+    def get_hash_command(self, repr_):
+        return 'print(hash(%s))' % repr_
+
+    def get_hash(self, repr_, randomization=None, seed=None):
+        env = os.environ.copy()
+        if randomization is not None:
+            env['PYTHONHASHRANDOMIZATION'] = str(randomization)
+        if seed is not None:
+            env['PYTHONHASHSEED'] = str(seed)
+        cmd_line = [sys.executable,
+                    '-c', self.get_hash_command(repr_)]
+        p = subprocess.Popen(cmd_line, stdin=subprocess.PIPE,
+                             stdout=subprocess.PIPE, stderr=subprocess.STDOUT,
+                             env=env)
+        out, err = p.communicate()
+        out = test_support.strip_python_stderr(out)
+        return int(out.strip())
+
+    def test_randomized_hash(self):
+        # two runs should return different hashes
+        run1 = self.get_hash(self.repr_, randomization=1)
+        run2 = self.get_hash(self.repr_, randomization=1)
+        self.assertNotEqual(run1, run2)
+
+class StringlikeHashRandomizationTests(HashRandomizationTests):
+    def test_null_hash(self):
+        # PYTHONHASHSEED=0 disables the randomized hash
+        if IS_64BIT:
+            known_hash_of_obj = 1453079729188098211
+        else:
+            known_hash_of_obj = -1600925533
+
+        # Randomization is disabled by default:
+        self.assertEqual(self.get_hash(self.repr_), known_hash_of_obj)
+
+        # If enabled, it can still be disabled by setting the seed to 0:
+        self.assertEqual(self.get_hash(self.repr_, randomization=1, seed=0),
+                         known_hash_of_obj)
+
+    def test_fixed_hash(self):
+        # test a fixed seed for the randomized hash
+        # Note that all types share the same values:
+        if IS_64BIT:
+            h = -4410911502303878509
+        else:
+            h = -206076799
+        self.assertEqual(self.get_hash(self.repr_, randomization=1, seed=42),
+                         h)
+
+class StrHashRandomizationTests(StringlikeHashRandomizationTests):
+    repr_ = repr('abc')
+
+    def test_empty_string(self):
+        self.assertEqual(hash(""), 0)
+
+class UnicodeHashRandomizationTests(StringlikeHashRandomizationTests):
+    repr_ = repr(u'abc')
+
+    def test_empty_string(self):
+        self.assertEqual(hash(u""), 0)
+
+class BufferHashRandomizationTests(StringlikeHashRandomizationTests):
+    repr_ = 'buffer("abc")'
+
+    def test_empty_string(self):
+        self.assertEqual(hash(buffer("")), 0)
+
 def test_main():
     test_support.run_unittest(HashEqualityTestCase,
                               HashInheritanceTestCase,
-                              HashBuiltinsTestCase)
+                              HashBuiltinsTestCase,
+                              StrHashRandomizationTests,
+                              UnicodeHashRandomizationTests,
+                              BufferHashRandomizationTests)
 
 
 if __name__ == "__main__":
diff -r 9a4131ada792 Lib/test/test_os.py
--- a/Lib/test/test_os.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_os.py	Sat Feb 11 17:59:19 2012 -0500
@@ -5,6 +5,7 @@
 import os
 import unittest
 import warnings
+import subprocess
 import sys
 from test import test_support
 
@@ -499,18 +500,46 @@
 
 class URandomTests (unittest.TestCase):
     def test_urandom(self):
-        try:
-            with test_support.check_warnings():
-                self.assertEqual(len(os.urandom(1)), 1)
-                self.assertEqual(len(os.urandom(10)), 10)
-                self.assertEqual(len(os.urandom(100)), 100)
-                self.assertEqual(len(os.urandom(1000)), 1000)
-                # see http://bugs.python.org/issue3708
-                self.assertEqual(len(os.urandom(0.9)), 0)
-                self.assertEqual(len(os.urandom(1.1)), 1)
-                self.assertEqual(len(os.urandom(2.0)), 2)
-        except NotImplementedError:
-            pass
+        with test_support.check_warnings():
+            self.assertEqual(len(os.urandom(1)), 1)
+            self.assertEqual(len(os.urandom(10)), 10)
+            self.assertEqual(len(os.urandom(100)), 100)
+            self.assertEqual(len(os.urandom(1000)), 1000)
+            # see http://bugs.python.org/issue3708
+            self.assertEqual(len(os.urandom(0.9)), 0)
+            self.assertEqual(len(os.urandom(1.1)), 1)
+            self.assertEqual(len(os.urandom(2.0)), 2)
+
+    def test_urandom_length(self):
+        self.assertEqual(len(os.urandom(0)), 0)
+        self.assertEqual(len(os.urandom(1)), 1)
+        self.assertEqual(len(os.urandom(10)), 10)
+        self.assertEqual(len(os.urandom(100)), 100)
+        self.assertEqual(len(os.urandom(1000)), 1000)
+
+    def test_urandom_value(self):
+        data1 = os.urandom(16)
+        data2 = os.urandom(16)
+        self.assertNotEqual(data1, data2)
+
+    def get_urandom_subprocess(self, count):
+        code = '\n'.join((
+            'import os, sys',
+            'data = os.urandom(%s)' % count,
+            'sys.stdout.write(data)'))
+        cmd_line = [sys.executable,
+                    '-c', code]
+        p = subprocess.Popen(cmd_line, stdin=subprocess.PIPE,
+                             stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
+        out, err = p.communicate()
+        out = test_support.strip_python_stderr(out)
+        self.assertEqual(len(out), count)
+        return out
+
+    def test_urandom_subprocess(self):
+        data1 = self.get_urandom_subprocess(16)
+        data2 = self.get_urandom_subprocess(16)
+        self.assertNotEqual(data1, data2)
 
 class Win32ErrorTests(unittest.TestCase):
     def test_rename(self):
diff -r 9a4131ada792 Lib/test/test_set.py
--- a/Lib/test/test_set.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_set.py	Sat Feb 11 17:59:19 2012 -0500
@@ -688,6 +688,17 @@
         if self.repr is not None:
             self.assertEqual(repr(self.set), self.repr)
 
+    def check_repr_against_values(self):
+        text = repr(self.set)
+        self.assertTrue(text.startswith('{'))
+        self.assertTrue(text.endswith('}'))
+
+        result = text[1:-1].split(', ')
+        result.sort()
+        sorted_repr_values = [repr(value) for value in self.values]
+        sorted_repr_values.sort()
+        self.assertEqual(result, sorted_repr_values)
+
     def test_print(self):
         fo = open(test_support.TESTFN, "wb")
         try:
diff -r 9a4131ada792 Lib/test/test_support.py
--- a/Lib/test/test_support.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_support.py	Sat Feb 11 17:59:19 2012 -0500
@@ -893,3 +893,13 @@
                     break
             except:
                 break
+
+def strip_python_stderr(stderr):
+    """Strip the stderr of a Python process from potential debug output
+    emitted by the interpreter.
+
+    This will typically be run on the result of the communicate() method
+    of a subprocess.Popen object.
+    """
+    stderr = re.sub(br"\[\d+ refs\]\r?\n?$", b"", stderr).strip()
+    return stderr
diff -r 9a4131ada792 Lib/test/test_sys.py
--- a/Lib/test/test_sys.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_sys.py	Sat Feb 11 17:59:19 2012 -0500
@@ -384,7 +384,7 @@
         attrs = ("debug", "py3k_warning", "division_warning", "division_new",
                  "inspect", "interactive", "optimize", "dont_write_bytecode",
                  "no_site", "ignore_environment", "tabcheck", "verbose",
-                 "unicode", "bytes_warning")
+                 "unicode", "bytes_warning", "hash_randomization")
         for attr in attrs:
             self.assert_(hasattr(sys.flags, attr), attr)
             self.assertEqual(type(getattr(sys.flags, attr)), int, attr)
diff -r 9a4131ada792 Makefile.pre.in
--- a/Makefile.pre.in	Fri Jan 27 09:42:45 2012 +0100
+++ b/Makefile.pre.in	Sat Feb 11 17:59:19 2012 -0500
@@ -280,6 +280,7 @@
 		Python/pymath.o \
 		Python/pystate.o \
 		Python/pythonrun.o \
+		Python/random.o \
 		Python/structmember.o \
 		Python/symtable.o \
 		Python/sysmodule.o \
diff -r 9a4131ada792 Misc/NEWS
--- a/Misc/NEWS	Fri Jan 27 09:42:45 2012 +0100
+++ b/Misc/NEWS	Sat Feb 11 17:59:19 2012 -0500
@@ -10,6 +10,12 @@
 Core and Builtins
 -----------------
 
+- Issue #13703: oCERT-2011-003: add -R command-line option and
+  PYTHONHASHRANDOMIZATION (and PYTHONHASHSEED) environment variables, to
+  provide an opt-in way to protect against denial of service attacks due to
+  hash collisions within the dict and set types.  Patch by David Malcolm,
+  based on work by Victor Stinner.
+
 Library
 -------
 
diff -r 9a4131ada792 Misc/python.man
--- a/Misc/python.man	Fri Jan 27 09:42:45 2012 +0100
+++ b/Misc/python.man	Sat Feb 11 17:59:19 2012 -0500
@@ -34,6 +34,9 @@
 .B \-O0
 ]
 [
+.B \-R
+]
+[
 .B -Q
 .I argument
 ]
@@ -151,6 +154,18 @@
 .B \-O0
 Discard docstrings in addition to the \fB-O\fP optimizations.
 .TP
+.B \-R
+Turn on "hash randomization", so that the hash() values of str, bytes and
+datetime objects are "salted" with an unpredictable pseudo-random value.
+Although they remain constant within an individual Python process, they are
+not predictable between repeated invocations of Python.
+.IP
+This is intended to provide protection against a denial of service
+caused by carefully-chosen inputs that exploit the worst case performance
+of a dict lookup, O(n^2) complexity.  See
+http://www.ocert.org/advisories/ocert-2011-003.html
+for details.
+.TP
 .BI "\-Q " argument
 Division control; see PEP 238.  The argument must be one of "old" (the
 default, int/int and long/long return an int or long), "new" (new
@@ -411,6 +426,24 @@
 If this is set to a non-empty string it is equivalent to specifying
 the \fB\-v\fP option. If set to an integer, it is equivalent to
 specifying \fB\-v\fP multiple times. 
+.IP PYTHONHASHRANDOMIZATION
+If this is set to a non-empty string it is equivalent to specifying the
+\fB\-R\fP option.
+.IP PYTHONHASHSEED
+This environment variable only has an effect when hash randomization has
+been enabled (via the \fB\-R\fP option, or its equivalent environment
+variable, \fB\PYTHONHASHRANDOMIZATION\fP).
+
+If PYTHONHASHSEED is set, it is used as a fixed seed for
+generating the hash() of the types covered by the hash randomization.
+
+Its purpose is to allow repeatable hashing, such as for selftests for the
+interpreter itself, or to allow a cluster of python processes to share hash
+values.
+
+It should be a decimal number in the range [0; 4294967295].  Specifying
+the value 0 will lead to the same hash values as when hash randomization
+is disabled.
 .SH AUTHOR
 The Python Software Foundation: http://www.python.org/psf
 .SH INTERNET RESOURCES
diff -r 9a4131ada792 Modules/main.c
--- a/Modules/main.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Modules/main.c	Sat Feb 11 17:59:19 2012 -0500
@@ -40,7 +40,7 @@
 static int  orig_argc;
 
 /* command line options */
-#define BASE_OPTS "3bBc:dEhiJm:OQ:sStuUvVW:xX?"
+#define BASE_OPTS "3bBc:dEhiJm:OQ:RsStuUvVW:xX?"
 
 #ifndef RISCOS
 #define PROGRAM_OPTS BASE_OPTS
@@ -72,6 +72,9 @@
 -O     : optimize generated bytecode slightly; also PYTHONOPTIMIZE=x\n\
 -OO    : remove doc-strings in addition to the -O optimizations\n\
 -Q arg : division options: -Qold (default), -Qwarn, -Qwarnall, -Qnew\n\
+-R     : use a pseudo-random salt to make hash() values of various types be\n\
+         unpredictable between separate invocations of the interpreter, as\n\
+         a defence against denial-of-service attacks\n\
 -s     : don't add user site directory to sys.path; also PYTHONNOUSERSITE\n\
 -S     : don't imply 'import site' on initialization\n\
 -t     : issue warnings about inconsistent tab usage (-tt: issue errors)\n\
@@ -101,6 +104,25 @@
 PYTHONCASEOK : ignore case in 'import' statements (Windows).\n\
 PYTHONIOENCODING: Encoding[:errors] used for stdin/stdout/stderr.\n\
 ";
+static char *usage_6 = "\
+PYTHONHASHRANDOMIZATION : make hash() values of various types be unpredictable\n\
+                          between separate invocations of the interpreter, as\n\
+                          a defence against denial-of-service attacks\n\
+PYTHONHASHSEED: this environment variable only has an effect when hash\n\
+                randomization has been enabled (via the -R option, or its\n\
+                equivalent environment variable, PYTHONHASHRANDOMIZATION)\n\
+\n\
+                If PYTHONHASHSEED is set, it is used as a fixed seed for\n\
+                generating the hash() of the types covered by the hash randomization\n\
+\n\
+                Its purpose is to allow repeatable hashing, such as for\n\
+                selftests for the interpreter itself, or to allow a cluster of\n\
+                python processes to share hash values.\n\
+\n\
+                It should be a decimal number in the range [0; 4294967295].\n\
+                Specifying the value 0 will lead to the same hash values as\n\
+                when hash randomization is disabled.\n\
+";
 
 
 static int
@@ -117,6 +139,7 @@
         fputs(usage_3, f);
         fprintf(f, usage_4, DELIM);
         fprintf(f, usage_5, DELIM, PYTHONHOMEHELP);
+        fputs(usage_6, f);
     }
 #if defined(__VMS)
     if (exitcode == 0) {
@@ -388,6 +411,10 @@
             PySys_AddWarnOption(_PyOS_optarg);
             break;
 
+        case 'R':
+            Py_HashRandomizationFlag++;
+            break;
+
         /* This space reserved for other options */
 
         default:
diff -r 9a4131ada792 Modules/posixmodule.c
--- a/Modules/posixmodule.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Modules/posixmodule.c	Sat Feb 11 17:59:19 2012 -0500
@@ -8371,117 +8371,35 @@
 }
 #endif
 
-#ifdef MS_WINDOWS
-
-PyDoc_STRVAR(win32_urandom__doc__,
+PyDoc_STRVAR(posix_urandom__doc__,
 "urandom(n) -> str\n\n\
-Return a string of n random bytes suitable for cryptographic use.");
-
-typedef BOOL (WINAPI *CRYPTACQUIRECONTEXTA)(HCRYPTPROV *phProv,\
-              LPCSTR pszContainer, LPCSTR pszProvider, DWORD dwProvType,\
-              DWORD dwFlags );
-typedef BOOL (WINAPI *CRYPTGENRANDOM)(HCRYPTPROV hProv, DWORD dwLen,\
-              BYTE *pbBuffer );
-
-static CRYPTGENRANDOM pCryptGenRandom = NULL;
-/* This handle is never explicitly released. Instead, the operating
-   system will release it when the process terminates. */
-static HCRYPTPROV hCryptProv = 0;
-
-static PyObject*
-win32_urandom(PyObject *self, PyObject *args)
-{
-    int howMany;
-    PyObject* result;
-
-    /* Read arguments */
-    if (! PyArg_ParseTuple(args, "i:urandom", &howMany))
-        return NULL;
-    if (howMany < 0)
-        return PyErr_Format(PyExc_ValueError,
-                            "negative argument not allowed");
-
-    if (hCryptProv == 0) {
-        HINSTANCE hAdvAPI32 = NULL;
-        CRYPTACQUIRECONTEXTA pCryptAcquireContext = NULL;
-
-        /* Obtain handle to the DLL containing CryptoAPI
-           This should not fail         */
-        hAdvAPI32 = GetModuleHandle("advapi32.dll");
-        if(hAdvAPI32 == NULL)
-            return win32_error("GetModuleHandle", NULL);
-
-        /* Obtain pointers to the CryptoAPI functions
-           This will fail on some early versions of Win95 */
-        pCryptAcquireContext = (CRYPTACQUIRECONTEXTA)GetProcAddress(
-                                        hAdvAPI32,
-                                        "CryptAcquireContextA");
-        if (pCryptAcquireContext == NULL)
-            return PyErr_Format(PyExc_NotImplementedError,
-                                "CryptAcquireContextA not found");
-
-        pCryptGenRandom = (CRYPTGENRANDOM)GetProcAddress(
-                                        hAdvAPI32, "CryptGenRandom");
-        if (pCryptGenRandom == NULL)
-            return PyErr_Format(PyExc_NotImplementedError,
-                                "CryptGenRandom not found");
-
-        /* Acquire context */
-        if (! pCryptAcquireContext(&hCryptProv, NULL, NULL,
-                                   PROV_RSA_FULL, CRYPT_VERIFYCONTEXT))
-            return win32_error("CryptAcquireContext", NULL);
-    }
-
-    /* Allocate bytes */
-    result = PyString_FromStringAndSize(NULL, howMany);
-    if (result != NULL) {
-        /* Get random data */
-        memset(PyString_AS_STRING(result), 0, howMany); /* zero seed */
-        if (! pCryptGenRandom(hCryptProv, howMany, (unsigned char*)
-                              PyString_AS_STRING(result))) {
-            Py_DECREF(result);
-            return win32_error("CryptGenRandom", NULL);
-        }
+Return n pseudo-random bytes.");
+
+static PyObject *
+posix_urandom(PyObject *self, PyObject *args)
+{
+    Py_ssize_t size;
+    PyObject *result;
+    int ret;
+ 
+     /* Read arguments */
+    if (!PyArg_ParseTuple(args, "n:urandom", &size))
+        return NULL;
+    if (size < 0)
+         return PyErr_Format(PyExc_ValueError,
+                             "negative argument not allowed");
+    result = PyBytes_FromStringAndSize(NULL, size);
+    if (result == NULL)
+        return NULL;
+
+    ret = _PyOS_URandom(PyBytes_AS_STRING(result),
+                        PyBytes_GET_SIZE(result));
+    if (ret == -1) {
+        Py_DECREF(result);
+        return NULL;
     }
     return result;
 }
-#endif
-
-#ifdef __VMS
-/* Use openssl random routine */
-#include <openssl/rand.h>
-PyDoc_STRVAR(vms_urandom__doc__,
-"urandom(n) -> str\n\n\
-Return a string of n random bytes suitable for cryptographic use.");
-
-static PyObject*
-vms_urandom(PyObject *self, PyObject *args)
-{
-    int howMany;
-    PyObject* result;
-
-    /* Read arguments */
-    if (! PyArg_ParseTuple(args, "i:urandom", &howMany))
-        return NULL;
-    if (howMany < 0)
-        return PyErr_Format(PyExc_ValueError,
-                            "negative argument not allowed");
-
-    /* Allocate bytes */
-    result = PyString_FromStringAndSize(NULL, howMany);
-    if (result != NULL) {
-        /* Get random data */
-        if (RAND_pseudo_bytes((unsigned char*)
-                              PyString_AS_STRING(result),
-                              howMany) < 0) {
-            Py_DECREF(result);
-            return PyErr_Format(PyExc_ValueError,
-                                "RAND_pseudo_bytes");
-        }
-    }
-    return result;
-}
-#endif
 
 static PyMethodDef posix_methods[] = {
     {"access",          posix_access, METH_VARARGS, posix_access__doc__},
@@ -8787,12 +8705,7 @@
 #ifdef HAVE_GETLOADAVG
     {"getloadavg",      posix_getloadavg, METH_NOARGS, posix_getloadavg__doc__},
 #endif
- #ifdef MS_WINDOWS
-    {"urandom", win32_urandom, METH_VARARGS, win32_urandom__doc__},
- #endif
- #ifdef __VMS
-    {"urandom", vms_urandom, METH_VARARGS, vms_urandom__doc__},
- #endif
+    {"urandom",         posix_urandom,   METH_VARARGS, posix_urandom__doc__},
     {NULL,              NULL}            /* Sentinel */
 };
 
diff -r 9a4131ada792 Objects/bufferobject.c
--- a/Objects/bufferobject.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Objects/bufferobject.c	Sat Feb 11 17:59:19 2012 -0500
@@ -334,10 +334,16 @@
         return -1;
     p = (unsigned char *) ptr;
     len = size;
-    x = *p << 7;
+    if (len == 0) {
+        self->b_hash = 0;
+        return 0;
+    }
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= size;
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
     self->b_hash = x;
diff -r 9a4131ada792 Objects/object.c
--- a/Objects/object.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Objects/object.c	Sat Feb 11 17:59:19 2012 -0500
@@ -1101,6 +1101,8 @@
     return -1;
 }
 
+_Py_HashSecret_t _Py_HashSecret;
+
 long
 PyObject_Hash(PyObject *v)
 {
diff -r 9a4131ada792 Objects/stringobject.c
--- a/Objects/stringobject.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Objects/stringobject.c	Sat Feb 11 17:59:19 2012 -0500
@@ -1212,11 +1212,17 @@
     if (a->ob_shash != -1)
         return a->ob_shash;
     len = Py_SIZE(a);
+    if (len == 0) {
+        a->ob_shash = 0;
+        return 0;
+    }
     p = (unsigned char *) a->ob_sval;
-    x = *p << 7;
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= Py_SIZE(a);
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
     a->ob_shash = x;
diff -r 9a4131ada792 Objects/unicodeobject.c
--- a/Objects/unicodeobject.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Objects/unicodeobject.c	Sat Feb 11 17:59:19 2012 -0500
@@ -6695,11 +6695,17 @@
     if (self->hash != -1)
         return self->hash;
     len = PyUnicode_GET_SIZE(self);
+    if (len == 0) {
+        self->hash = 0;
+        return 0;
+    }
     p = PyUnicode_AS_UNICODE(self);
-    x = *p << 7;
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= PyUnicode_GET_SIZE(self);
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
     self->hash = x;
diff -r 9a4131ada792 PCbuild/pythoncore.vcproj
--- a/PCbuild/pythoncore.vcproj	Fri Jan 27 09:42:45 2012 +0100
+++ b/PCbuild/pythoncore.vcproj	Sat Feb 11 17:59:19 2012 -0500
@@ -1779,6 +1779,10 @@
 				>
 			</File>
 			<File
+				RelativePath="..\Python\random.c"
+				>
+			</File>
+			<File
 				RelativePath="..\Python\structmember.c"
 				>
 			</File>
diff -r 9a4131ada792 Python/pythonrun.c
--- a/Python/pythonrun.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Python/pythonrun.c	Sat Feb 11 17:59:19 2012 -0500
@@ -67,6 +67,7 @@
 static void call_ll_exitfuncs(void);
 extern void _PyUnicode_Init(void);
 extern void _PyUnicode_Fini(void);
+extern void _PyRandom_Init(void);
 
 #ifdef WITH_THREAD
 extern void _PyGILState_Init(PyInterpreterState *, PyThreadState *);
@@ -89,6 +90,7 @@
   true divisions (which they will be in 2.3). */
 int _Py_QnewFlag = 0;
 int Py_NoUserSiteDirectory = 0; /* for -s and site.py */
+int Py_HashRandomizationFlag = 0; /* for -R and PYTHONHASHRANDOMIZATION */
 
 /* PyModule_GetWarningsModule is no longer necessary as of 2.6
 since _warnings is builtin.  This API should not be used. */
@@ -166,6 +168,10 @@
         Py_OptimizeFlag = add_flag(Py_OptimizeFlag, p);
     if ((p = Py_GETENV("PYTHONDONTWRITEBYTECODE")) && *p != '\0')
         Py_DontWriteBytecodeFlag = add_flag(Py_DontWriteBytecodeFlag, p);
+    if ((p = Py_GETENV("PYTHONHASHRANDOMIZATION")) && *p != '\0')
+        Py_HashRandomizationFlag = add_flag(Py_HashRandomizationFlag, p);
+    
+    _PyRandom_Init();
 
     interp = PyInterpreterState_New();
     if (interp == NULL)
diff -r 9a4131ada792 Python/random.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Python/random.c	Sat Feb 11 17:59:19 2012 -0500
@@ -0,0 +1,303 @@
+#include "Python.h"
+#ifdef MS_WINDOWS
+#include <windows.h>
+#else
+#include <fcntl.h>
+#endif
+
+static int random_initialized = 0;
+
+#ifdef MS_WINDOWS
+typedef BOOL (WINAPI *CRYPTACQUIRECONTEXTA)(HCRYPTPROV *phProv,\
+              LPCSTR pszContainer, LPCSTR pszProvider, DWORD dwProvType,\
+              DWORD dwFlags );
+typedef BOOL (WINAPI *CRYPTGENRANDOM)(HCRYPTPROV hProv, DWORD dwLen,\
+              BYTE *pbBuffer );
+
+static CRYPTGENRANDOM pCryptGenRandom = NULL;
+/* This handle is never explicitly released. Instead, the operating
+   system will release it when the process terminates. */
+static HCRYPTPROV hCryptProv = 0;
+
+static int
+win32_urandom_init(int raise)
+{
+    HINSTANCE hAdvAPI32 = NULL;
+    CRYPTACQUIRECONTEXTA pCryptAcquireContext = NULL;
+
+    /* Obtain handle to the DLL containing CryptoAPI. This should not fail. */
+    hAdvAPI32 = GetModuleHandle("advapi32.dll");
+    if(hAdvAPI32 == NULL)
+        goto error;
+
+    /* Obtain pointers to the CryptoAPI functions. This will fail on some early
+       versions of Win95. */
+    pCryptAcquireContext = (CRYPTACQUIRECONTEXTA)GetProcAddress(
+                               hAdvAPI32, "CryptAcquireContextA");
+    if (pCryptAcquireContext == NULL)
+        goto error;
+
+    pCryptGenRandom = (CRYPTGENRANDOM)GetProcAddress(hAdvAPI32,
+                                                     "CryptGenRandom");
+    if (pCryptGenRandom == NULL)
+        goto error;
+
+    /* Acquire context */
+    if (! pCryptAcquireContext(&hCryptProv, NULL, NULL,
+                               PROV_RSA_FULL, CRYPT_VERIFYCONTEXT))
+        goto error;
+
+    return 0;
+
+error:
+    if (raise)
+        PyErr_SetFromWindowsErr(0);
+    else
+        Py_FatalError("Failed to initialize Windows random API (CryptoGen)");
+    return -1;
+}
+
+/* Fill buffer with size pseudo-random bytes generated by the Windows CryptoGen
+   API. Return 0 on success, or -1 on error. */
+static int
+win32_urandom(unsigned char *buffer, Py_ssize_t size, int raise)
+{
+    Py_ssize_t chunk;
+
+    if (hCryptProv == 0)
+    {
+        if (win32_urandom_init(raise) == -1)
+            return -1;
+    }
+
+    while (size > 0)
+    {
+        chunk = size > INT_MAX ? INT_MAX : size;
+        if (!pCryptGenRandom(hCryptProv, chunk, buffer))
+        {
+            /* CryptGenRandom() failed */
+            if (raise)
+                PyErr_SetFromWindowsErr(0);
+            else
+                Py_FatalError("Failed to initialize the randomized hash "
+                        "secret using CryptoGen)");
+            return -1;
+        }
+        buffer += chunk;
+        size -= chunk;
+    }
+    return 0;
+}
+#endif /* MS_WINDOWS */
+
+
+#ifdef __VMS
+/* Use openssl random routine */
+#include <openssl/rand.h>
+static int
+vms_urandom(unsigned char *buffer, Py_ssize_t size, int raise)
+{
+    if (RAND_pseudo_bytes(buffer, size) < 0) {
+        if (raise) {
+            PyErr_Format(PyExc_ValueError,
+                         "RAND_pseudo_bytes");
+        } else {
+            Py_FatalError("Failed to initialize the randomized hash "
+                          "secret using RAND_pseudo_bytes");
+        }
+        return -1;
+    }
+    return 0;
+}
+#endif /* __VMS */
+
+
+#if !defined(MS_WINDOWS) && !defined(__VMS)
+
+/* Read size bytes from /dev/urandom into buffer.
+   Call Py_FatalError() on error. */
+static void
+dev_urandom_noraise(char *buffer, Py_ssize_t size)
+{
+    int fd;
+    Py_ssize_t n;
+
+    assert (0 < size);
+
+    fd = open("/dev/urandom", O_RDONLY);
+    if (fd < 0)
+        Py_FatalError("Failed to open /dev/urandom");
+
+    while (0 < size)
+    {
+        do {
+            n = read(fd, buffer, (size_t)size);
+        } while (n < 0 && errno == EINTR);
+        if (n <= 0)
+        {
+            /* stop on error or if read(size) returned 0 */
+            Py_FatalError("Failed to read bytes from /dev/urandom");
+            break;
+        }
+        buffer += n;
+        size -= (Py_ssize_t)n;
+    }
+    close(fd);
+}
+
+/* Read size bytes from /dev/urandom into buffer.
+   Return 0 on success, raise an exception and return -1 on error. */
+static int
+dev_urandom_python(char *buffer, Py_ssize_t size)
+{
+    int fd;
+    Py_ssize_t n;
+
+    if (size <= 0)
+        return 0;
+
+    Py_BEGIN_ALLOW_THREADS
+    fd = open("/dev/urandom", O_RDONLY);
+    Py_END_ALLOW_THREADS
+    if (fd < 0)
+    {
+        PyErr_SetFromErrnoWithFilename(PyExc_OSError, "/dev/urandom");
+        return -1;
+    }
+
+    Py_BEGIN_ALLOW_THREADS
+    do {
+        do {
+            n = read(fd, buffer, (size_t)size);
+        } while (n < 0 && errno == EINTR);
+        if (n <= 0)
+            break;
+        buffer += n;
+        size -= (Py_ssize_t)n;
+    } while (0 < size);
+    Py_END_ALLOW_THREADS
+
+    if (n <= 0)
+    {
+        /* stop on error or if read(size) returned 0 */
+        if (n < 0)
+            PyErr_SetFromErrno(PyExc_OSError);
+        else
+            PyErr_Format(PyExc_RuntimeError,
+                         "Failed to read %zi bytes from /dev/urandom",
+                         size);
+        close(fd);
+        return -1;
+    }
+    close(fd);
+    return 0;
+}
+#endif /* !defined(MS_WINDOWS) && !defined(__VMS) */
+
+/* Fill buffer with pseudo-random bytes generated by a linear congruent
+   generator (LCG):
+
+       x(n+1) = (x(n) * 214013 + 2531011) % 2^32
+
+   Use bits 23..16 of x(n) to generate a byte. */
+static void
+lcg_urandom(unsigned int x0, unsigned char *buffer, size_t size)
+{
+    size_t index;
+    unsigned int x;
+
+    x = x0;
+    for (index=0; index < size; index++) {
+        x *= 214013;
+        x += 2531011;
+        /* modulo 2 ^ (8 * sizeof(int)) */
+        buffer[index] = (x >> 16) & 0xff;
+    }
+}
+
+/* Fill buffer with size pseudo-random bytes, not suitable for cryptographic
+   use, from the operating random number generator (RNG).
+
+   Return 0 on success, raise an exception and return -1 on error. */
+int
+_PyOS_URandom(void *buffer, Py_ssize_t size)
+{
+    if (size < 0) {
+        PyErr_Format(PyExc_ValueError,
+                     "negative argument not allowed");
+        return -1;
+    }
+    if (size == 0)
+        return 0;
+
+#ifdef MS_WINDOWS
+    return win32_urandom((unsigned char *)buffer, size, 1);
+#else
+ #ifdef __VMS
+    return vms_urandom((unsigned char *)secret, secret_size, 1);
+ #else
+    return dev_urandom_python((char*)buffer, size);
+ #endif
+#endif/* #else clause of #ifdef MS_WINDOWS */
+}
+
+void
+_PyRandom_Init(void)
+{
+    char *env;
+    void *secret = &_Py_HashSecret;
+    Py_ssize_t secret_size = sizeof(_Py_HashSecret);
+
+    if (random_initialized)
+        return;
+    random_initialized = 1;
+
+    /*
+      By default, hash randomization is disabled, and only
+      enabled if PYTHONHASHRANDOMIZATION is set to non-empty
+      or if "-R" is provided at the command line:
+    */
+    if (!Py_HashRandomizationFlag) {
+        /* Disable the randomized hash: */
+        memset(secret, 0, secret_size);
+        return;
+    }
+
+    /*
+      PYTHONHASHRANDOMIZATION was found; generate a per-process secret,
+      using PYTHONHASHSEED if provided.
+    */
+
+    env = Py_GETENV("PYTHONHASHSEED");
+    if (env && *env != '\0') {
+        char *endptr = env;
+        unsigned long seed;
+        seed = strtoul(env, &endptr, 10);
+        if (*endptr != '\0'
+            || seed > 4294967295UL
+            || (errno == ERANGE && seed == ULONG_MAX))
+        {
+            Py_FatalError("PYTHONHASHSEED must be an integer "
+                          "in range [0; 4294967295]");
+        }
+        if (seed == 0) {
+            /* disable the randomized hash */
+            memset(secret, 0, secret_size);
+        }
+        else {
+            lcg_urandom(seed, (unsigned char*)secret, secret_size);
+        }
+    }
+    else {
+#ifdef MS_WINDOWS
+        (void)win32_urandom((unsigned char *)secret, secret_size, 0);
+#else /* #ifdef MS_WINDOWS */
+ #ifdef __VMS
+        vms_urandom((unsigned char *)secret, secret_size, 0);
+ #else
+        dev_urandom_noraise((char*)secret, secret_size);
+ #endif
+#endif/* #else clause of #ifdef MS_WINDOWS */
+    }
+}
+
diff -r 9a4131ada792 Python/sysmodule.c
--- a/Python/sysmodule.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Python/sysmodule.c	Sat Feb 11 17:59:19 2012 -0500
@@ -1224,6 +1224,7 @@
     {"unicode",                 "-U"},
     /* {"skip_first",                   "-x"}, */
     {"bytes_warning", "-b"},
+    {"hash_randomization", "-R"},
     {0}
 };
 
@@ -1232,9 +1233,9 @@
     flags__doc__,       /* doc */
     flags_fields,       /* fields */
 #ifdef RISCOS
+    17
+#else
     16
-#else
-    15
 #endif
 };
 
@@ -1271,6 +1272,7 @@
     SetFlag(Py_UnicodeFlag);
     /* SetFlag(skipfirstline); */
     SetFlag(Py_BytesWarningFlag);
+    SetFlag(Py_HashRandomizationFlag);
 #undef SetFlag
 
     if (PyErr_Occurred()) {
-------------- next part --------------
diff -r e7706bdaaa0d Doc/library/sys.rst
--- a/Doc/library/sys.rst	Fri Jan 27 09:48:47 2012 +0100
+++ b/Doc/library/sys.rst	Sat Feb 11 17:59:37 2012 -0500
@@ -220,6 +220,7 @@
    :const:`ignore_environment`   :option:`-E`
    :const:`verbose`              :option:`-v`
    :const:`bytes_warning`        :option:`-b`
+   :const:`hash_randomization`   :option:`-R`
    ============================= =============================
 
 
diff -r e7706bdaaa0d Doc/reference/datamodel.rst
--- a/Doc/reference/datamodel.rst	Fri Jan 27 09:48:47 2012 +0100
+++ b/Doc/reference/datamodel.rst	Sat Feb 11 17:59:37 2012 -0500
@@ -1265,6 +1265,8 @@
    inheritance of :meth:`__hash__` will be blocked, just as if :attr:`__hash__`
    had been explicitly set to :const:`None`.
 
+   See also the :option:`-R` command-line option.
+
 
 .. method:: object.__bool__(self)
 
diff -r e7706bdaaa0d Doc/using/cmdline.rst
--- a/Doc/using/cmdline.rst	Fri Jan 27 09:48:47 2012 +0100
+++ b/Doc/using/cmdline.rst	Sat Feb 11 17:59:37 2012 -0500
@@ -21,7 +21,7 @@
 
 When invoking Python, you may specify any of these options::
 
-    python [-bBdEhiOsSuvVWx?] [-c command | -m module-name | script | - ] [args]
+    python [-bBdEhiORsSuvVWx?] [-c command | -m module-name | script | - ] [args]
 
 The most common use case is, of course, a simple invocation of a script::
 
@@ -215,6 +215,30 @@
    Discard docstrings in addition to the :option:`-O` optimizations.
 
 
+.. cmdoption:: -R
+
+   Turn on hash randomization, so that the :meth:`__hash__` values of str,
+   bytes and datetime objects are "salted" with an unpredictable random value.
+   Although they remain constant within an individual Python process, they
+   are not predictable between repeated invocations of Python.
+
+   This is intended to provide protection against a denial-of-service
+   caused by carefully-chosen inputs that exploit the worst case performance
+   of a dict lookup, O(n^2) complexity.  See:
+
+       http://www.ocert.org/advisories/ocert-2011-003.html
+
+   for details.
+
+   Changing hash values affects the order in which keys are retrieved from
+   a dict.  Although Python has never made guarantees about this ordering
+   (and it typically varies between 32-bit and 64-bit builds), enough
+   real-world code implicitly relies on this non-guaranteed behavior that
+   the randomization is disabled by default.
+
+   See also :envvar:`PYTHONHASHRANDOMIZATION`.
+
+
 .. cmdoption:: -s
 
    Don't add user site directory to sys.path
@@ -435,6 +459,30 @@
    import of source modules.
 
 
+.. envvar:: PYTHONHASHRANDOMIZATION
+
+   If this is set to a non-empty string it is equivalent to specifying the
+   :option:`-R` option.
+
+
+.. envvar:: PYTHONHASHSEED
+
+   This environment variable only has an effect when hash randomization has
+   been enabled (via the :option:`-R` option, or its equivalent environment
+   variable, :envvar:`PYTHONHASHRANDOMIZATION`).
+
+   If :envvar:`PYTHONHASHSEED` is set, it is used as a fixed seed for
+   generating the hash() of the types covered by the hash randomization.
+
+   Its purpose is to allow repeatable hashing, such as for selftests for the
+   interpreter itself, or to allow a cluster of python processes to share hash
+   values.
+
+   It should be a decimal number in the range [0; 4294967295].  Specifying
+   the value 0 will lead to the same hash values as when hash randomization
+   is disabled.
+
+
 .. envvar:: PYTHONIOENCODING
 
    Overrides the encoding used for stdin/stdout/stderr, in the syntax
diff -r e7706bdaaa0d Include/object.h
--- a/Include/object.h	Fri Jan 27 09:48:47 2012 +0100
+++ b/Include/object.h	Sat Feb 11 17:59:37 2012 -0500
@@ -473,6 +473,12 @@
 PyAPI_FUNC(long) _Py_HashDouble(double);
 PyAPI_FUNC(long) _Py_HashPointer(void*);
 
+typedef struct {
+    long prefix;
+    long suffix;
+} _Py_HashSecret_t;
+PyAPI_DATA(_Py_HashSecret_t) _Py_HashSecret;
+
 /* Helper for passing objects to printf and the like */
 #define PyObject_REPR(obj) _PyUnicode_AsString(PyObject_Repr(obj))
 
diff -r e7706bdaaa0d Include/pydebug.h
--- a/Include/pydebug.h	Fri Jan 27 09:48:47 2012 +0100
+++ b/Include/pydebug.h	Sat Feb 11 17:59:37 2012 -0500
@@ -19,6 +19,7 @@
 PyAPI_DATA(int) Py_DontWriteBytecodeFlag;
 PyAPI_DATA(int) Py_NoUserSiteDirectory;
 PyAPI_DATA(int) Py_UnbufferedStdioFlag;
+PyAPI_DATA(int) Py_HashRandomizationFlag;
 
 /* this is a wrapper around getenv() that pays attention to
    Py_IgnoreEnvironmentFlag.  It should be used for getting variables like
diff -r e7706bdaaa0d Include/pythonrun.h
--- a/Include/pythonrun.h	Fri Jan 27 09:48:47 2012 +0100
+++ b/Include/pythonrun.h	Sat Feb 11 17:59:37 2012 -0500
@@ -174,6 +174,8 @@
 PyAPI_FUNC(PyOS_sighandler_t) PyOS_getsig(int);
 PyAPI_FUNC(PyOS_sighandler_t) PyOS_setsig(int, PyOS_sighandler_t);
 
+/* Random */
+PyAPI_FUNC(int) _PyOS_URandom (void *buffer, Py_ssize_t size);
 
 #ifdef __cplusplus
 }
diff -r e7706bdaaa0d Lib/os.py
--- a/Lib/os.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/os.py	Sat Feb 11 17:59:37 2012 -0500
@@ -611,23 +611,6 @@
 except NameError: # statvfs_result may not exist
     pass
 
-if not _exists("urandom"):
-    def urandom(n):
-        """urandom(n) -> str
-
-        Return a string of n random bytes suitable for cryptographic use.
-
-        """
-        try:
-            _urandomfd = open("/dev/urandom", O_RDONLY)
-        except (OSError, IOError):
-            raise NotImplementedError("/dev/urandom (or equivalent) not found")
-        bs = b""
-        while len(bs) < n:
-            bs += read(_urandomfd, n - len(bs))
-        close(_urandomfd)
-        return bs
-
 # Supply os.popen()
 def popen(cmd, mode="r", buffering=-1):
     if not isinstance(cmd, str):
diff -r e7706bdaaa0d Lib/test/regrtest.py
--- a/Lib/test/regrtest.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/regrtest.py	Sat Feb 11 17:59:37 2012 -0500
@@ -428,6 +428,11 @@
         except ValueError:
             print("Couldn't find starting test (%s), using all tests" % start)
     if randomize:
+        hashseed = os.getenv('PYTHONHASHSEED')
+        if not hashseed:
+            os.environ['PYTHONHASHSEED'] = str(random_seed)
+            os.execv(sys.executable, [sys.executable] + sys.argv)
+            return
         random.seed(random_seed)
         print("Using random seed", random_seed)
         random.shuffle(tests)
diff -r e7706bdaaa0d Lib/test/test_cmd_line.py
--- a/Lib/test/test_cmd_line.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_cmd_line.py	Sat Feb 11 17:59:37 2012 -0500
@@ -190,6 +190,22 @@
             self.assertTrue(path1.encode('ascii') in stdout)
             self.assertTrue(path2.encode('ascii') in stdout)
 
+    def test_hash_randomization(self):
+        # Verify that -R enables hash randomization:
+        self.verify_valid_flag('-R')
+        hashes = []
+        for i in range(2):
+            code = 'print(hash("spam"))'
+            data, rc = self.start_python_and_exit_code('-R', '-c', code)
+            self.assertEqual(rc, 0)
+            hashes.append(data)
+        self.assertNotEqual(hashes[0], hashes[1])
+
+        # Verify that sys.flags contains hash_randomization
+        code = 'import sys; print(sys.flags)'
+        data, rc = self.start_python_and_exit_code('-R', '-c', code)
+        self.assertEqual(rc,0)
+        self.assertIn(b'hash_randomization=1', data)
 
 def test_main():
     test.support.run_unittest(CmdLineTest)
diff -r e7706bdaaa0d Lib/test/test_hash.py
--- a/Lib/test/test_hash.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_hash.py	Sat Feb 11 17:59:37 2012 -0500
@@ -3,10 +3,16 @@
 #
 # Also test that hash implementations are inherited as expected
 
+import datetime
+import os
+import struct
 import unittest
 from test import support
+from test.script_helper import assert_python_ok
 from collections import Hashable
 
+IS_64BIT = (struct.calcsize('l') == 8)
+
 
 class HashEqualityTestCase(unittest.TestCase):
 
@@ -118,10 +124,92 @@
         for obj in self.hashes_to_check:
             self.assertEqual(hash(obj), _default_hash(obj))
 
+class HashRandomizationTests(unittest.TestCase):
+
+    # Each subclass should define a field "repr_", containing the repr() of
+    # an object to be tested
+
+    def get_hash_command(self, repr_):
+        return 'print(hash(%s))' % repr_
+
+    def get_hash(self, repr_, randomization=None, seed=None):
+        env = os.environ.copy()
+        if randomization is not None:
+            env['PYTHONHASHRANDOMIZATION'] = str(randomization)
+        if seed is not None:
+            env['PYTHONHASHSEED'] = str(seed)
+        out = assert_python_ok(
+            '-c', self.get_hash_command(repr_),
+            **env)
+        stdout = out[1].strip()
+        return int(stdout)
+
+    def test_randomized_hash(self):
+        # two runs should return different hashes
+        run1 = self.get_hash(self.repr_, randomization=1)
+        run2 = self.get_hash(self.repr_, randomization=1)
+        self.assertNotEqual(run1, run2)
+
+class StringlikeHashRandomizationTests(HashRandomizationTests):
+    def test_null_hash(self):
+        # PYTHONHASHSEED=0 disables the randomized hash
+        if IS_64BIT:
+            known_hash_of_obj = 1453079729188098211
+        else:
+            known_hash_of_obj = -1600925533
+
+        # Randomization is disabled by default:
+        self.assertEqual(self.get_hash(self.repr_), known_hash_of_obj)
+
+        # If enabled, it can still be disabled by setting the seed to 0:
+        self.assertEqual(self.get_hash(self.repr_, randomization=1, seed=0),
+                         known_hash_of_obj)
+
+    def test_fixed_hash(self):
+        # test a fixed seed for the randomized hash
+        # Note that all types share the same values:
+        if IS_64BIT:
+            h = -4410911502303878509
+        else:
+            h = -206076799
+        self.assertEqual(self.get_hash(self.repr_, randomization=1, seed=42),
+                         h)
+
+class StrHashRandomizationTests(StringlikeHashRandomizationTests):
+    repr_ = repr('abc')
+
+    def test_empty_string(self):
+        self.assertEqual(hash(""), 0)
+
+class BytesHashRandomizationTests(StringlikeHashRandomizationTests):
+    repr_ = repr(b'abc')
+
+    def test_empty_string(self):
+        self.assertEqual(hash(b""), 0)
+
+class DatetimeTests(HashRandomizationTests):
+    def get_hash_command(self, repr_):
+        return 'import datetime; print(hash(%s))' % repr_
+
+class DatetimeDateTests(DatetimeTests):
+    repr_ = repr(datetime.date(1066, 10, 14))
+
+class DatetimeDatetimeTests(DatetimeTests):
+    repr_ = repr(datetime.datetime(1, 2, 3, 4, 5, 6, 7))
+
+class DatetimeTimeTests(DatetimeTests):
+    repr_ = repr(datetime.time(0))
+
 def test_main():
     support.run_unittest(HashEqualityTestCase,
                               HashInheritanceTestCase,
-                              HashBuiltinsTestCase)
+                              HashBuiltinsTestCase,
+                         StrHashRandomizationTests,
+                         BytesHashRandomizationTests,
+                         DatetimeDateTests,
+                         DatetimeDatetimeTests,
+                         DatetimeTimeTests)
+
 
 
 if __name__ == "__main__":
diff -r e7706bdaaa0d Lib/test/test_os.py
--- a/Lib/test/test_os.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_os.py	Sat Feb 11 17:59:37 2012 -0500
@@ -9,6 +9,7 @@
 import sys
 import shutil
 from test import support
+from test.script_helper import assert_python_ok
 
 # Detect whether we're on a Linux system that uses the (now outdated
 # and unmaintained) linuxthreads threading library.  There's an issue
@@ -574,14 +575,33 @@
         f.close()
 
 class URandomTests(unittest.TestCase):
-    def test_urandom(self):
-        try:
-            self.assertEqual(len(os.urandom(1)), 1)
-            self.assertEqual(len(os.urandom(10)), 10)
-            self.assertEqual(len(os.urandom(100)), 100)
-            self.assertEqual(len(os.urandom(1000)), 1000)
-        except NotImplementedError:
-            pass
+    def test_urandom_length(self):
+        self.assertEqual(len(os.urandom(0)), 0)
+        self.assertEqual(len(os.urandom(1)), 1)
+        self.assertEqual(len(os.urandom(10)), 10)
+        self.assertEqual(len(os.urandom(100)), 100)
+        self.assertEqual(len(os.urandom(1000)), 1000)
+
+    def test_urandom_value(self):
+        data1 = os.urandom(16)
+        data2 = os.urandom(16)
+        self.assertNotEqual(data1, data2)
+
+    def get_urandom_subprocess(self, count):
+        code = '\n'.join((
+            'import os, sys',
+            'data = os.urandom(%s)' % count,
+            'sys.stdout.buffer.write(data)',
+            'sys.stdout.buffer.flush()'))
+        out = assert_python_ok('-c', code)
+        stdout = out[1]
+        self.assertEqual(len(stdout), 16)
+        return stdout
+
+    def test_urandom_subprocess(self):
+        data1 = self.get_urandom_subprocess(16)
+        data2 = self.get_urandom_subprocess(16)
+        self.assertNotEqual(data1, data2)
 
 class ExecTests(unittest.TestCase):
     @unittest.skipIf(USING_LINUXTHREADS,
diff -r e7706bdaaa0d Lib/test/test_sys.py
--- a/Lib/test/test_sys.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_sys.py	Sat Feb 11 17:59:37 2012 -0500
@@ -446,7 +446,7 @@
         attrs = ("debug", "division_warning",
                  "inspect", "interactive", "optimize", "dont_write_bytecode",
                  "no_user_site", "no_site", "ignore_environment", "verbose",
-                 "bytes_warning")
+                 "bytes_warning", "hash_randomization")
         for attr in attrs:
             self.assertTrue(hasattr(sys.flags, attr), attr)
             self.assertEqual(type(getattr(sys.flags, attr)), int, attr)
diff -r e7706bdaaa0d Makefile.pre.in
--- a/Makefile.pre.in	Fri Jan 27 09:48:47 2012 +0100
+++ b/Makefile.pre.in	Sat Feb 11 17:59:37 2012 -0500
@@ -305,6 +305,7 @@
 		Python/pymath.o \
 		Python/pystate.o \
 		Python/pythonrun.o \
+		Python/random.o \
 		Python/structmember.o \
 		Python/symtable.o \
 		Python/sysmodule.o \
diff -r e7706bdaaa0d Misc/NEWS
--- a/Misc/NEWS	Fri Jan 27 09:48:47 2012 +0100
+++ b/Misc/NEWS	Sat Feb 11 17:59:37 2012 -0500
@@ -10,6 +10,12 @@
 Core and Builtins
 -----------------
 
+- Issue #13703: oCERT-2011-003: add -R command-line option and
+  PYTHONHASHRANDOMIZATION (and PYTHONHASHSEED) environment variables, to
+  provide an opt-in way to protect against denial of service attacks due to
+  hash collisions within the dict and set types.  Patch by David Malcolm,
+  based on work by Victor Stinner.
+
 Library
 -------
 
diff -r e7706bdaaa0d Misc/python.man
--- a/Misc/python.man	Fri Jan 27 09:48:47 2012 +0100
+++ b/Misc/python.man	Sat Feb 11 17:59:37 2012 -0500
@@ -34,6 +34,9 @@
 .B \-OO
 ]
 [
+.B \-R
+]
+[
 .B -Q
 .I argument
 ]
@@ -145,6 +148,18 @@
 .B \-OO
 Discard docstrings in addition to the \fB-O\fP optimizations.
 .TP
+.B \-R
+Turn on "hash randomization", so that the hash() values of str, bytes and
+datetime objects are "salted" with an unpredictable pseudo-random value.
+Although they remain constant within an individual Python process, they are
+not predictable between repeated invocations of Python.
+.IP
+This is intended to provide protection against a denial of service
+caused by carefully-chosen inputs that exploit the worst case performance
+of a dict lookup, O(n^2) complexity.  See
+http://www.ocert.org/advisories/ocert-2011-003.html
+for details.
+.TP
 .BI "\-Q " argument
 Division control; see PEP 238.  The argument must be one of "old" (the
 default, int/int and long/long return an int or long), "new" (new
@@ -403,6 +418,24 @@
 If this is set to a non-empty string it is equivalent to specifying
 the \fB\-v\fP option. If set to an integer, it is equivalent to
 specifying \fB\-v\fP multiple times. 
+.IP PYTHONHASHRANDOMIZATION
+If this is set to a non-empty string it is equivalent to specifying the
+\fB\-R\fP option.
+.IP PYTHONHASHSEED
+This environment variable only has an effect when hash randomization has
+been enabled (via the \fB\-R\fP option, or its equivalent environment
+variable, \fB\PYTHONHASHRANDOMIZATION\fP).
+
+If PYTHONHASHSEED is set, it is used as a fixed seed for
+generating the hash() of the types covered by the hash randomization.
+
+Its purpose is to allow repeatable hashing, such as for selftests for the
+interpreter itself, or to allow a cluster of python processes to share hash
+values.
+
+It should be a decimal number in the range [0; 4294967295].  Specifying
+the value 0 will lead to the same hash values as when hash randomization
+is disabled.
 .SH AUTHOR
 The Python Software Foundation: http://www.python.org/psf
 .SH INTERNET RESOURCES
diff -r e7706bdaaa0d Modules/datetimemodule.c
--- a/Modules/datetimemodule.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Modules/datetimemodule.c	Sat Feb 11 17:59:37 2012 -0500
@@ -2566,10 +2566,12 @@
     register long x;
 
     p = (unsigned char *) data;
-    x = *p << 7;
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= len;
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
 
diff -r e7706bdaaa0d Modules/main.c
--- a/Modules/main.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Modules/main.c	Sat Feb 11 17:59:37 2012 -0500
@@ -47,7 +47,7 @@
 static int  orig_argc;
 
 /* command line options */
-#define BASE_OPTS L"bBc:dEhiJm:OsStuvVW:xX?"
+#define BASE_OPTS L"bBc:dEhiJm:ORsStuvVW:xX?"
 
 #define PROGRAM_OPTS BASE_OPTS
 
@@ -72,6 +72,9 @@
 -m mod : run library module as a script (terminates option list)\n\
 -O     : optimize generated bytecode slightly; also PYTHONOPTIMIZE=x\n\
 -OO    : remove doc-strings in addition to the -O optimizations\n\
+-R     : use a pseudo-random salt to make hash() values of various types be\n\
+         unpredictable between separate invocations of the interpreter, as\n\
+         a defence against denial-of-service attacks\n\
 -s     : don't add user site directory to sys.path; also PYTHONNOUSERSITE\n\
 -S     : don't imply 'import site' on initialization\n\
 ";
@@ -99,6 +102,25 @@
 PYTHONCASEOK : ignore case in 'import' statements (Windows).\n\
 PYTHONIOENCODING: Encoding[:errors] used for stdin/stdout/stderr.\n\
 ";
+static char *usage_6 = "\
+PYTHONHASHRANDOMIZATION : make hash() values of various types be unpredictable\n\
+                          between separate invocations of the interpreter, as\n\
+                          a defence against denial-of-service attacks\n\
+PYTHONHASHSEED: this environment variable only has an effect when hash\n\
+                randomization has been enabled (via the -R option, or its\n\
+                equivalent environment variable, PYTHONHASHRANDOMIZATION)\n\
+\n\
+                If PYTHONHASHSEED is set, it is used as a fixed seed for\n\
+                generating the hash() of the types covered by the hash randomization\n\
+\n\
+                Its purpose is to allow repeatable hashing, such as for\n\
+                selftests for the interpreter itself, or to allow a cluster of\n\
+                python processes to share hash values.\n\
+\n\
+                It should be a decimal number in the range [0; 4294967295].\n\
+                Specifying the value 0 will lead to the same hash values as\n\
+                when hash randomization is disabled.\n\
+";
 
 #ifndef MS_WINDOWS
 static FILE*
@@ -136,6 +158,7 @@
         fputs(usage_3, f);
         fprintf(f, usage_4, DELIM);
         fprintf(f, usage_5, DELIM, PYTHONHOMEHELP);
+        fputs(usage_6, f);
     }
 #if defined(__VMS)
     if (exitcode == 0) {
@@ -373,6 +396,10 @@
             PySys_AddWarnOption(_PyOS_optarg);
             break;
 
+        case 'R':
+            Py_HashRandomizationFlag++;
+            break;
+
         /* This space reserved for other options */
 
         default:
diff -r e7706bdaaa0d Modules/posixmodule.c
--- a/Modules/posixmodule.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Modules/posixmodule.c	Sat Feb 11 17:59:37 2012 -0500
@@ -6942,82 +6942,6 @@
 }
 #endif
 
-#ifdef MS_WINDOWS
-
-PyDoc_STRVAR(win32_urandom__doc__,
-"urandom(n) -> str\n\n\
-Return n random bytes suitable for cryptographic use.");
-
-typedef BOOL (WINAPI *CRYPTACQUIRECONTEXTA)(HCRYPTPROV *phProv,\
-              LPCSTR pszContainer, LPCSTR pszProvider, DWORD dwProvType,\
-              DWORD dwFlags );
-typedef BOOL (WINAPI *CRYPTGENRANDOM)(HCRYPTPROV hProv, DWORD dwLen,\
-              BYTE *pbBuffer );
-
-static CRYPTGENRANDOM pCryptGenRandom = NULL;
-/* This handle is never explicitly released. Instead, the operating
-   system will release it when the process terminates. */
-static HCRYPTPROV hCryptProv = 0;
-
-static PyObject*
-win32_urandom(PyObject *self, PyObject *args)
-{
-    int howMany;
-    PyObject* result;
-
-    /* Read arguments */
-    if (! PyArg_ParseTuple(args, "i:urandom", &howMany))
-        return NULL;
-    if (howMany < 0)
-        return PyErr_Format(PyExc_ValueError,
-                            "negative argument not allowed");
-
-    if (hCryptProv == 0) {
-        HINSTANCE hAdvAPI32 = NULL;
-        CRYPTACQUIRECONTEXTA pCryptAcquireContext = NULL;
-
-        /* Obtain handle to the DLL containing CryptoAPI
-           This should not fail         */
-        hAdvAPI32 = GetModuleHandle("advapi32.dll");
-        if(hAdvAPI32 == NULL)
-            return win32_error("GetModuleHandle", NULL);
-
-        /* Obtain pointers to the CryptoAPI functions
-           This will fail on some early versions of Win95 */
-        pCryptAcquireContext = (CRYPTACQUIRECONTEXTA)GetProcAddress(
-                                        hAdvAPI32,
-                                        "CryptAcquireContextA");
-        if (pCryptAcquireContext == NULL)
-            return PyErr_Format(PyExc_NotImplementedError,
-                                "CryptAcquireContextA not found");
-
-        pCryptGenRandom = (CRYPTGENRANDOM)GetProcAddress(
-                                        hAdvAPI32, "CryptGenRandom");
-        if (pCryptGenRandom == NULL)
-            return PyErr_Format(PyExc_NotImplementedError,
-                                "CryptGenRandom not found");
-
-        /* Acquire context */
-        if (! pCryptAcquireContext(&hCryptProv, NULL, NULL,
-                                   PROV_RSA_FULL, CRYPT_VERIFYCONTEXT))
-            return win32_error("CryptAcquireContext", NULL);
-    }
-
-    /* Allocate bytes */
-    result = PyBytes_FromStringAndSize(NULL, howMany);
-    if (result != NULL) {
-        /* Get random data */
-        memset(PyBytes_AS_STRING(result), 0, howMany); /* zero seed */
-        if (! pCryptGenRandom(hCryptProv, howMany, (unsigned char*)
-                              PyBytes_AS_STRING(result))) {
-            Py_DECREF(result);
-            return win32_error("CryptGenRandom", NULL);
-        }
-    }
-    return result;
-}
-#endif
-
 PyDoc_STRVAR(device_encoding__doc__,
 "device_encoding(fd) -> str\n\n\
 Return a string describing the encoding of the device\n\
@@ -7055,41 +6979,35 @@
     return Py_None;
 }
 
-#ifdef __VMS
-/* Use openssl random routine */
-#include <openssl/rand.h>
-PyDoc_STRVAR(vms_urandom__doc__,
+PyDoc_STRVAR(posix_urandom__doc__,
 "urandom(n) -> str\n\n\
-Return n random bytes suitable for cryptographic use.");
-
-static PyObject*
-vms_urandom(PyObject *self, PyObject *args)
-{
-    int howMany;
-    PyObject* result;
-
-    /* Read arguments */
-    if (! PyArg_ParseTuple(args, "i:urandom", &howMany))
-        return NULL;
-    if (howMany < 0)
+Return n pseudo-random bytes.");
+
+static PyObject *
+posix_urandom(PyObject *self, PyObject *args)
+{
+    Py_ssize_t size;
+    PyObject *result;
+    int ret;
+ 
+     /* Read arguments */
+    if (!PyArg_ParseTuple(args, "n:urandom", &size))
+        return NULL;
+    if (size < 0)
         return PyErr_Format(PyExc_ValueError,
                             "negative argument not allowed");
-
-    /* Allocate bytes */
-    result = PyBytes_FromStringAndSize(NULL, howMany);
-    if (result != NULL) {
-        /* Get random data */
-        if (RAND_pseudo_bytes((unsigned char*)
-                              PyBytes_AS_STRING(result),
-                              howMany) < 0) {
-            Py_DECREF(result);
-            return PyErr_Format(PyExc_ValueError,
-                                "RAND_pseudo_bytes");
-        }
+    result = PyBytes_FromStringAndSize(NULL, size);
+    if (result == NULL)
+        return NULL;
+
+    ret = _PyOS_URandom(PyBytes_AS_STRING(result),
+                        PyBytes_GET_SIZE(result));
+    if (ret == -1) {
+        Py_DECREF(result);
+        return NULL;
     }
     return result;
 }
-#endif
 
 static PyMethodDef posix_methods[] = {
     {"access",          posix_access, METH_VARARGS, posix_access__doc__},
@@ -7374,12 +7292,7 @@
 #ifdef HAVE_GETLOADAVG
     {"getloadavg",      posix_getloadavg, METH_NOARGS, posix_getloadavg__doc__},
 #endif
- #ifdef MS_WINDOWS
-    {"urandom", win32_urandom, METH_VARARGS, win32_urandom__doc__},
- #endif
- #ifdef __VMS
-    {"urandom", vms_urandom, METH_VARARGS, vms_urandom__doc__},
- #endif
+    {"urandom",         posix_urandom,   METH_VARARGS, posix_urandom__doc__},
     {NULL,              NULL}            /* Sentinel */
 };
 
diff -r e7706bdaaa0d Objects/bytesobject.c
--- a/Objects/bytesobject.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Objects/bytesobject.c	Sat Feb 11 17:59:37 2012 -0500
@@ -899,11 +899,17 @@
     if (a->ob_shash != -1)
         return a->ob_shash;
     len = Py_SIZE(a);
+    if (len == 0) {
+        a->ob_shash = 0;
+        return 0;
+    }
     p = (unsigned char *) a->ob_sval;
-    x = *p << 7;
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= Py_SIZE(a);
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
     a->ob_shash = x;
diff -r e7706bdaaa0d Objects/object.c
--- a/Objects/object.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Objects/object.c	Sat Feb 11 17:59:37 2012 -0500
@@ -712,6 +712,8 @@
     return -1;
 }
 
+_Py_HashSecret_t _Py_HashSecret;
+
 long
 PyObject_Hash(PyObject *v)
 {
diff -r e7706bdaaa0d Objects/unicodeobject.c
--- a/Objects/unicodeobject.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Objects/unicodeobject.c	Sat Feb 11 17:59:37 2012 -0500
@@ -7344,11 +7344,17 @@
     if (self->hash != -1)
         return self->hash;
     len = Py_SIZE(self);
+    if (len == 0) {
+        self->hash = 0;
+        return 0;
+    }
     p = self->str;
-    x = *p << 7;
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= Py_SIZE(self);
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
     self->hash = x;
diff -r e7706bdaaa0d PCbuild/pythoncore.vcproj
--- a/PCbuild/pythoncore.vcproj	Fri Jan 27 09:48:47 2012 +0100
+++ b/PCbuild/pythoncore.vcproj	Sat Feb 11 17:59:37 2012 -0500
@@ -1778,6 +1778,10 @@
 				RelativePath="..\Python\pythonrun.c"
 				>
 			</File>
+ 			<File
+				RelativePath="..\Python\random.c"
+				>
+			</File>
 			<File
 				RelativePath="..\Python\structmember.c"
 				>
diff -r e7706bdaaa0d Python/pythonrun.c
--- a/Python/pythonrun.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Python/pythonrun.c	Sat Feb 11 17:59:37 2012 -0500
@@ -73,6 +73,7 @@
 extern void _PyUnicode_Fini(void);
 extern int _PyLong_Init(void);
 extern void PyLong_Fini(void);
+extern void _PyRandom_Init(void);
 
 #ifdef WITH_THREAD
 extern void _PyGILState_Init(PyInterpreterState *, PyThreadState *);
@@ -91,6 +92,7 @@
 int Py_IgnoreEnvironmentFlag; /* e.g. PYTHONPATH, PYTHONHOME */
 int Py_NoUserSiteDirectory = 0; /* for -s and site.py */
 int Py_UnbufferedStdioFlag = 0; /* Unbuffered binary std{in,out,err} */
+int Py_HashRandomizationFlag = 0; /* for -R and PYTHONHASHRANDOMIZATION */
 
 /* PyModule_GetWarningsModule is no longer necessary as of 2.6
 since _warnings is builtin.  This API should not be used. */
@@ -195,6 +197,10 @@
         Py_OptimizeFlag = add_flag(Py_OptimizeFlag, p);
     if ((p = Py_GETENV("PYTHONDONTWRITEBYTECODE")) && *p != '\0')
         Py_DontWriteBytecodeFlag = add_flag(Py_DontWriteBytecodeFlag, p);
+    if ((p = Py_GETENV("PYTHONHASHRANDOMIZATION")) && *p != '\0')
+        Py_HashRandomizationFlag = add_flag(Py_HashRandomizationFlag, p);
+    
+    _PyRandom_Init();
 
     interp = PyInterpreterState_New();
     if (interp == NULL)
diff -r e7706bdaaa0d Python/random.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Python/random.c	Sat Feb 11 17:59:37 2012 -0500
@@ -0,0 +1,299 @@
+#include "Python.h"
+#ifdef MS_WINDOWS
+#include <windows.h>
+#else
+#include <fcntl.h>
+#endif
+
+static int random_initialized = 0;
+
+#ifdef MS_WINDOWS
+typedef BOOL (WINAPI *CRYPTACQUIRECONTEXTA)(HCRYPTPROV *phProv,\
+              LPCSTR pszContainer, LPCSTR pszProvider, DWORD dwProvType,\
+              DWORD dwFlags );
+typedef BOOL (WINAPI *CRYPTGENRANDOM)(HCRYPTPROV hProv, DWORD dwLen,\
+              BYTE *pbBuffer );
+
+static CRYPTGENRANDOM pCryptGenRandom = NULL;
+/* This handle is never explicitly released. Instead, the operating
+   system will release it when the process terminates. */
+static HCRYPTPROV hCryptProv = 0;
+
+static int
+win32_urandom_init(int raise)
+{
+    HINSTANCE hAdvAPI32 = NULL;
+    CRYPTACQUIRECONTEXTA pCryptAcquireContext = NULL;
+
+    /* Obtain handle to the DLL containing CryptoAPI. This should not fail. */
+    hAdvAPI32 = GetModuleHandle("advapi32.dll");
+    if(hAdvAPI32 == NULL)
+        goto error;
+
+    /* Obtain pointers to the CryptoAPI functions. This will fail on some early
+       versions of Win95. */
+    pCryptAcquireContext = (CRYPTACQUIRECONTEXTA)GetProcAddress(
+                               hAdvAPI32, "CryptAcquireContextA");
+    if (pCryptAcquireContext == NULL)
+        goto error;
+
+    pCryptGenRandom = (CRYPTGENRANDOM)GetProcAddress(hAdvAPI32,
+                                                     "CryptGenRandom");
+    if (pCryptGenRandom == NULL)
+        goto error;
+
+    /* Acquire context */
+    if (! pCryptAcquireContext(&hCryptProv, NULL, NULL,
+                               PROV_RSA_FULL, CRYPT_VERIFYCONTEXT))
+        goto error;
+
+    return 0;
+
+error:
+    if (raise)
+        PyErr_SetFromWindowsErr(0);
+    else
+        Py_FatalError("Failed to initialize Windows random API (CryptoGen)");
+    return -1;
+}
+
+/* Fill buffer with size pseudo-random bytes generated by the Windows CryptoGen
+   API. Return 0 on success, or -1 on error. */
+static int
+win32_urandom(unsigned char *buffer, Py_ssize_t size, int raise)
+{
+    Py_ssize_t chunk;
+
+    if (hCryptProv == 0)
+    {
+        if (win32_urandom_init(raise) == -1)
+            return -1;
+    }
+
+    while (size > 0)
+    {
+        chunk = size > INT_MAX ? INT_MAX : size;
+        if (!pCryptGenRandom(hCryptProv, chunk, buffer))
+        {
+            /* CryptGenRandom() failed */
+            if (raise)
+                PyErr_SetFromWindowsErr(0);
+            else
+                Py_FatalError("Failed to initialized the randomized hash "
+                        "secret using CryptoGen)");
+            return -1;
+        }
+        buffer += chunk;
+        size -= chunk;
+    }
+    return 0;
+}
+#endif /* MS_WINDOWS */
+
+
+#ifdef __VMS
+/* Use openssl random routine */
+#include <openssl/rand.h>
+static int
+vms_urandom(unsigned char *buffer, Py_ssize_t size, int raise)
+{
+    if (RAND_pseudo_bytes(buffer, size) < 0) {
+        if (raise) {
+            PyErr_Format(PyExc_ValueError,
+                         "RAND_pseudo_bytes");
+        } else {
+            Py_FatalError("Failed to initialize the randomized hash "
+                          "secret using RAND_pseudo_bytes");
+        }
+        return -1;
+    }
+    return 0;
+}
+#endif /* __VMS */
+
+
+#if !defined(MS_WINDOWS) && !defined(__VMS)
+
+/* Read size bytes from /dev/urandom into buffer.
+   Call Py_FatalError() on error. */
+static void
+dev_urandom_noraise(char *buffer, Py_ssize_t size)
+{
+    int fd;
+    Py_ssize_t n;
+
+    assert (0 < size);
+
+    fd = open("/dev/urandom", O_RDONLY);
+    if (fd < 0)
+        Py_FatalError("Failed to open /dev/urandom");
+
+    while (0 < size)
+    {
+        do {
+            n = read(fd, buffer, (size_t)size);
+        } while (n < 0 && errno == EINTR);
+        if (n <= 0)
+        {
+            /* stop on error or if read(size) returned 0 */
+            Py_FatalError("Failed to read bytes from /dev/urandom");
+            break;
+        }
+        buffer += n;
+        size -= (Py_ssize_t)n;
+    }
+    close(fd);
+}
+
+/* Read size bytes from /dev/urandom into buffer.
+   Return 0 on success, raise an exception and return -1 on error. */
+static int
+dev_urandom_python(char *buffer, Py_ssize_t size)
+{
+    int fd;
+    Py_ssize_t n;
+
+    if (size <= 0)
+        return 0;
+
+    Py_BEGIN_ALLOW_THREADS
+    fd = open("/dev/urandom", O_RDONLY);
+    Py_END_ALLOW_THREADS
+    if (fd < 0)
+    {
+        PyErr_SetFromErrnoWithFilename(PyExc_OSError, "/dev/urandom");
+        return -1;
+    }
+
+    Py_BEGIN_ALLOW_THREADS
+    do {
+        do {
+            n = read(fd, buffer, (size_t)size);
+        } while (n < 0 && errno == EINTR);
+        if (n <= 0)
+            break;
+        buffer += n;
+        size -= (Py_ssize_t)n;
+    } while (0 < size);
+    Py_END_ALLOW_THREADS
+
+    if (n <= 0)
+    {
+        /* stop on error or if read(size) returned 0 */
+        if (n < 0)
+            PyErr_SetFromErrno(PyExc_OSError);
+        else
+            PyErr_Format(PyExc_RuntimeError,
+                         "Failed to read %zi bytes from /dev/urandom",
+                         size);
+        close(fd);
+        return -1;
+    }
+    close(fd);
+    return 0;
+}
+#endif /* !defined(MS_WINDOWS) && !defined(__VMS) */
+
+/* Fill buffer with pseudo-random bytes generated by a linear congruent
+   generator (LCG):
+
+       x(n+1) = (x(n) * 214013 + 2531011) % 2^32
+
+   Use bits 23..16 of x(n) to generate a byte. */
+static void
+lcg_urandom(unsigned int x0, unsigned char *buffer, size_t size)
+{
+    size_t index;
+    unsigned int x;
+
+    x = x0;
+    for (index=0; index < size; index++) {
+        x *= 214013;
+        x += 2531011;
+        /* modulo 2 ^ (8 * sizeof(int)) */
+        buffer[index] = (x >> 16) & 0xff;
+    }
+}
+
+/* Fill buffer with size pseudo-random bytes, not suitable for cryptographic
+   use, from the operating random number generator (RNG).
+
+   Return 0 on success, raise an exception and return -1 on error. */
+int
+_PyOS_URandom(void *buffer, Py_ssize_t size)
+{
+    if (size < 0) {
+        PyErr_Format(PyExc_ValueError,
+                     "negative argument not allowed");
+        return -1;
+    }
+    if (size == 0)
+        return 0;
+
+#ifdef MS_WINDOWS
+    return win32_urandom((unsigned char *)buffer, size, 1);
+#else
+    return dev_urandom_python((char*)buffer, size);
+#endif
+}
+
+void
+_PyRandom_Init(void)
+{
+    char *env;
+    void *secret = &_Py_HashSecret;
+    Py_ssize_t secret_size = sizeof(_Py_HashSecret);
+
+    if (random_initialized)
+        return;
+    random_initialized = 1;
+
+    /*
+      By default, hash randomization is disabled, and only
+      enabled if PYTHONHASHRANDOMIZATION is set to non-empty
+      or if "-R" is provided at the command line:
+    */
+    if (!Py_HashRandomizationFlag) {
+        /* Disable the randomized hash: */
+        memset(secret, 0, secret_size);
+        return;
+    }
+
+    /*
+      Hash randomization is enabled.  Generate a per-process secret,
+      using PYTHONHASHSEED if provided.
+    */
+
+    env = Py_GETENV("PYTHONHASHSEED");
+    if (env && *env != '\0') {
+        char *endptr = env;
+        unsigned long seed;
+        seed = strtoul(env, &endptr, 10);
+        if (*endptr != '\0'
+            || seed > 4294967295UL
+            || (errno == ERANGE && seed == ULONG_MAX))
+        {
+            Py_FatalError("PYTHONHASHSEED must be an integer "
+                          "in range [0; 4294967295]");
+        }
+        if (seed == 0) {
+            /* disable the randomized hash */
+            memset(secret, 0, secret_size);
+        }
+        else {
+            lcg_urandom(seed, (unsigned char*)secret, secret_size);
+        }
+    }
+    else {
+#ifdef MS_WINDOWS
+        (void)win32_urandom((unsigned char *)secret, secret_size, 0);
+#else /* #ifdef MS_WINDOWS */
+ #ifdef __VMS
+        vms_urandom((unsigned char *)secret, secret_size, 0);
+ #else
+        dev_urandom_noraise((char*)secret, secret_size);
+ #endif
+#endif
+    }
+}
+
diff -r e7706bdaaa0d Python/sysmodule.c
--- a/Python/sysmodule.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Python/sysmodule.c	Sat Feb 11 17:59:37 2012 -0500
@@ -1126,6 +1126,7 @@
     /* {"unbuffered",                   "-u"}, */
     /* {"skip_first",                   "-x"}, */
     {"bytes_warning", "-b"},
+    {"hash_randomization", "-R"},
     {0}
 };
 
@@ -1134,9 +1135,9 @@
     flags__doc__,       /* doc */
     flags_fields,       /* fields */
 #ifdef RISCOS
+    13
+#else
     12
-#else
-    11
 #endif
 };
 
@@ -1169,6 +1170,7 @@
     /* SetFlag(saw_unbuffered_flag); */
     /* SetFlag(skipfirstline); */
     SetFlag(Py_BytesWarningFlag);
+    SetFlag(Py_HashRandomizationFlag);
 #undef SetFlag
 
     if (PyErr_Occurred()) {

From report at bugs.python.org  Sun Feb 12 00:34:42 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 11 Feb 2012 23:34:42 +0000
Subject: [issue13881] Stream encoder for zlib_codec doesn't use the
	incremental encoder
In-Reply-To: <1327606849.1.0.885842099772.issue13881@psf.upfronthosting.co.za>
Message-ID: <1329003282.66.0.201293061388.issue13881@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Andrew, could you possibly write a patch and a test for 3.3?

----------
nosy: +jcea
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13881>
_______________________________________

From report at bugs.python.org  Sun Feb 12 02:37:26 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 12 Feb 2012 01:37:26 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1329001725.2149.10.camel@surprise>
Message-ID: <CAGE7PNJ6aHBz-Ub3RruvkMMQc=sAs8JFMStqmMV-vwexBtRakw@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

Should -R be required to take a parameter specifying "on" or "off" so
that code using a #! line continues to work as specified across the a
change in default behavior when upgrading from 3.2 to 3.3?

#!/usr/bin/python3 -R on
#!/usr/bin/python3 -R off

In 3.3 it would be a good idea to have a command line flag to turn
this off.  Rather than introducing a new flag in 3.3 a parameter that
is specific without regards for the default avoids that entirely.

before anyone suggests it: I do *not* think -R should accept a value
to use as the seed.  that is unnecessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Sun Feb 12 03:11:28 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 12 Feb 2012 02:11:28 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1329012688.13.0.62888644637.issue13703@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Comments to be addressed added on the code review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Sun Feb 12 03:44:36 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Feb 2012 02:44:36 +0000
Subject: [issue13996] "What's New in Python" should have initial release date
	on heading
In-Reply-To: <1328994669.43.0.0878472757687.issue13996@psf.upfronthosting.co.za>
Message-ID: <1329014676.08.0.549774333181.issue13996@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I agree that the date of the release would be more useful than the date of the doc build.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13996>
_______________________________________

From report at bugs.python.org  Sun Feb 12 03:50:00 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Feb 2012 02:50:00 +0000
Subject: [issue13991] namespace packages depending on order
In-Reply-To: <1328907203.29.0.677752935093.issue13991@psf.upfronthosting.co.za>
Message-ID: <1329015000.96.0.562486009027.issue13991@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> There is nothing binary in the archive
The archive is a binary file.  We tend to dislike those because we need to download and process them instead of just reading them in a browser tab, and in some cases (Windows .exe files) there are also security reasons.  It?s not a big deal anyway, just a small matter of convention.

> I use the standard pkg_resources way to do things:
setuptools is not in the standard library nor does it implements PEPs, so it?s at most a de facto standard.  More importantly, it is not developed by python-dev; could you report the bug to bugs.python.org/setuptools and bitbucket.org/tarek/distribute ?  If they find that the bug actually comes from distutils, then we?ll reopen this bug.  Thanks!

----------
assignee: tarek -> eric.araujo
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13991>
_______________________________________

From report at bugs.python.org  Sun Feb 12 04:02:17 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Feb 2012 03:02:17 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1329015737.34.0.310927218918.issue10287@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hynek, the patch doesn't apply properly here. Are you soon it's been generated against an up-to-date working copy?

Also, I think the logic is wrong: the capabilities should *always* be queried after auth, even if they are already known. That's because they can change after auth is successful.

See RFC 4643: ?Other capabilities returned in response to a CAPABILITIES
   command received after authentication MAY be different from those
   returned before authentication.  For example, an NNTP server may not
   want to advertise support for a specific extension unless a client
   has been authenticated.?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10287>
_______________________________________

From report at bugs.python.org  Sun Feb 12 04:02:44 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Feb 2012 03:02:44 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1329015764.88.0.400342731579.issue10287@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(oh, and better if it can come with a test)

----------
type:  -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10287>
_______________________________________

From report at bugs.python.org  Sun Feb 12 04:03:01 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Feb 2012 03:03:01 +0000
Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of
	customize_compiler
In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za>
Message-ID: <1329015781.69.0.513202562075.issue13994@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FWIW I approve of the patch.

Quoting Ned:
> this isn't the first time we've been burned by the after effects of the 2.7 Distutils
> revert.  I really think we should go through and make sure there aren't other unnecessary
> discrepancies between the current state of 2.7.x and 3.2.x/default.
The revert indiscriminately reverted new features and bug and doc fixes, some of which have been fixed again later when rediscovered.  I never did a systematic review but I could.  One of the most painful difference between 2.7 and 3.x is the use of urllib vs. httplib in the register and upload commands, which does not let me port patches easily.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13994>
_______________________________________

From report at bugs.python.org  Sun Feb 12 04:08:44 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Feb 2012 03:08:44 +0000
Subject: [issue13953] Get rid of doctests in packaging.tests.test_version
In-Reply-To: <1328554740.27.0.167211242761.issue13953@psf.upfronthosting.co.za>
Message-ID: <1329016124.92.0.897207214818.issue13953@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Isn't that what the previous code (doctest code) did?
I don?t understand, could you rephrase?

> I thought that the code should be ported as far backwards as possible and that's why I
> used the plain assertEqual (I don't know exactly in with version the other assert
> methods were introduced. Unittest2?)
Michael Foord took over maintenance of unittest and released a bunch of improvements for 2.7 and 3.1, then further improvements in 3.2.  unittest2 is a standalone release of this improved unittest (not sure if it?s like 3.1 or 3.2).  For packaging in the 3.3 stdlib we have all new methods, and for distutils2 we use unittest2 which has them too and works with 2.4, so we have compat.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13953>
_______________________________________

From report at bugs.python.org  Sun Feb 12 04:44:20 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Feb 2012 03:44:20 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329018260.6.0.0108658882516.issue13988@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>> I think that 3.2 and 2.7 should get a doc note about cET
> What doc note?

I was referring to one of the points raised in the email thread: the docs don?t tell people that they can import a faster ET version, cET.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sun Feb 12 04:44:45 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Feb 2012 03:44:45 +0000
Subject: [issue13950] rm commented-out code
In-Reply-To: <1328517147.42.0.318507953737.issue13950@psf.upfronthosting.co.za>
Message-ID: <1329018285.27.0.993851828397.issue13950@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Done as part of my general cleanup of test_version.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Get rid of doctests in packaging.tests.test_version

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13950>
_______________________________________

From report at bugs.python.org  Sun Feb 12 04:44:55 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 12 Feb 2012 03:44:55 +0000
Subject: [issue13193] packaging.tests.test_manifest and
	distutils.tests.test_filelist failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <E1RwQMw-0004k3-8P@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c566a3447ba1 by ?ric Araujo in branch '2.7':
Fix distutils.filelist.FileList under Windows (#13193).
http://hg.python.org/cpython/rev/c566a3447ba1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Sun Feb 12 04:46:24 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Feb 2012 03:46:24 +0000
Subject: [issue13949] rm needless use of pass statement
In-Reply-To: <1328517020.67.0.388528127173.issue13949@psf.upfronthosting.co.za>
Message-ID: <1329018384.12.0.256978564208.issue13949@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Will commit this together with the test_version cleanup.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Get rid of doctests in packaging.tests.test_version

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13949>
_______________________________________

From report at bugs.python.org  Sun Feb 12 04:49:58 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 12 Feb 2012 03:49:58 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329018598.62.0.980941865874.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

>> I was referring to one of the points raised in the email thread: the docs don?t tell people that they can import a faster ET version, cET.

Well, they *do*, but very modestly :-) I agree that should be improved and emphasized a bit, perhaps even mentioning (at least in the 3.2 doc) that in 3.3 it's going to be done by default. Is that accepted practice? I mean to mention in docs of 3.x some upcoming change in version 3.x+1 ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sun Feb 12 04:51:14 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 12 Feb 2012 03:51:14 +0000
Subject: [issue13996] "What's New in Python" should have initial release date
	on heading
In-Reply-To: <1328994669.43.0.0878472757687.issue13996@psf.upfronthosting.co.za>
Message-ID: <1329018674.55.0.270436776969.issue13996@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I think this is the wrong place to show release dates (a subject that would be further confused by having multiple point releases).

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13996>
_______________________________________

From report at bugs.python.org  Sun Feb 12 05:01:19 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Feb 2012 04:01:19 +0000
Subject: [issue13948] rm needless use of set function
In-Reply-To: <1328516888.02.0.726524948471.issue13948@psf.upfronthosting.co.za>
Message-ID: <1329019279.3.0.374550407839.issue13948@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Done as part of my general test_version cleanup.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Get rid of doctests in packaging.tests.test_version

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13948>
_______________________________________

From report at bugs.python.org  Sun Feb 12 05:12:24 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 12 Feb 2012 04:12:24 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329019944.02.0.0289634312774.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Florent,

The issue13988_fold_cET_behind_ET.diff patch looks good to me. Unless there are objections from others, you can commit! Even the tests became simpler now, that's awesome ;-)

Now, what's left for this issue:

1. Update the documentation
2. Update "what's new"
3. Discuss and possibly implement the deprecation of cElementTree

I'll send a patch for 1 & 2 soon. What about 3?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sun Feb 12 05:20:41 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Feb 2012 04:20:41 +0000
Subject: [issue12297] Clarifications to atexit.register and unregister doc
In-Reply-To: <1307634551.41.0.658857259056.issue12297@psf.upfronthosting.co.za>
Message-ID: <1329020441.01.0.764683181111.issue12297@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I assume the patch is an improved description of reality. The old 'without binding the original name to ``None``.' is confusing to me in that context, so good riddance. However, I am not familiar with atexit or how it is intended to work. If you are not sure either, you might ask on pydev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12297>
_______________________________________

From report at bugs.python.org  Sun Feb 12 05:21:18 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 12 Feb 2012 04:21:18 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329020478.14.0.673849682541.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Attaching a patch for Doc/library/xml.etree.elementtree.rst and Misc/NEWS.

The doc notice is modeled after a similar notice in the doc of 'pickle'. Note that I've also removed the mention that effbot's site is the home of the development version of the library, since it's no longer formally true.

----------
Added file: http://bugs.python.org/file24492/issue13988_doc_news.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sun Feb 12 05:22:42 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Feb 2012 04:22:42 +0000
Subject: [issue13946] readline completer could return an iterable
In-Reply-To: <1328471281.77.0.152059916947.issue13946@psf.upfronthosting.co.za>
Message-ID: <1329020562.27.0.636633095478.issue13946@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13946>
_______________________________________

From report at bugs.python.org  Sun Feb 12 05:26:27 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 12 Feb 2012 04:26:27 +0000
Subject: [issue13193] packaging.tests.test_manifest and
	distutils.tests.test_filelist failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <E1RwR17-0007OM-MI@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 90b30d62caf2 by ?ric Araujo in branch '3.2':
Fix distutils.filelist.FileList under Windows (#13193).
http://hg.python.org/cpython/rev/90b30d62caf2

New changeset 68347f8430ec by ?ric Araujo in branch 'default':
Merge fixes for #13193 and FAQ from 3.2
http://hg.python.org/cpython/rev/68347f8430ec

New changeset f06effb61cde by ?ric Araujo in branch 'default':
Port the fix for #13193 to packaging
http://hg.python.org/cpython/rev/f06effb61cde

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Sun Feb 12 05:29:11 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Feb 2012 04:29:11 +0000
Subject: [issue13193] packaging.tests.test_manifest and
	distutils.tests.test_filelist failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1329020951.69.0.273608774502.issue13193@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Reverted the liberal fix and replaced it with Vinay?s in time for the next bugfix releases.  Will watch buildbot and close the report.  Thanks to all who helped.

----------
resolution:  -> fixed
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Sun Feb 12 05:31:51 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Feb 2012 04:31:51 +0000
Subject: [issue13952] mimetypes doesn't recognize .csv
In-Reply-To: <1328550236.31.0.476108753678.issue13952@psf.upfronthosting.co.za>
Message-ID: <1329021111.22.0.317223383043.issue13952@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

One solution would be to update our mimetypes file just before a new version, and then leave it until the next, just as we update unicodedata to current unicode and then leave it alone for bugfix releases. Rather than the entire IANA file, which has a lot of useless stuff, we might update from the most recent *nix files (assuming that they have less than 'everything').

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13952>
_______________________________________

From report at bugs.python.org  Sun Feb 12 05:33:07 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Feb 2012 04:33:07 +0000
Subject: [issue13997] Add open_ascii() builtin
Message-ID: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

(This proposes a new builtin, so may need to become a PEP)

A common programming task is "I want to process this text file, I know it's in an ASCII compatible encoding, I don't know which one specifically, but I'm only manipulating the ASCII parts so it doesn't matter".

In Python 2, you handle that task by doing:

    f = open(fname)

The non-ASCII parts are then carried along as 8-bit bytes and reproduced faithfully when written back out.

In Python 3, you handle it by doing:

    f = open(fname, encoding="ascii", errors="surrogateescape")

The non-ASCII parts are then carried along as code points in the Unicode Private Use Area and reproduced faithfully when written back out.

It would be significantly more friendly to beginners (and migrants from Python 2) if the following shorthand spelling was available out of the box:

    f = open_ascii(fname)

----------
messages: 153164
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Add open_ascii() builtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sun Feb 12 05:35:56 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 12 Feb 2012 04:35:56 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329021356.15.0.525441691188.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Florent,

Just something minor I noticed in the new cElementTree.py:

  # Wrapper module for _elementtree

  from xml.etree.ElementTree import *
  # Not in __all__
  from xml.etree.ElementTree import ElementPath, XMLID, register_namespace

The "wrapper" comment should be removed, and possibly replaced with "This module exists for backwards compatibility with releases earlier than 3.3; Please import xml.etree.ElementTree directly"

Also, regarding the names not in __all__. Any good reason for them not to be? Seems like an omission to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sun Feb 12 05:36:47 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Feb 2012 04:36:47 +0000
Subject: [issue13963] dev guide has no mention of mechanics of patch review
In-Reply-To: <1328631878.8.0.85188160352.issue13963@psf.upfronthosting.co.za>
Message-ID: <1329021407.61.0.129308309119.issue13963@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

At one time, reviews (or the fact of a review) were posted back here automatically (or perhaps it is an option?) just like push messages. But I am not much familiar with the process either.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13963>
_______________________________________

From report at bugs.python.org  Sun Feb 12 05:37:04 2012
From: report at bugs.python.org (Chris Rebert)
Date: Sun, 12 Feb 2012 04:37:04 +0000
Subject: [issue13997] Add open_ascii() builtin
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329021424.4.0.229722436324.issue13997@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sun Feb 12 05:38:49 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 12 Feb 2012 04:38:49 +0000
Subject: [issue13997] Add open_ascii() builtin
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329021529.87.0.670004791947.issue13997@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Would not adding a new keyword arg to open() be less intrusive and more consistent?

I.e. open(fname, asciionly=True) or something similar.

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sun Feb 12 05:42:53 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Feb 2012 04:42:53 +0000
Subject: [issue13198] Remove duplicate definition of write_record_file
In-Reply-To: <1318857154.54.0.641953188635.issue13198@psf.upfronthosting.co.za>
Message-ID: <1329021773.62.0.0720412851244.issue13198@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file23666/remove-duplicate-write_record_file.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13198>
_______________________________________

From report at bugs.python.org  Sun Feb 12 05:43:58 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Feb 2012 04:43:58 +0000
Subject: [issue13972] set and frozenset constructors don't accept multiple
	iterables
In-Reply-To: <1328775388.29.0.217148871947.issue13972@psf.upfronthosting.co.za>
Message-ID: <1329021838.61.0.451851650449.issue13972@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I believe s = set(); s.update(s1, s2, s3, ...) 
a) does what is requested;
b) is the proper spelling, as the request *is* for a union of input collections.
So I recommend closing.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13972>
_______________________________________

From report at bugs.python.org  Sun Feb 12 05:48:21 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Feb 2012 04:48:21 +0000
Subject: [issue13997] Add open_ascii() builtin
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329022101.64.0.792336173864.issue13997@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, what happened to "not every one-liner should be a builtin function"?

> I'm only manipulating the ASCII parts

How can you be sure about that?

> It would be significantly more friendly to beginners (and migrants from 
> Python 2)

To the point that many of them would stop thinking about the problem, and start producing unicode-incompatible code.
The idea that it may be presented as a porting recipe is IMO a good reason to oppose introducing this new function.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sun Feb 12 05:51:46 2012
From: report at bugs.python.org (Chris Rebert)
Date: Sun, 12 Feb 2012 04:51:46 +0000
Subject: [issue13997] Add open_ascii() builtin
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329022306.54.0.645370828942.issue13997@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

@Bendersky:

Unlike open()'s other arguments, that one wouldn't be orthogonal though. It would be possible to write e.g.:

f = open(fname, encoding="big5", errors="replace", ascii_only=True)

which seems disturbing, IMO. It would be nicer to rule out such impossible combinations categorically.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sun Feb 12 05:51:59 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Feb 2012 04:51:59 +0000
Subject: [issue13997] Add open_ascii() builtin
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329022319.4.0.394273362035.issue13997@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

No point to adding a new keyword arg - if people are going to do something like that, they may as well learn to use "errors" and "encoding" properly.

Adding open_ascii() would be an acknowledgement that "basically ASCII, but maybe with a few other bytes that just need to round-trip correctly" is a common enough use case to special case (in particular, it's convenient to have algorithms than can operate on both utf-8 and all 8-bit extended ASCII variants, including latin-1).

The downside to using surrogateescape is that if you ever *do* feed it a file in a non-ASCII compatible encoding and then perform ASCII-based manipulations, you'll get mojibake instead of an early UnicodeDecodeError. (i.e. exactly the same problem this kind of thing can cause in Python 2)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sun Feb 12 05:53:33 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Feb 2012 04:53:33 +0000
Subject: [issue13986] ValueError: cannot convert float NaN to integer
In-Reply-To: <1328874238.47.0.897260032056.issue13986@psf.upfronthosting.co.za>
Message-ID: <1329022413.49.0.674677435229.issue13986@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If I believe the error message, os.fstat(f.fileno()).st_mtime is returning a NaN, which would be a bug in our function or your system. Since os.fstat should be a thin wrapper over the system call, I would lean to the latter. I do not know if writing to sys.stderr would work during compilation, but if it does, try inserting a statement to grab the value and print it before the long conversion.

Is this error 'deterministic' in being raised consistently?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13986>
_______________________________________

From report at bugs.python.org  Sun Feb 12 06:00:40 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Feb 2012 05:00:40 +0000
Subject: [issue13193] packaging.tests.test_manifest and
	distutils.tests.test_filelist failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1329022840.01.0.889140543485.issue13193@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Buildbots exist to crush joy: http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%202.7/builds/1285/steps/test/logs/stdio/text

Possible ways forward:
- One of you gentlemen with a Windows box and a clear head can try to find a correct fix for the bug
- If Benjamin wants to release this week-end, the attached patch reverts to the buggy 2.7.2 code and skips the failing test on Windows (more skips may be needed)
- I?ll be on the Internet on Monday afternoon (Europe).

----------
resolution: fixed -> 
stage: committed/rejected -> needs patch
Added file: http://bugs.python.org/file24493/revert-filelist-fix-2.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Sun Feb 12 06:04:26 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Feb 2012 05:04:26 +0000
Subject: [issue13193] packaging.tests.test_manifest and
	distutils.tests.test_filelist failures
In-Reply-To: <1329022840.01.0.889140543485.issue13193@psf.upfronthosting.co.za>
Message-ID: <1329022878.3456.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Possible ways forward:
> - One of you gentlemen with a Windows box and a clear head can try to
> find a correct fix for the bug

This error shows that distutils's own test suite relies on being able to
put both kind of path separators in a manifest, so my fix was probably
the correct one ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Sun Feb 12 06:11:53 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Feb 2012 05:11:53 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329023513.16.0.724971090663.issue13988@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> perhaps even mentioning (at least in the 3.2 doc) that in 3.3 it's going
> to be done by default. Is that accepted practice?
I don?t think we ever do that, and it would be confusing.

-1 to mentioning _elementtree, an implementation detail.  What I was talking about is cElementTree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sun Feb 12 06:12:58 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Feb 2012 05:12:58 +0000
Subject: [issue12297] Clarifications to atexit.register and unregister doc
In-Reply-To: <1307634551.41.0.658857259056.issue12297@psf.upfronthosting.co.za>
Message-ID: <1329023578.35.0.181482419131.issue12297@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I wrote the patch after testing in a shell, so I?m confident it describes reality; I was more asking a wording/phrasing review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12297>
_______________________________________

From report at bugs.python.org  Sun Feb 12 06:22:39 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Feb 2012 05:22:39 +0000
Subject: [issue13193] packaging.tests.test_manifest and
	distutils.tests.test_filelist failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1329024159.51.0.0265505817247.issue13193@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?d say there is a bug in the tests then.  Remember that they were added recently and only tested on posix, so they?re not authoritative.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Sun Feb 12 06:27:45 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Feb 2012 05:27:45 +0000
Subject: [issue13193] packaging.tests.test_manifest and
	distutils.tests.test_filelist failures
In-Reply-To: <1329024159.51.0.0265505817247.issue13193@psf.upfronthosting.co.za>
Message-ID: <1329024286.3456.11.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I?d say there is a bug in the tests then.  Remember that they were
> added recently and only tested on posix, so they?re not authoritative.

How about people who have similar "bugs" in their code then?
I think you're trying to be pure instead of practical.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Sun Feb 12 06:32:08 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Feb 2012 05:32:08 +0000
Subject: [issue13997] Add open_ascii() builtin
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329024728.19.0.974961899202.issue13997@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

IMO it is a fact that the characters used by human languages are stored as bytes by computers, so a programmer needs to know the basics about text handling and encoding.  I don?t like the idea of a built-in function helping people to put their hands on their ears and sing ?la-la-la everything is ASCII?.  I know that it is hard to find oneself confronted with a UnicodeDecodeError, I?ve been there, but then I learned.  My hope is that good explanations in the FAQ, howto and library ref (with good PageRank, so that people googling error messages find us) can help people understand how to work with text.

That said, I?m going to re-read Armin?s post about Python 3 and Nick?s reply to it to understand your position better.

can?t-put-my-damn-name-in-so-many-websites-in-2012-grumble?ly yours

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sun Feb 12 06:46:07 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 12 Feb 2012 05:46:07 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329025567.77.0.52525770444.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

?ric,

Could you please open a new issue (with a dependency on this one) and explain there clearly what you want/mean?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sun Feb 12 06:47:19 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Feb 2012 05:47:19 +0000
Subject: [issue11751] Increase distutils.filelist / packaging.manifest test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1329025639.28.0.893480155791.issue11751@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FYI the tests revealed a bug in the code on Windows: #13193

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11751>
_______________________________________

From report at bugs.python.org  Sun Feb 12 06:55:42 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Feb 2012 05:55:42 +0000
Subject: [issue13997] Add open_ascii() builtin
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329026142.73.0.733005146129.issue13997@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Pondering it further (and reading subsequent comments here and in the thread), I agree an open_ascii() builtin would be a step backwards, not forwards.

So, morphing this issue into a documentation one to work out:
- the bare minimum we think Python 3 users should be learning about Unicode
- deciding where to document that (with a reference to the Unicode HOWTO for anyone that wants to know more)

Some ideas specifically in the context of text files (for readers already familiar with the basic concept of text encodings):

1. The world is moving towards standardising on UTF-8 as the binary encoding used to store text files. However, we're a long way from living in that world right now. Other encodings (many, but far from all, ASCII compatible) will be encountered quite often, either as the default encoding on a particular platform, or as the encoding of a particular text file. Dealing with these correctly requires additional work.

2. To maximise the chance of correct local interoperability, Python 3's default choice of encoding is actually taken from the underlying platform rather than being forced to UTF-8. While it is becoming more and more common for platforms to set their preferred encoding to UTF-8, this is not yet universal (notably, Windows still does not use UTF-8 as the default encoding for text files in order to preserve compatibility with various Unicode-unaware legacy applications).

To handle this correctly in cross-platform applications and libraries, it is often necessary to explicitly pass "encoding='utf-8'" when opening a UTF-8 encoded text file.

The default encoding on a given platform can be checked by running "import locale; locale.getpreferredencoding()" at the interactive prompt.

3. Currently, it is still fairly common to encounter text files that are known to be stored in an ASCII-compatible text encoding without knowing precisely *which* encoding is used. The Python 2 text model allowed such files to be processed naively simply by assuming they were in an ASCII-compatible encoding and passing any non-ASCII characters faithfully through to the result. This permissive behaviour can be requested explicitly in Python 3 by passing "encoding='ascii'" and "errors='surrogateescape'" when opening a text file.

This approach parallels the behaviour of Python 2 and works correctly so long as it is fed data solely in ASCII compatible encodings (such as UTF-8 and latin-1). Behaviour when fed data that uses other encodings is unpredictable - common symptoms include Unicode encoding and decoding errors at unexpected points in a program, as well as silent corruption of the output text.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sun Feb 12 06:56:22 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Feb 2012 05:56:22 +0000
Subject: [issue13997] Clearly explain the bare minimum Python 3 users should
	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329026182.14.0.219063459906.issue13997@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
title: Add open_ascii() builtin -> Clearly explain the bare minimum Python 3 users should know about Unicode
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sun Feb 12 07:00:47 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 12 Feb 2012 06:00:47 +0000
Subject: [issue13997] Clearly explain the bare minimum Python 3 users should
	know about Unicode
In-Reply-To: <1329026182.16.0.134541940719.issue13997@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda8s4pBc56ihFM_w=zCxoUoSdr633=CKeTLRurm1k79wDA@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

If the concept is accepted. I see no better place for this than the
Unicode HOWTO. If it's too long, then a TL;DR; section should be added
in the beginning detailing "the bare minimum". No need to scatter such
information in bits and pieces around the documentation. That's what
the Unicode HOWTO is for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sun Feb 12 07:09:05 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 12 Feb 2012 06:09:05 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1329026945.3.0.388674759908.issue13609@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

test_stty_match() should be skipped also when os.isatty(sys.__stdin__.fileno()) is False.
This test fails when test suite is run by Portage (Gentoo package manager), which somehow sets null input.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Sun Feb 12 07:41:39 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sun, 12 Feb 2012 06:41:39 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1329026945.3.0.388674759908.issue13609@psf.upfronthosting.co.za>
Message-ID: <4F375E56.4000402@in.waw.pl>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

Hi,

looking at the tests, the test should be skipped with 'stty invocation 
failed'. Does something different happen? Can you post the output from 
the tests?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Sun Feb 12 08:07:15 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Feb 2012 07:07:15 +0000
Subject: [issue13198] Remove duplicate definition of write_record_file
In-Reply-To: <1318857154.54.0.641953188635.issue13198@psf.upfronthosting.co.za>
Message-ID: <1329030435.4.0.119901969971.issue13198@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch attached.  Adding people from #13175 for review/testing on Windows.

----------
keywords: +needs review
nosy: +pmoore, tarek, vinay.sajip
stage: test needed -> patch review
Added file: http://bugs.python.org/file24494/remove-duplicate-write_record_file.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13198>
_______________________________________

From report at bugs.python.org  Sun Feb 12 09:17:48 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 12 Feb 2012 08:17:48 +0000
Subject: [issue13997] Clearly explain the bare minimum Python 3 users should
	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329034668.71.0.603268456338.issue13997@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Unicode
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sun Feb 12 09:42:54 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Feb 2012 08:42:54 +0000
Subject: [issue4966] Improving Lib Doc Sequence Types Section
In-Reply-To: <1232149418.64.0.0450574767427.issue4966@psf.upfronthosting.co.za>
Message-ID: <1329036174.67.0.923124805625.issue4966@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Just noting that this has slipped a bit down my Python to-do list (there are other things I want to focus on before the first 3.3 alpha).

I'll get back to it at some point, but if someone want to take my branch and run with it in the meantime, please feel free.

----------
assignee: ncoghlan -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4966>
_______________________________________

From report at bugs.python.org  Sun Feb 12 09:51:47 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Feb 2012 08:51:47 +0000
Subject: [issue12627] Implement PEP 394: The "python" Command on Unix-Like
	Systems
In-Reply-To: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>
Message-ID: <1329036707.1.0.428811642954.issue12627@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12627>
_______________________________________

From report at bugs.python.org  Sun Feb 12 09:54:43 2012
From: report at bugs.python.org (Devin Jeanpierre)
Date: Sun, 12 Feb 2012 08:54:43 +0000
Subject: [issue13998] Lookbehind assertions go behind the start position for
	the match
Message-ID: <1329036883.7.0.662970564139.issue13998@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre <jeanpierreda at gmail.com>:

compiled regex objects' match method offers an optional "pos" parameter described to be roughly equivalent to slicing except for how it treats the "^" operation. See http://docs.python.org/library/re.html#re.RegexObject.search

However, the behavior of lookbehind assertions also differs:

>>> re.compile("(?<=a)b").match("ab", 1)
<_sre.SRE_Match object at 0x...>
>>> re.compile("(?<=a)b").match("ab"[1:])
>>>

This alone might be a documentation bug, but the behavior is also inconsistent with the behavior of lookahead assertions, which do *not* look past the endpos:

>>> re.compile("a(?=b)").match("ab", 0, 1)
>>> re.compile("a(?=b)").match("ab")
<_sre.SRE_Match object at 0x...>
>>>

----------
components: Regular Expressions
messages: 153188
nosy: Devin Jeanpierre, ezio.melotti
priority: normal
severity: normal
status: open
title: Lookbehind assertions go behind the start position for the match
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13998>
_______________________________________

From report at bugs.python.org  Sun Feb 12 09:58:47 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Feb 2012 08:58:47 +0000
Subject: [issue13997] Clearly explain the bare minimum Python 3 users should
	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329037127.54.0.928948885614.issue13997@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> A common programming task is "I want to process this text file,
> I know it's in an ASCII compatible encoding, I don't know which
> one specifically, but I'm only manipulating the ASCII parts
> so it doesn't matter".

Can you give more detail about this use case? Why would you ignore non-ASCII characters?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sun Feb 12 10:19:38 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Feb 2012 09:19:38 +0000
Subject: [issue13997] Clearly explain the bare minimum Python 3 users should
	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329038378.58.0.474374234993.issue13997@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Usually because the file may contain certain ASCII markers (or you're inserting such markers), but beyond that, you only care that it's in a consistent ASCII compatible encoding.

Parsing log files from sources that aren't set up correctly often falls into this category - you know the markers are ASCII, but the actual message contents may not be properly encoded. (e.g. they use a locale dependent encoding, but not all the log files are from the same machine and not all machines have their locale set up properly). (although errors="replace" can be a better option for such "read-only" use cases).

A use case where you really do need "errors='surrogateescape'" is when you're reformatting a log file and you want to preserve the encoding for the messages while manipulating the pure ASCII timestamps and message headers. In that case, surrogateescape is the right answer, because you can manipulate the ASCII bits freely while preserving the log message contents when you write the reformatted files back out. The reformatting script offers an API that says "put any ASCII compatible encoding in, and you'll get that same encoding back out".

You'll get weird behaviour (i.e. as you do in Python 2) if the assumption of an ASCII compatible encoding is ever violated, but that would be equally true if the script tried to process things at the raw bytes level.

The assumption of an ASCII compatibile text encoding is a useful one a lot of the time. The problem with Python 2 is it makes that assumption implicitly, and makes it almost impossible to disable it. Python 3, on the other hand, assumes very little by default (basically what it returns from sys.getfilesystemencoding() and locale.getpreferredencoding()), this requiring that the programmer know how to state their assumptions explicitly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sun Feb 12 10:55:49 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Feb 2012 09:55:49 +0000
Subject: [issue13997] Clearly explain the bare minimum Python 3 users should
	know about Unicode
In-Reply-To: <1329038378.58.0.474374234993.issue13997@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaUJLrgJXj6nfkK=ajqx-8fLk2uRFLEZyFsjmXG+W1Pmw@mail.gmail.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Why do you use Unicode with the ugly surrogateescape error handler in
this case? Bytes are just fine for such usecase.

The surrogateescape error handler produces unusual characters in range
U+DC80-U+DCFF which cannot be printed to a console because sys.stdout
uses the strict error handler, and sys.stderr  uses the
backslashreplace error handler. If I remember correctly, only UTF-7
encoder allow lone surrogate characters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sun Feb 12 11:07:30 2012
From: report at bugs.python.org (Yuval Greenfield)
Date: Sun, 12 Feb 2012 10:07:30 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1329041250.78.0.030406481302.issue13968@psf.upfronthosting.co.za>


Yuval Greenfield <ubershmekel at gmail.com> added the comment:

Raymond Hettinger, by simple do you mean a single argument rglob function? Or do you mean you prefer glob doesn't get a new function?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Sun Feb 12 11:08:05 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Sun, 12 Feb 2012 10:08:05 +0000
Subject: [issue13953] Get rid of doctests in packaging.tests.test_version
In-Reply-To: <1329016124.92.0.897207214818.issue13953@psf.upfronthosting.co.za>
Message-ID: <4F378FD4.1070403@email.de>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

Does a "doc test" test the output literally? (I've just always used 
unittest)

Ok, thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13953>
_______________________________________

From report at bugs.python.org  Sun Feb 12 11:19:22 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 12 Feb 2012 10:19:22 +0000
Subject: [issue13963] dev guide has no mention of mechanics of patch review
In-Reply-To: <1328631878.8.0.85188160352.issue13963@psf.upfronthosting.co.za>
Message-ID: <1329041962.75.0.642181418638.issue13963@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

AFAIK, all interested parties are supposed to automatically be sent email
notifications whenever anyone posts an update on the review. However,
I've run into a bug <http://psf.upfronthosting.co.za/roundup/meta/issue402>
that seems to be preventing this from working for me.

> * Do all patches go into this review site, or do I have to do something extra to get them to land there?

It should happen automatically, but only if the patch applies cleanly to
the head of the default branch.

> * I have patches for both 2.6 and 3.1 - are they kept separate, or do they affect each other's "delta from patch set"?

If the patch applies cleanly to default (unlikely), I imagine things
could get messy. Most of the time, though, they'll be ignored altogether.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13963>
_______________________________________

From report at bugs.python.org  Sun Feb 12 11:37:04 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 12 Feb 2012 10:37:04 +0000
Subject: [issue13997] Clearly explain the bare minimum Python 3 users should
	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329043024.19.0.0993924885493.issue13997@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sun Feb 12 11:58:32 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 12 Feb 2012 10:58:32 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1329044312.95.0.664267544105.issue10287@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

Sure, I wanted to add tests as soon as I know that the flow is correct (which it isn't :)).

So essentially we want always

CAPABILITIES
LOGIN
CAPABILITIES

?

That's rather simple to achieve. The tests are going to be the harder part. ;)

Re the patch: I tried to generate it using SourceTree but probably did something wrong ? will use hg next time again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10287>
_______________________________________

From report at bugs.python.org  Sun Feb 12 12:05:11 2012
From: report at bugs.python.org (Aaron Staley)
Date: Sun, 12 Feb 2012 11:05:11 +0000
Subject: [issue13992] Segfault in PyTrash_destroy_chain
In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za>
Message-ID: <1329044711.89.0.393446996799.issue13992@psf.upfronthosting.co.za>


Aaron Staley <usaar33 at gmail.com> added the comment:

Active extension modules are MySQL-python, numpy, and crypto.

Here is the output from the non-optimized debug build. Slightly different trace, but still some sort of deallocator crashing AFAIK:


#0  0x000000000046247c in _Py_ForgetReference (op=
    <Channel(origin_addr=None, in_window_size=65536, in_window_threshold=6553, lock=<thread.lock at remote 0x571bf90>, _pipe=None, eof_received=0, in_max_packet_size=34816, out_buffer_cv=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x571bf90>, acquire=<built-in method acquire of thread.lock object at remote 0x571bf90>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x571bf90>) at remote 0x593d3e0>, event=<_Event(_Verbose__verbose=False, _Event__flag=True, _Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x59138b0>, acquire=<built-in method acquire of thread.lock object at remote 0x59138b0>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x59138b0>) at remote 0x5a333e0>) at remote 0x593ded0>, transport=<Transport(_Thread__ident=140009885591296, host_key_type='ssh-rsa', _channels=<ChannelMap(_lock=<thread.lock at remote 0x5928f90>, _map=<WeakValueDictionary(_re...(truncated)) at Objects/object.c:2220
#1  0x00000000004624ed in _Py_Dealloc (op=
    <Channel(origin_addr=None, in_window_size=65536, in_window_threshold=6553, lock=<thread.lock at remote 0x571bf90>, _pipe=None, eof_received=0, in_max_packet_size=34816, out_buffer_cv=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x571bf90>, acquire=<built-in method acquire of thread.lock object at remote 0x571bf90>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x571bf90>) at remote 0x593d3e0>, event=<_Event(_Verbose__verbose=False, _Event__flag=True, _Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x59138b0>, acquire=<built-in method acquire of thread.lock object at remote 0x59138b0>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x59138b0>) at remote 0x5a333e0>) at remote 0x593ded0>, transport=<Transport(_Thread__ident=140009885591296, host_key_type='ssh-rsa', _channels=<ChannelMap(_lock=<thread.lock at remote 0x5928f90>, _map=<WeakValueDictionary(_re...(truncated)) at Objects/object.c:2240
#2  0x0000000000442244 in list_dealloc (op=0x66d7ab0) at Objects/listobject.c:309
#3  0x00000000004624fa in _Py_Dealloc (op=
    [<Channel(origin_addr=None, in_window_size=65536, in_window_threshold=6553, lock=<thread.lock at remote 0x571bf90>, _pipe=None, eof_received=0, in_max_packet_size=34816, out_buffer_cv=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x571bf90>, acquire=<built-in method acquire of thread.lock object at remote 0x571bf90>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x571bf90>) at remote 0x593d3e0>, event=<_Event(_Verbose__verbose=False, _Event__flag=True, _Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x59138b0>, acquire=<built-in method acquire of thread.lock object at remote 0x59138b0>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x59138b0>) at remote 0x5a333e0>) at remote 0x593ded0>, transport=<Transport(_Thread__ident=140009885591296, host_key_type='ssh-rsa', _channels=<ChannelMap(_lock=<thread.lock at remote 0x5928f90>, _map=<WeakValueDictionary(_r...(truncated)) at Objects/object.c:2241
#4  0x0000000000448bc4 in listiter_next (it=0x5d1c530) at Objects/listobject.c:2917
#5  0x00000000004ce425 in PyEval_EvalFrameEx (f=
    Frame 0x7f56a050aea0, for file /usr/lib/python2.7/dist-packages/paramiko/transport.py, line 1586, in run (self=<Transport(_Thread__ident=140009885591296, host_key_type='ssh-rsa', _channels=<ChannelMap(_lock=<thread.lock at remote 0x5928f90>, _map=<WeakValueDictionary(_remove=<function at remote 0x56355a0>, data={}) at remote 0x5939588>) at remote 0x5912bc0>, lock=<thread.lock at remote 0x5928d60>, _Thread__started=<_Event(_Verbose__verbose=False, _Event__flag=True, _Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x521ff40>, acquire=<built-in method acquire of thread.lock object at remote 0x521ff40>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x521ff40>) at remote 0x5223300>) at remote 0x47f56f0>, _channel_counter=22, active=False, _preferred_compression=('none',), server_object=None, kex_engine=None, log_name='paramiko.transport', _x11_handler=None, remote_compression='none', _Thread__initialized=True, server_accepts=[], s...(truncated), throwflag=0) at Python/ceval.c:2497
#6  0x00000000004d41c3 in fast_function (func=<function at remote 0x4716300>, pp_stack=0x7f56977ed400, n=1, na=1, nk=0) at Python/ceval.c:4099
#7  0x00000000004d3ed3 in call_function (pp_stack=0x7f56977ed400, oparg=0) at Python/ceval.c:4034
#8  0x00000000004cec2b in PyEval_EvalFrameEx (f=
    Frame 0x5756c40, for file /root/python2.7-2.7.2/Lib/threading.py, line 552, in __bootstrap_inner (self=<Transport(_Thread__ident=140009885591296, host_key_type='ssh-rsa', _channels=<ChannelMap(_lock=<thread.lock at remote 0x5928f90>, _map=<WeakValueDictionary(_remove=<function at remote 0x56355a0>, data={}) at remote 0x5939588>) at remote 0x5912bc0>, lock=<thread.lock at remote 0x5928d60>, _Thread__started=<_Event(_Verbose__verbose=False, _Event__flag=True, _Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x521ff40>, acquire=<built-in method acquire of thread.lock object at remote 0x521ff40>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x521ff40>) at remote 0x5223300>) at remote 0x47f56f0>, _channel_counter=22, active=False, _preferred_compression=('none',), server_object=None, kex_engine=None, log_name='paramiko.transport', _x11_handler=None, remote_compression='none', _Thread__initialized=True, server_accepts=[], saved_exc...(truncated), throwflag=0) at Python/ceval.c:2666
#9  0x00000000004d41c3 in fast_function (func=<function at remote 0x16ff060>, pp_stack=0x7f56977ed760, n=1, na=1, nk=0) at Python/ceval.c:4099
#10 0x00000000004d3ed3 in call_function (pp_stack=0x7f56977ed760, oparg=0) at Python/ceval.c:4034
#11 0x00000000004cec2b in PyEval_EvalFrameEx (f=
    Frame 0x53b9380, for file /root/python2.7-2.7.2/Lib/threading.py, line 525, in __bootstrap (self=<Transport(_Thread__ident=140009885591296, host_key_type='ssh-rsa', _channels=<ChannelMap(_lock=<thread.lock at remote 0x5928f90>, _map=<WeakValueDictionary(_remove=<function at remote 0x56355a0>, data={}) at remote 0x5939588>) at remote 0x5912bc0>, lock=<thread.lock at remote 0x5928d60>, _Thread__started=<_Event(_Verbose__verbose=False, _Event__flag=True, _Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x521ff40>, acquire=<built-in method acquire of thread.lock object at remote 0x521ff40>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x521ff40>) at remote 0x5223300>) at remote 0x47f56f0>, _channel_counter=22, active=False, _preferred_compression=('none',), server_object=None, kex_engine=None, log_name='paramiko.transport', _x11_handler=None, remote_compression='none', _Thread__initialized=True, server_accepts=[], saved_exception...(truncated), throwflag=0) at Python/ceval.c:2666
#12 0x00000000004d1533 in PyEval_EvalCodeEx (co=0x16cb510, globals=
    {'current_thread': <function at remote 0x16ffe28>, '_BoundedSemaphore': <type at remote 0x1680cd0>, 'currentThread': <function at remote 0x16ffe28>, '_Timer': <type at remote 0x1682640>, '_format_exc': <function at remote 0x1538e28>, 'Semaphore': <function at remote 0x16fc840>, 'activeCount': <function at remote 0x1700108>, '_profile_hook': None, '_sleep': <built-in function sleep>, '_trace_hook': None, 'ThreadError': <type at remote 0x165f7f0>, '_enumerate': <function at remote 0x17001b0>, '_start_new_thread': <built-in function start_new_thread>, 'BoundedSemaphore': <function at remote 0x16fcf78>, '_shutdown': <instancemethod at remote 0x14a2960>, '__all__': ['activeCount', 'active_count', 'Condition', 'currentThread', 'current_thread', 'enumerate', 'Event', 'Lock', 'RLock', 'Semaphore', 'BoundedSemaphore', 'Thread', 'Timer', 'setprofile', 'settrace', 'local', 'stack_size'], '_Event': <type at remote 0x1681730>, 'active_count': <function at remote 0x1700108>, '__package__': None, '_Condition': <type at remo...(truncated), locals=0x0, args=0x475f088, argcount=1, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at Python/ceval.c:3253
#13 0x000000000055c7e9 in function_call (func=<function at remote 0x16feed0>, arg=
    (<Transport(_Thread__ident=140009885591296, host_key_type='ssh-rsa', _channels=<ChannelMap(_lock=<thread.lock at remote 0x5928f90>, _map=<WeakValueDictionary(_remove=<function at remote 0x56355a0>, data={}) at remote 0x5939588>) at remote 0x5912bc0>, lock=<thread.lock at remote 0x5928d60>, _Thread__started=<_Event(_Verbose__verbose=False, _Event__flag=True, _Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x521ff40>, acquire=<built-in method acquire of thread.lock object at remote 0x521ff40>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x521ff40>) at remote 0x5223300>) at remote 0x47f56f0>, _channel_counter=22, active=False, _preferred_compression=('none',), server_object=None, kex_engine=None, log_name='paramiko.transport', _x11_handler=None, remote_compression='none', _Thread__initialized=True, server_accepts=[], saved_exception=exceptions.EOFError(), packetizer=<Packetizer(_Packetizer__remainder='', _Packetizer__block_siz...(truncated), kw=0x0) at Objects/funcobject.c:526
#14 0x0000000000420ae3 in PyObject_Call (func=<function at remote 0x16feed0>, arg=
    (<Transport(_Thread__ident=140009885591296, host_key_type='ssh-rsa', _channels=<ChannelMap(_lock=<thread.lock at remote 0x5928f90>, _map=<WeakValueDictionary(_remove=<function at remote 0x56355a0>, data={}) at remote 0x5939588>) at remote 0x5912bc0>, lock=<thread.lock at remote 0x5928d60>, _Thread__started=<_Event(_Verbose__verbose=False, _Event__flag=True, _Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x521ff40>, acquire=<built-in method acquire of thread.lock object at remote 0x521ff40>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x521ff40>) at remote 0x5223300>) at remote 0x47f56f0>, _channel_counter=22, active=False, _preferred_compression=('none',), server_object=None, kex_engine=None, log_name='paramiko.transport', _x11_handler=None, remote_compression='none', _Thread__initialized=True, server_accepts=[], saved_exception=exceptions.EOFError(), packetizer=<Packetizer(_Packetizer__remainder='', _Packetizer__block_siz...(truncated), kw=0x0) at Objects/abstract.c:2529
#15 0x000000000042b35f in instancemethod_call (func=<function at remote 0x16feed0>, arg=
    (<Transport(_Thread__ident=140009885591296, host_key_type='ssh-rsa', _channels=<ChannelMap(_lock=<thread.lock at remote 0x5928f90>, _map=<WeakValueDictionary(_remove=<function at remote 0x56355a0>, data={}) at remote 0x5939588>) at remote 0x5912bc0>, lock=<thread.lock at remote 0x5928d60>, _Thread__started=<_Event(_Verbose__verbose=False, _Event__flag=True, _Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x521ff40>, acquire=<built-in method acquire of thread.lock object at remote 0x521ff40>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x521ff40>) at remote 0x5223300>) at remote 0x47f56f0>, _channel_counter=22, active=False, _preferred_compression=('none',), server_object=None, kex_engine=None, log_name='paramiko.transport', _x11_handler=None, remote_compression='none', _Thread__initialized=True, server_accepts=[], saved_exception=exceptions.EOFError(), packetizer=<Packetizer(_Packetizer__remainder='', _Packetizer__block_siz...(truncated), kw=0x0) at Objects/classobject.c:2578
#16 0x0000000000420ae3 in PyObject_Call (func=<instancemethod at remote 0x59377e0>, arg=(), kw=0x0) at Objects/abstract.c:2529
#17 0x00000000004d3496 in PyEval_CallObjectWithKeywords (func=<instancemethod at remote 0x59377e0>, arg=(), kw=0x0) at Python/ceval.c:3882
#18 0x000000000051e193 in t_bootstrap (boot_raw=0x3828988) at ./Modules/threadmodule.c:614
#19 0x00007f56b1f17efc in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#20 0x00007f56b15c789d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#21 0x0000000000000000 in ?? ()


The op object is empty, which caused the segfault:

(gdb) f 0
2220            op->_ob_prev->_ob_next != op || op->_ob_next->_ob_prev != op)
(gdb) p *op
$5 = {_ob_next = 0x0, _ob_prev = 0x0, ob_refcnt = 0, ob_type = 0x3c6d9f0}


I believe this is the python decoded version?:
(gdb) p op
$18 = 
    <Channel(origin_addr=None, in_window_size=65536, in_window_threshold=6553, lock=<thread.lock at remote 0x571bf90>, _pipe=None, eof_received=0, in_max_packet_size=34816, out_buffer_cv=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x571bf90>, acquire=<built-in method acquire of thread.lock object at remote 0x571bf90>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x571bf90>) at remote 0x593d3e0>, event=<_Event(_Verbose__verbose=False, _Event__flag=True, _Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x59138b0>, acquire=<built-in method acquire of thread.lock object at remote 0x59138b0>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x59138b0>) at remote 0x5a333e0>) at remote 0x593ded0>, transport=<Transport(_Thread__ident=140009885591296, host_key_type='ssh-rsa', _channels=<ChannelMap(_lock=<thread.lock at remote 0x5928f90>, _map=<WeakValueDictionary(_re...(truncated

Possibly useful?

(gdb) p (void*)op
$31 = (void *) 0x593bd80
(gdb) p &refchain
$32 = <unknown at remote 0x7e8ca0>


Possibly a double free?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13992>
_______________________________________

From report at bugs.python.org  Sun Feb 12 12:11:38 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Feb 2012 11:11:38 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1329045098.71.0.411806602462.issue13882@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch version 15:
 - round "correctly"
 - datetime.date.fromtimestamp() and datetime.datetime.fromtimestamp() reuses _PyTime_t API to support decimal.Decimal without loss of precision
 - add more tests

----------
Added file: http://bugs.python.org/file24495/time_decimal-15.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Sun Feb 12 12:18:49 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Feb 2012 11:18:49 +0000
Subject: [issue13997] Clearly explain the bare minimum Python 3 users should
	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329045529.5.0.619347316857.issue13997@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If such use cases are indeed better handled as bytes, then that's what should be documented. However, there are some text processing assumptions that no longer hold when using bytes instead of strings (such as "x[0:1] == x[0]"). You also can't safely pass such byte sequences to various other APIs (e.g. urllib.parse will happily process surrogate escaped text without corrupting them, but will throw UnicodeDecodeError for bytes sequences that aren't pure 7-bit ASCII).

Using surrogateescape instead means that you're only going to have problems if you go to encode the data to an encoding other than the source one. That's basically the things work in Python 2 with 8-bit strings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sun Feb 12 12:21:42 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Feb 2012 11:21:42 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1329045702.64.0.10512247356.issue13882@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file24495/time_decimal-15.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Sun Feb 12 12:23:05 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Feb 2012 11:23:05 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1329045785.35.0.802192534411.issue13882@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

(Oops, I attached the wrong patch.)

----------
Added file: http://bugs.python.org/file24496/time_decimal-15.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Sun Feb 12 12:25:06 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Feb 2012 11:25:06 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1329045906.43.0.296331084269.issue13882@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file24496/time_decimal-15.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Sun Feb 12 12:37:56 2012
From: report at bugs.python.org (andrea crotti)
Date: Sun, 12 Feb 2012 11:37:56 +0000
Subject: [issue13991] namespace packages depending on order
In-Reply-To: <1328907203.29.0.677752935093.issue13991@psf.upfronthosting.co.za>
Message-ID: <1329046676.56.0.0686578302257.issue13991@psf.upfronthosting.co.za>


andrea crotti <andrea.crotti.0 at gmail.com> added the comment:

About the binary file, in theory I agree with you, but that archive contains 5 or 6 subdirectories with a few almost empty files.

Of course I can write a script that recreates that situation, but does it make sense when I can just tar and untar it?
And what should be the security threat in a tar.gz file?

Anyway it doesn't matter and sure I will try to use plain text in the future..

About the bug, for what I can understand the bug comes from pkg_resources:
/usr/lib/python2.7/site-packages/pkg_resources.py is owned by python2-distribute 0.6.24-1

and/or from how the import mechanism works on namespace packages, not from setuptools..
Should I still move the bug report to somewhere else?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13991>
_______________________________________

From report at bugs.python.org  Sun Feb 12 12:37:58 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Feb 2012 11:37:58 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1329046678.69.0.977249799883.issue13882@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New try, set the version to 16 to avoid the confusion.

test_time is failing on Windows.

----------
Added file: http://bugs.python.org/file24497/time_decimal-16.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Sun Feb 12 13:16:36 2012
From: report at bugs.python.org (Paul Moore)
Date: Sun, 12 Feb 2012 12:16:36 +0000
Subject: [issue13997] Clearly explain the bare minimum Python 3 users should
	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329048996.28.0.292415350086.issue13997@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

A better example in terms of "intended to be text" might be ChangeLog files. These are clearly text files, but of sufficiently standard format that they can be manipulated programmatically.

Consider a program to get a list of all authors who changed a particular file. Scan the file for date lines, then scan the block of text below for the filename you care about. Extract the author from the date line, put into a set, sort and print.

All of this can be done assuming the file is ASCII-compatible, but requires non-trivial text processing that would be a pain to do on bytes. But author names are quite likely to be non-ASCII, especially if it's an international project. And the changelog file is manually edited by people on different machines, so the possibility of inconsistent encodings is definitely there. (I have seen this happen - it's not theoretical!)

For my code, all I care about is that the names round-trip, so that I'm not damaging people's names any more than has already happened.

encoding="ascii",errors="surrogateescape" sounds like precisely the right answer here.

(If it's hard to find a good answer in Python 3, it's very easy to decide to use Python 2 which "just works", or even other tools like awk which also take Python 2's naive approach - and dismiss Python 3's Unicode model as "too hard").

My mental model here is text editors, which let you open any file, do their best to display as much as they can and allow you to manipulate it without damaging the bits you don't change. I don't see any reason why people shouldn't be able to write Python 3 code that way if they need to.

----------
nosy: +pmoore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sun Feb 12 13:28:18 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 12 Feb 2012 12:28:18 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329049698.57.0.0966129848823.issue13988@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

There was a discussion in December which ruled out some CPython too specific implementation details from the documentation.
http://mail.python.org/pipermail/python-dev/2011-December/115063.html

Maybe it's better to remove these 2 lines about the "transparent optimizer". Then the "versionchanged" tag can be changed a little:
.. versionchanged:: 3.3
   This module will use a fast implementation whenever available.
   The module :mod:`xml.etree.cElementTree` is deprecated.

Probably we'll add few words in the Doc/whatsnew/3.3.rst too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sun Feb 12 13:52:26 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 12 Feb 2012 12:52:26 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329051146.71.0.973661276317.issue13988@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Updated patch:
 - add 'XMLID' and 'register_namespace' to the ElementTree.__all__
 - the comment says explicitly that cElementTree is deprecated
 - exercise the deprecated module with the tests

----------
Added file: http://bugs.python.org/file24498/issue13988_fold_cET_behind_ET_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sun Feb 12 14:00:19 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 12 Feb 2012 13:00:19 +0000
Subject: [issue13997] Clearly explain the bare minimum Python 3 users should
	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329051619.19.0.570366959524.issue13997@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sun Feb 12 14:06:52 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 12 Feb 2012 13:06:52 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1329052012.07.0.203394128532.issue10287@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

I've added general tests of AUTH USER/PASS as there weren't any present yet.

As I haven't alas heard back from Easynews, I can only presume they allow CAPABILITIES after a login ? I've added a test case that models this behavior.

Otherwise I did as it was asked: getcapabilities() is tolerant to temporary errors and we get them again after a login now.

(I'm also using the remote repo tool now to avoid further patch fuckups ? sorry for the extra mails.)

----------
hgrepos: +113

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10287>
_______________________________________

From report at bugs.python.org  Sun Feb 12 14:07:34 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 12 Feb 2012 13:07:34 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1329052054.27.0.786484617563.issue10287@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


Added file: http://bugs.python.org/file24499/0cf0b06e1d31.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10287>
_______________________________________

From report at bugs.python.org  Sun Feb 12 15:53:12 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Feb 2012 14:53:12 +0000
Subject: [issue13997] Clearly explain the bare minimum Python 3 users should
	know about Unicode
In-Reply-To: <1329048996.28.0.292415350086.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329058207.3456.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> My mental model here is text editors, which let you open any file, do
> their best to display as much as they can and allow you to manipulate
> it without damaging the bits you don't change. I don't see any reason
> why people shouldn't be able to write Python 3 code that way if they
> need to.

Some text editors try to guess the encoding, which is different from
"display invalid characters anyway".
Other text editors like gedit pop up an error when there are invalid
bytes according to the configured encoding.

That said, people *are* able to write Python 3 code the way you said.
They simply have to use the "surrogateescape" error handler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sun Feb 12 16:47:30 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 12 Feb 2012 15:47:30 +0000
Subject: [issue13992] Segfault in PyTrash_destroy_chain
In-Reply-To: <1329044711.89.0.393446996799.issue13992@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2ZEJe9-fwJvwHEg=tMD8dGT-FGX-ukDSdVS1gSECHpBw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Possibly a double free?

> (gdb) p *op
> $5 = {_ob_next = 0x0, _ob_prev = 0x0, ob_refcnt = 0, ob_type = 0x3c6d9f0}
>

It indeed looks like a double free (see the previous and next pointers
have already been set to NULL).

Could you check if there's not another thread active inside the
interpreter at the same time ("thread apply all bt")?

But I'm afraid it'll be hard to debug with just a core dump.
Do you have any test script that could be used to reproduce the crash?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13992>
_______________________________________

From report at bugs.python.org  Sun Feb 12 18:14:25 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 12 Feb 2012 17:14:25 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1329066865.73.0.765101524363.issue13968@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The last forumulation of what rglob does "apply the glob to the current directory and all subdirectories recursively, returning the joined list with filenames anchored in the current directory" is simple and intuitive enough for me.  (I'm not sure it can be implemented using Nick's module.)

The discussions about starting directory and the meaning of '..' and implicitly prepending '*' totally confused me.  If the formulation in my first paragraph is the intended semantics and the function actually implements those semantics (however it does it under the hood), then I'm fine with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Sun Feb 12 18:26:31 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Feb 2012 17:26:31 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1329067591.51.0.688623798709.issue10287@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've made a couple of small comments (see "review" link next to the patch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10287>
_______________________________________

From report at bugs.python.org  Sun Feb 12 18:58:55 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 12 Feb 2012 17:58:55 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1329069535.08.0.151256051528.issue10287@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


Added file: http://bugs.python.org/file24500/e986dd8bb47d.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10287>
_______________________________________

From report at bugs.python.org  Sun Feb 12 19:00:08 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 12 Feb 2012 18:00:08 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1329069608.62.0.215786621789.issue10287@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

Thanks! I think I've addressed everything in the latest patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10287>
_______________________________________

From report at bugs.python.org  Sun Feb 12 19:18:16 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 12 Feb 2012 18:18:16 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <E1Rwe04-0004P6-B1@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d789f453387d by Antoine Pitrou in branch '3.2':
Issue #10287: nntplib now queries the server's CAPABILITIES again after authenticating (since the result may change, according to RFC 4643).
http://hg.python.org/cpython/rev/d789f453387d

New changeset 98ad67529241 by Antoine Pitrou in branch 'default':
Issue #10287: nntplib now queries the server's CAPABILITIES again after authenticating (since the result may change, according to RFC 4643).
http://hg.python.org/cpython/rev/98ad67529241

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10287>
_______________________________________

From report at bugs.python.org  Sun Feb 12 19:18:48 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Feb 2012 18:18:48 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1329070728.67.0.602547647974.issue10287@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you :) Committed now.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10287>
_______________________________________

From report at bugs.python.org  Sun Feb 12 19:19:42 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Feb 2012 18:19:42 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1329070782.72.0.116909484925.issue10287@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Perhaps I closed too quickly... Julien's original message had two other requests:

?If "READER" is advertised, no need to send a "MODE READER" command at all...

If "MODE-READER" is advertised, then "MODE READER" (if wanted) can be sent.
Then, self.capabilities() should be sent again.  Capabilities changed!?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10287>
_______________________________________

From report at bugs.python.org  Sun Feb 12 19:31:34 2012
From: report at bugs.python.org (Paul Moore)
Date: Sun, 12 Feb 2012 18:31:34 +0000
Subject: [issue13198] Remove duplicate definition of write_record_file
In-Reply-To: <1318857154.54.0.641953188635.issue13198@psf.upfronthosting.co.za>
Message-ID: <1329071494.37.0.842415354862.issue13198@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

Produces RECORD files with CR-CR-LF line endings (see issue13175). This breaks pysetup remove.

I can't tell if this patch is good otherwise - it's certainly no worse than the behaviour of the unpatched version, but that's not saying much :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13198>
_______________________________________

From report at bugs.python.org  Sun Feb 12 19:32:14 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 12 Feb 2012 18:32:14 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <1329071534.26.0.192426320686.issue11836@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Thanks Eli for the heads-up, I had missed Antoine's comment!

Antoine, I'm probably missing something, but SimpleQueue is present in 2.7 and 3.2 too, so why not mention it in the doc for those versions too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11836>
_______________________________________

From report at bugs.python.org  Sun Feb 12 19:34:35 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Feb 2012 18:34:35 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <1329071675.29.0.806371403295.issue11836@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, I'm probably missing something, but SimpleQueue is present in 
> 2.7 and 3.2 too, so why not mention it in the doc for those versions too?

What I mean is that "multiprocessing.SimpleQueue" is a new API, so should be 3.3-only (while "multiprocessing.queues.SimpleQueue" already exists).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11836>
_______________________________________

From report at bugs.python.org  Sun Feb 12 19:37:33 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 12 Feb 2012 18:37:33 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1329071853.79.0.946065431412.issue10287@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

There's one more issue Julien has raised: nntplib attempts to authenticate when "AUTHINFO" is sent w/o USER. (haven't tested it but I presume it's still valid)

It's trivial to catch that but I'd say that it's fine to let the server handle it if the user has specifically told us to authenticate by giving credentials ? no? Maybe if dealing with not-entirely-rfc-compliant servers?

I will look into the READER/MODE-READER part.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10287>
_______________________________________

From report at bugs.python.org  Sun Feb 12 19:46:04 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 12 Feb 2012 18:46:04 +0000
Subject: [issue13999] Queue references in multiprocessing doc points to Queue
	module and not to self
Message-ID: <1329072364.23.0.444581618774.issue13999@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

At the subject says, several references to Queue are linking to Queue module and not to multiprocessing.

----------
assignee: docs at python
components: Documentation
messages: 153218
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: Queue references in multiprocessing doc points to Queue module and not to self
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13999>
_______________________________________

From report at bugs.python.org  Sun Feb 12 19:50:16 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 12 Feb 2012 18:50:16 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <1329072616.54.0.862706873509.issue11836@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

It's the way all the subclasses are imported into the main module that got me in fault, I think. OK, so if I got it correctly, I should document multiprocessing.queue.SimpleQueue in 2.7 and 3.1 and multiprocessing.SimpleQueue in 3.3 also adding the hunk to __init__ (thus changing the API).

I'd say to document int still near to Queue() and JoinableQueue() - do you agree?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11836>
_______________________________________

From report at bugs.python.org  Sun Feb 12 19:59:42 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Feb 2012 18:59:42 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1329072616.54.0.862706873509.issue11836@psf.upfronthosting.co.za>
Message-ID: <1329073001.3456.12.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It's the way all the subclasses are imported into the main module that
> got me in fault, I think. OK, so if I got it correctly, I should
> document multiprocessing.queue.SimpleQueue in 2.7 and 3.1 and
> multiprocessing.SimpleQueue in 3.3 also adding the hunk to __init__
> (thus changing the API).

Yes.

> I'd say to document int still near to Queue() and JoinableQueue() - do
> you agree?

Yes, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11836>
_______________________________________

From report at bugs.python.org  Sun Feb 12 20:06:23 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 12 Feb 2012 19:06:23 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329073583.14.0.339240015183.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Florent,

Your updated patch looks good. I think that the explicit import of _namespace_map into cElementTree is just to satisfy some weird magic in the tests and can probably be removed as well (along with the weird magic :-), but that's not really important and can be left for later cleanups.

Regarding the documentation, alright let's not mention the implementation detail, and your "versionchanged" addition makes sense. I don't think adding directly to whatsnew/3.3.rst is necessary, updating Misc/NEWS is enough.

I'll apply the documentation patch after you apply the code patch. Or if you want, you can apply it yourself, I don't mind.

Thanks for the cooperation!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sun Feb 12 20:09:44 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 12 Feb 2012 19:09:44 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <E1Rwens-00086f-75@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 60aa7dacb605 by Petri Lehtinen in branch '2.7':
Fix sqlite3.Connection.iterdump on tables/fields with reserved names or quotes
http://hg.python.org/cpython/rev/60aa7dacb605

New changeset 4b105d328fe7 by Petri Lehtinen in branch '3.2':
Fix sqlite3.Connection.iterdump on tables/fields with reserved names or quotes
http://hg.python.org/cpython/rev/4b105d328fe7

New changeset 5d0f7b275fe9 by Petri Lehtinen in branch 'default':
Merge branch '3.2'
http://hg.python.org/cpython/rev/5d0f7b275fe9

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9750>
_______________________________________

From report at bugs.python.org  Sun Feb 12 20:11:15 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 12 Feb 2012 19:11:15 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329073875.28.0.762547976155.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

By the way, I see that if the explicit import of _namespace_map is commented out, the test_xml_etree_c test fails because it's not in the __all__ list. So the test can just import it directly with:

from xml.etree.ElementTree import _namespace_map

And the import in cElementTree won't be necessary. After all, _namespace_map is definitely not a public API!

This will keep cElementTree an nice-and-clean:

from xml.etree.ElementTree import *

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sun Feb 12 20:13:14 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 12 Feb 2012 19:13:14 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <1329073994.09.0.149243743007.issue11836@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

>> OK, so if I got it correctly, I should document multiprocessing.queue.SimpleQueue in 2.7 and 3.1 [...]

and 3.2, we're no longer updating 3.1 with such changes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11836>
_______________________________________

From report at bugs.python.org  Sun Feb 12 20:13:55 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 12 Feb 2012 19:13:55 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <1329074035.87.0.262479299117.issue11836@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
Removed message: http://bugs.python.org/msg153224

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11836>
_______________________________________

From report at bugs.python.org  Sun Feb 12 20:14:24 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 12 Feb 2012 19:14:24 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <1329074064.63.0.977210290074.issue11836@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

> OK, so if I got it correctly, I should document multiprocessing.queue.SimpleQueue in 2.7 and 3.1 [...]


s/3.1/3.2/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11836>
_______________________________________

From report at bugs.python.org  Sun Feb 12 20:23:19 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 12 Feb 2012 19:23:19 +0000
Subject: [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>
Message-ID: <1329074599.03.0.56858018181.issue13491@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

> > In the Doc/includes/sqlite3 directory there are still some scripts that require the
> > createdb.py, so I didn't nuke the file.
>
> Do these scripts (or a README file) explain about createdb.py?

No. There's no mention of createdb.py anywhere.

> > I also removed the strange "The arguments to :meth:`executescript` must be :func:`bytes`
> > objects" sentence from the patch. I assume it was a mistake, as it's wrong.
>
> Why not change it so that it?s correct?  (Maybe looking at the file history would
> show where the mistake comes from.)

It's just not in the history, it was only in OP's patch. And it's wrong, as executescript() takes an str argument, not bytes.

Having slept over this, I think execute_1.py and execute_2.py should be merged as one file, as after my patch, execute_2.py would not be runnable by itself.

This would also be a good chance to look at all the examples and have them cleaned up. That could also be a separate patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13491>
_______________________________________

From report at bugs.python.org  Sun Feb 12 20:53:45 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 12 Feb 2012 19:53:45 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1329074064.63.0.977210290074.issue11836@psf.upfronthosting.co.za>
Message-ID: <CAPdtAj0f0ScG6o1x4FhDQc9tpdrurWTkBbKBavHXjW_zoLEnTg@mail.gmail.com>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

>> OK, so if I got it correctly, I should document multiprocessing.queue.SimpleQueue in 2.7 and 3.1 [...]
>
> s/3.1/3.2/

yeah, just a typo :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11836>
_______________________________________

From report at bugs.python.org  Sun Feb 12 21:36:30 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 12 Feb 2012 20:36:30 +0000
Subject: [issue13193] packaging.tests.test_manifest and
	distutils.tests.test_filelist failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1329078990.14.0.591780942125.issue13193@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

It appears that while test_process_template() uses "/"-delimited paths
consistently across all OSes, 2.7 also has a test_process_template_line()
that uses os.path.join() to construct its paths. Changing this test to
use hardcoded "/"-delimited paths fixes the failure (see attached patch).

----------
stage: needs patch -> commit review
Added file: http://bugs.python.org/file24501/fix-test_process_template_lines.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Sun Feb 12 22:02:56 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 12 Feb 2012 21:02:56 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1329080576.09.0.396311527032.issue10287@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


Added file: http://bugs.python.org/file24502/b33bcf179df4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10287>
_______________________________________

From report at bugs.python.org  Sun Feb 12 22:03:28 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 12 Feb 2012 21:03:28 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1329080608.95.0.0424941034685.issue10287@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

So my take on the whole issue and Antoine "tends to agree". ;)

1. If the user tells us (s)he _wants_ us to authenticate or send MODE READER, we do it even if capabilities don't advertise it. There's a lot of rfc-non-conformant servers out there. Permanent errors (i.e. not supported) will be gracefully swallowed.

That's already status quo.

2. If the server tells us it already _is_ in READER mode, we don't send it because in that case we can assume the server knows what it's doing.

The next patch checks whether we're in READER mode before trying to switch the mode.

I've also added a test for the basic case where a connection is made to a MODE-READER advertising server.

I also added a handler to the nntp2 tests that raises an exception if "mode reader" is called although the server advertises itself as "reader".

If there's a consensus of not sending "MODE READER" if not advertised, it's a matter of two lines to fix that. Personally, I like this middle ground best.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10287>
_______________________________________

From report at bugs.python.org  Sun Feb 12 22:07:45 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 12 Feb 2012 21:07:45 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329080865.73.0.500579895781.issue13988@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

> from xml.etree.ElementTree import _namespace_map
>
> And the import in cElementTree won't be necessary.
> After all, _namespace_map is definitely not a public API!

Because of the interaction of the support.import_fresh_module with the CleanContext context manager, it's not so easy to remove black magic.
I don't find better than:

        if hasattr(ET, '_namespace_map'):
            _namespace_map = ET._namespace_map
        else:
            from xml.etree.ElementTree import _namespace_map


This is why I kept the import in the deprecated "cElementTree" at first.
It does not hurt (it's private API), and it makes the test easier.

( If you have doubts, try ./python -m test test_xml_etree{,_c} or variants. )


I will probably commit code and documentation at once. It makes things easier regarding traceability.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Sun Feb 12 23:00:19 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 12 Feb 2012 22:00:19 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1329084019.05.0.0825520910128.issue13609@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Actually this test fails due to another reason. I'm still investigating it.

In the meantime, a different bug was found:

# stty size | cat
46 157
# python3.3 -c 'import os; print(os.get_terminal_size())' | cat
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OSError: [Errno 22] Invalid argument

Especially redirection to `less` is often used. `stty size` works, so it should be possible to fix Python.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Mon Feb 13 00:02:45 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Feb 2012 23:02:45 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1329087765.42.0.413040232793.issue13609@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Using strace, I see that stty calls ioctl(TIOCGWINSZ) on stdin (fd=0)
if it failed on stdout (fd=1), whereas Python only tries stdout.

Attached patch implements a similar idea.

----------
Added file: http://bugs.python.org/file24503/get_terminal_size_pipe.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Mon Feb 13 00:13:21 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Feb 2012 23:13:21 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1329088401.39.0.507507967267.issue13609@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Your patch is wrong. It always discards ioctl(stdout), even if it was successful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Mon Feb 13 00:14:32 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Feb 2012 23:14:32 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1329088472.37.0.857080718393.issue3905@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In 3.2.2, starting IDLE from a Command Prompt, I get the same error as Denver. Starting IDLE 'normally', from the icon, there is no error. So even though Command Prompt detaches pythonw in some way and gives me a new prompt to do something else, there is something different about the pythonw process that trips up subprocess.

Changing ["python", "-c", "print(32)"] to ["notepad"] gives the same result. Running in the interactive interpreted eliminated the error. So does changing stdin=None to stdin=subprocess.PIPE eliminates the error and brings up Notepad, which seems to operate normally. (I am guessing that it ignores stdin, etc.).

I see that that the latter was known in the original post and plausibly diagnosed by Trent Mick, but never fixed because it was not obvious how to do so.

Can the WindowsError be caught in subproccess, and if it is this error (6), follow the alternate patch that is used for NULL returns? Could that cause worse problems that the current situation?

If this is unfixable due to Windows behavior, perhaps we should say something in the doc.

----------
nosy: +terry.reedy
stage:  -> test needed
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Mon Feb 13 00:25:25 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Feb 2012 23:25:25 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1329088401.39.0.507507967267.issue13609@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYN+F93XmXBBYNW+onk_WeeRv0G+xO2w2x4-ZpXS8Cemg@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

New try (I fixed my email address and the patch).

----------
Added file: http://bugs.python.org/file24504/get_terminal_size_pipe-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________
-------------- next part --------------
diff -r 5d0f7b275fe9 Lib/shutil.py
--- a/Lib/shutil.py	Sun Feb 12 21:06:57 2012 +0200
+++ b/Lib/shutil.py	Mon Feb 13 00:25:38 2012 +0100
@@ -912,7 +912,7 @@ def get_terminal_size(fallback=(80, 24))
     # only query if necessary
     if columns <= 0 or lines <= 0:
         try:
-            size = os.get_terminal_size(sys.__stdout__.fileno())
+            size = os.get_terminal_size()
         except (NameError, OSError):
             size = os.terminal_size(fallback)
         if columns <= 0:
diff -r 5d0f7b275fe9 Modules/posixmodule.c
--- a/Modules/posixmodule.c	Sun Feb 12 21:06:57 2012 +0200
+++ b/Modules/posixmodule.c	Mon Feb 13 00:25:38 2012 +0100
@@ -10532,7 +10532,7 @@ get_terminal_size(PyObject *self, PyObje
     int columns, lines;
     PyObject *termsize;
 
-    int fd = fileno(stdout);
+    int fd = -1;
     /* Under some conditions stdout may not be connected and
      * fileno(stdout) may point to an invalid file descriptor. For example
      * GUI apps don't have valid standard streams by default.
@@ -10547,8 +10547,23 @@ get_terminal_size(PyObject *self, PyObje
 #ifdef TERMSIZE_USE_IOCTL
     {
         struct winsize w;
-        if (ioctl(fd, TIOCGWINSZ, &w))
-            return PyErr_SetFromErrno(PyExc_OSError);
+
+        if (fd == -1) {
+            fd = fileno(stdout);
+            if (ioctl(fd, TIOCGWINSZ, &w)) {
+                if (errno != EINVAL)
+                    return PyErr_SetFromErrno(PyExc_OSError);
+                /* ioctl(TIOCGWINSZ) may fail on stdout if stdout is a pipe,
+                   retry on stin */
+                fd = fileno(stdin);
+                if (ioctl(fd, TIOCGWINSZ, &w))
+                    return PyErr_SetFromErrno(PyExc_OSError);
+            }
+        }
+        else {
+            if (ioctl(fd, TIOCGWINSZ, &w))
+                return PyErr_SetFromErrno(PyExc_OSError);
+        }
         columns = w.ws_col;
         lines = w.ws_row;
     }
@@ -10559,6 +10574,10 @@ get_terminal_size(PyObject *self, PyObje
         DWORD nhandle;
         HANDLE handle;
         CONSOLE_SCREEN_BUFFER_INFO csbi;
+
+        if (fd == -1)
+            fd = 1;
+
         switch (fd) {
         case 0: nhandle = STD_INPUT_HANDLE;
             break;

From report at bugs.python.org  Mon Feb 13 00:28:22 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sun, 12 Feb 2012 23:28:22 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1329089302.55.0.964763536692.issue13609@psf.upfronthosting.co.za>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

> Using strace, I see that stty calls ioctl(TIOCGWINSZ) on stdin (fd=0)
> if it failed on stdout (fd=1), whereas Python only tries stdout.
It was done this way by design. Maybe checking stdin can be also useful,
but it is a rather big change in semantics. I think it should be a separate bug.

It is pretty common for programs to behave differently when run through pipe, even if stdin is on a tty. stty is rather the exception than the rule. E.g. almost all programs disable color when piped explicitly through less. 'dpkg | cat' ignores terminal width. So does git and ls.
stty is special, because the only purpose of that program is to query terminal size, but it cannot be taken as a model for the behaviour of a general purpose program.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Mon Feb 13 00:38:41 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 12 Feb 2012 23:38:41 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1329089921.22.0.546116535775.issue13609@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

The purpose of os.get_terminal_size() is the same as `stty size`, so `stty size` could be a model for behavior of os.get_terminal_size().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Mon Feb 13 00:45:11 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Feb 2012 23:45:11 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1329090311.11.0.743991113314.issue13609@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> E.g. almost all programs disable color when piped explicitly through less.

Using my patch, you can use os.get_terminal_size(sys.stdout.fileno()) if you like to get an error if sys.stdout is a pipe. My patch only changes the behaviour if no argument is specified (hum, the "special" behaviour should be documented). Or you can also check explicitly sys.stdout.isatty().

It is just more convinient to fallback to stdin if stdout is not a TTY.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Mon Feb 13 01:00:29 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 13 Feb 2012 00:00:29 +0000
Subject: [issue13930] lib2to3 ability to output files into a different
	directory and alter their names
In-Reply-To: <1328254888.57.0.86339015419.issue13930@psf.upfronthosting.co.za>
Message-ID: <E1RwjLI-00046J-1b@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ceea9ebfe003 by Gregory P. Smith in branch '3.2':
Issue #13930: Adds ability for 2to3 to write its output to a different
http://hg.python.org/cpython/rev/ceea9ebfe003

New changeset 9f583700d27f by Gregory P. Smith in branch '2.7':
Issue #13930: Adds ability for 2to3 to write its output to a different
http://hg.python.org/cpython/rev/9f583700d27f

New changeset 4b791e513c2c by Gregory P. Smith in branch 'default':
Issue #13930: Adds ability for 2to3 to write its output to a different
http://hg.python.org/cpython/rev/4b791e513c2c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13930>
_______________________________________

From report at bugs.python.org  Mon Feb 13 01:01:46 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 13 Feb 2012 00:01:46 +0000
Subject: [issue13930] lib2to3 ability to output files into a different
	directory and alter their names
In-Reply-To: <1328254888.57.0.86339015419.issue13930@psf.upfronthosting.co.za>
Message-ID: <1329091306.36.0.713093838367.issue13930@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
hgrepos:  -111

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13930>
_______________________________________

From report at bugs.python.org  Mon Feb 13 01:04:41 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 13 Feb 2012 00:04:41 +0000
Subject: [issue13930] lib2to3 ability to output files into a different
	directory and alter their names
In-Reply-To: <1328254888.57.0.86339015419.issue13930@psf.upfronthosting.co.za>
Message-ID: <1329091481.22.0.78029464531.issue13930@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/issue13930>
_______________________________________

From report at bugs.python.org  Mon Feb 13 01:23:13 2012
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Feb 2012 00:23:13 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1329092593.14.0.668972137934.issue13882@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Here is the version 17 of my patch. This version is mostly complete and so can be reviewed. Summary of the patch:

 - Add a _PyTime_t structure to store any timestamp in any resolution, universal structure used by all functions manipulating timestamps instead of C double to avoid loss of precision
 - Add many functions to create timestamp (set _PyTime_t structure) or to get a timestamp in a specific format (int, float, Decimal, timeval or timespec structure, in milliseconds, etc.)
 - Round to nearest with ties going away from zero (rounding method called "ROUND_HALF_UP" in Decimal)
 - Functions creating timestamps get a new optional timestamp argument to specify the requested return type, e.g. time.time(timestamp=int) returns an int
 - Functions getting timestamps argument now also support decimal.Decimal
 - Raise an OverflowError instead of a ValueError if a timestamp cannot be stored in a C time_t type

The patch is huge, but as I wrote before, I will split it into smaller parts:

 - Add _PyTime_t API
 - Use the new API in the time module
 - Use the new API in the os module
 - etc.

Changes in the version 17 of my patch:

 - tested on Linux 32/64 bits, OpenBSD 64 bits, FreeBSD 64 bits, Windows 64 bits
 - fix portability issues (for various time_t and C long sizes)

----------
Added file: http://bugs.python.org/file24505/time_decimal-17.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Mon Feb 13 01:24:55 2012
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Feb 2012 00:24:55 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1329092695.2.0.639968082928.issue13882@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file24473/time_decimal-14.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Mon Feb 13 01:24:56 2012
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Feb 2012 00:24:56 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1329092696.42.0.631935508546.issue13882@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file24497/time_decimal-16.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Mon Feb 13 02:01:29 2012
From: report at bugs.python.org (Aaron Staley)
Date: Mon, 13 Feb 2012 01:01:29 +0000
Subject: [issue13992] Segfault in PyTrash_destroy_chain
In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za>
Message-ID: <1329094889.65.0.212243579014.issue13992@psf.upfronthosting.co.za>


Aaron Staley <usaar33 at gmail.com> added the comment:

As far as I can tell, no other thread is active.  Their backtraces are all either:


#0  0x00007f283dedd300 in sem_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x0000000000519295 in PyThread_acquire_lock (lock=0xe7dd50, waitflag=1) at Python/thread_pthread.h:321
#2  0x00000000004c734f in PyEval_RestoreThread (tstate=0xfbfb40) at Python/ceval.c:357


or

Thread 77 (Thread 0x7f2808fb1700 (LWP 30292)):
#0  0x00007f283d57a773 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f283c458739 in internal_select (s=0x7f2831432ca0, writing=0) at /root/python2.7-2.7.2/Modules/socketmodule.c:692
#2  0x00007f283c45acdf in sock_recv_guts (s=0x7f2831432ca0, cbuf=0x339bf7c "\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313", <incomplete sequence \313>, len=16, flags=0) at /root/python2.7-2.7.2/Modules/socketmodule.c:2356
(More stack frames follow...)

or

Thread 17 (Thread 0x7f2829ff3700 (LWP 19252)):
#0  0x00007f283d57f913 in select () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f283d2a1fac in floatsleep (secs=0) at /root/python2.7-2.7.2/Modules/timemodule.c:943
#2  0x00007f283d2a0cd9 in time_sleep (self=0x0, args=(<float at remote 0xb3ed40>,)) at /root/python2.7-2.7.2/Modules/timemodule.c:206
(More stack frames follow...)

or
Thread 12 (Thread 0x7f2834e5f700 (LWP 19223)):
#0  0x00007f283d57f913 in select () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f2839cb275e in select_select (self=0x0, args=([<_socketobject at remote 0x7f2830f4d1a0>, <_socketobject at remote 0x2106ec0>], [], [], <float at remote 0x7f283034d510>)) at /root/python2.7-2.7.2/Modules/selectmodule.c:278
#2  0x000000000055f0ee in PyCFunction_Call (func=<built-in function select>, arg=([<_socketobject at remote 0x7f2830f4d1a0>, <_socketobject at remote 0x2106ec0>], [], [], <float at remote 0x7f283034d510>), kw=0x0) at Objects/methodobject.c:81
(More stack frames follow...)


Unfortunately, I've only been able to produce the segfault with this program (an EC2 server monitor and deployer).  It's very site specific and couldn't run on another machine.

That said, I can trigger these segfaults with high reliability, so I can certainly add additional debugging logs if requested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13992>
_______________________________________

From report at bugs.python.org  Mon Feb 13 03:18:54 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Feb 2012 02:18:54 +0000
Subject: [issue13955] email: RFC 2822 has been obsoleted by RFC 5322
In-Reply-To: <1328561144.0.0.46908466856.issue13955@psf.upfronthosting.co.za>
Message-ID: <1329099534.17.0.501276817852.issue13955@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  I misread this.  You are, in fact correct, but I don't think there is anything comprehensive to do here.  As I make changes and have actually checked then against RFC 5322, I'm either changing or adding that RFC number to the comments and docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13955>
_______________________________________

From report at bugs.python.org  Mon Feb 13 03:57:33 2012
From: report at bugs.python.org (Aaron Staley)
Date: Mon, 13 Feb 2012 02:57:33 +0000
Subject: [issue13992] Segfault in PyTrash_destroy_chain
In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za>
Message-ID: <1329101853.65.0.507253954597.issue13992@psf.upfronthosting.co.za>


Aaron Staley <usaar33 at gmail.com> added the comment:

I should note that my program is also affected by this bug:
http://bugs.python.org/issue13817
(couldn't isolate it until I used the pydebug configure info).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13992>
_______________________________________

From report at bugs.python.org  Mon Feb 13 04:36:09 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Feb 2012 03:36:09 +0000
Subject: [issue8739] Update to smtpd.py to RFC 5321
In-Reply-To: <1274103249.44.0.284620021799.issue8739@psf.upfronthosting.co.za>
Message-ID: <1329104169.61.0.982930593903.issue8739@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Alberto, might you still interested in working on this?  I thought I'd do a quick update to current trunk and check it in, but in the process of doing that I found some issues.  I suspect it has been frustrating for you that nothing happened with this for 3.2, but it is a non-trivial patch since it involves RFC conformance.

I'm uploading what I got done of the update.  I've restored your introduction of a size argument to the smtp and channel classes (I don't know why Giampaolo objected, adding keyword arguments is not backward incompatible).  A max data size was introduced to deal with a DOS attack on the SMTPD server, called data_size_limit.  I changed that to be 'max_message_size' (rather than your size_limit) because this patch will make it be used for implementing that extended SMTP feature (as well as continuing to provide the DOS-preventing-limit by default).

There are still not enough tests.  In particular there are no tests for the smtpd command line functionality, and there was a bug in that in the last patch (it was still using the class argument you had eliminated at Giampaolo's request).  Writing those tests is of course a bit of a pain, but by combining the stuff from script_helpers with smtplib, it ought to be possible.  (But I wouldn't let a lack of command line tests prevent me from committing a completed patch.)

The more important problem is that your implementation of RFC 5321 left out a critical piece: parameters on the MAIL FROM and RCPT TO commands, and in particular the SIZE parameter to MAIL FROM.  Without that you aren't actually implementing RFC 1870 (or, for that matter, 5321 since a compliant server should reject unknown parameters as a syntax error).

I know it has been a long time, but are you still interested in working on this?  I haven't had much time to review stuff lately, much less do coding for the stdlib, but I'd really like to see this in 3.3, so if you are willing to work on it I'll commit to reviewing it in a timely fashion.

----------
assignee:  -> r.david.murray
versions: +Python 3.3 -Python 3.2
Added file: http://bugs.python.org/file24506/rfc5321.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8739>
_______________________________________

From report at bugs.python.org  Mon Feb 13 04:46:11 2012
From: report at bugs.python.org (Meador Inge)
Date: Mon, 13 Feb 2012 03:46:11 +0000
Subject: [issue13979] Automatic *libc.so loading behaviour
In-Reply-To: <1328821808.41.0.811189579105.issue13979@psf.upfronthosting.co.za>
Message-ID: <1329104771.05.0.125900934837.issue13979@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

'find_library' itself actually loads no libraries.  I suspect what happened was that the following code in the 'uuid' module coupled with the 'find_library' bug caused 'liblttng-ust-libc.so' to be loaded:

    for libname in ['uuid', 'c']:
        try:
            lib = ctypes.CDLL(ctypes.util.find_library(libname))
        except:
            continue
        if hasattr(lib, 'uuid_generate_random'):
            _uuid_generate_random = lib.uuid_generate_random
        if hasattr(lib, 'uuid_generate_time'):
            _uuid_generate_time = lib.uuid_generate_time

This issue was fixed in 3.3 as a part of the optimization done in issue11258. I can still reproduce the problem in 2.7 and 3.2.

I am just going to backport the 3.3 regex to 2.7 and 3.2.  This is not an issue for the '_findLib_gcc' regex because the GCC output has a different format.  '_findLib_ldconfig' is never actually called so I removed it.  Patch attached.

----------
keywords: +patch
stage: needs patch -> patch review
versions:  -Python 3.3
Added file: http://bugs.python.org/file24507/issue13979-v0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13979>
_______________________________________

From report at bugs.python.org  Mon Feb 13 05:03:28 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 13 Feb 2012 04:03:28 +0000
Subject: [issue12297] Clarifications to atexit.register and unregister doc
In-Reply-To: <1307634551.41.0.658857259056.issue12297@psf.upfronthosting.co.za>
Message-ID: <1329105808.71.0.202845316798.issue12297@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

+ This function returns *func* which makes it possible
add , after 'func'.

+This obviously only works with functions that ...
I think I would like this better without 'obviously' (which you inherited).

Otherwise, seems good to go to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12297>
_______________________________________

From report at bugs.python.org  Mon Feb 13 05:19:15 2012
From: report at bugs.python.org (Aaron Staley)
Date: Mon, 13 Feb 2012 04:19:15 +0000
Subject: [issue13992] Segfault in PyTrash_destroy_chain
In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za>
Message-ID: <1329106755.96.0.30227267588.issue13992@psf.upfronthosting.co.za>


Aaron Staley <usaar33 at gmail.com> added the comment:

Used latest mercurial 2.7 branch and segfault still occurs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13992>
_______________________________________

From report at bugs.python.org  Mon Feb 13 05:22:22 2012
From: report at bugs.python.org (Aaron Staley)
Date: Mon, 13 Feb 2012 04:22:22 +0000
Subject: [issue13992] Segfault in PyTrash_destroy_chain
In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za>
Message-ID: <1329106942.65.0.181245997299.issue13992@psf.upfronthosting.co.za>


Aaron Staley <usaar33 at gmail.com> added the comment:

Also, the only particular things by code does is have a lot of threads (100+), holds open many ssh connections (with paramiko) and I do occasionally use PyThreadState_SetAsyncExc to asynchronously terminate threads.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13992>
_______________________________________

From report at bugs.python.org  Mon Feb 13 05:25:13 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 13 Feb 2012 04:25:13 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1329080865.73.0.500579895781.issue13988@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda-CQNoMZy6En3HT2fgZM9NHmru7taZFHmAes-uZLDbPaQ@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

Alright, it's not really important at this point and can be cleaned up
later.

>
> I will probably commit code and documentation at once. It makes things
> easier regarding traceability.
>

Sounds good

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Mon Feb 13 06:55:43 2012
From: report at bugs.python.org (Mike Perry)
Date: Mon, 13 Feb 2012 05:55:43 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1329112543.33.0.548995460759.issue1028@psf.upfronthosting.co.za>


Mike Perry <mike at cogsmos.com> added the comment:

Hello,

I am still able to reproduce this issue with Python 3.2.2. It seems as if this bug was closed with a the note:

r70039 3.1 forward ported > 3.2 > default.  Will be in 3.2.1.

This leads me to believe that either 3.2.2 has a regression or the patch never made it into 3.2.1. 

Can anyone chime in with some more details?

Thanks,

Mike

----------
nosy: +Mike.Perry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Mon Feb 13 08:23:49 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 13 Feb 2012 07:23:49 +0000
Subject: [issue13866] {urllib,
	urllib.parse}.urlencode should not use quote_plus
In-Reply-To: <1327529522.13.0.464287316871.issue13866@psf.upfronthosting.co.za>
Message-ID: <1329117829.17.0.76311940509.issue13866@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Stephen - urlencode is responsible for producing the application/x-www-form-urlencoded  format, usually used in the FORMs in the web.
As per the spec, the Space characters are replaced by `+'. - 

http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1

What you are looking for is probably quote and quote_plus helper functions.

When I had this doubt (long back), I referred to Java's URLEncoder class to see how it was behaving and then looked at the HTML specs. It was kind of standard behavior across different libraries.  Closing this as invalid.

----------
resolution:  -> invalid
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13866>
_______________________________________

From report at bugs.python.org  Mon Feb 13 08:46:45 2012
From: report at bugs.python.org (Mike Perry)
Date: Mon, 13 Feb 2012 07:46:45 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1329119205.66.0.163603179518.issue1028@psf.upfronthosting.co.za>


Mike Perry <mike at cogsmos.com> added the comment:

Figured I should capture the exception. See below.

3.2.2+ (default, Jan  8 2012, 07:22:26) 
[GCC 4.6.2]

Traceback (most recent call last):
  File "/usr/bin/idle3", line 5, in <module>
    main()
  File "/usr/lib/python3.2/idlelib/PyShell.py", line 1429, in main
    root.mainloop()
  File "/usr/lib/python3.2/tkinter/__init__.py", line 1012, in mainloop
    self.tk.mainloop(n)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xc0 in position 0: invalid start byte

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Mon Feb 13 09:15:33 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 13 Feb 2012 08:15:33 +0000
Subject: [issue7644] bug in nntplib.body() method with possible fix
In-Reply-To: <1262773754.82.0.67564143033.issue7644@psf.upfronthosting.co.za>
Message-ID: <1329120933.81.0.845343237579.issue7644@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

Looking into the source code of nntplib, I'd claim this bug isn't valid anymore?

At least the file is opened in binary mode now ? see Lib/nntplib.py:462

In any case, we have a test suite now.

----------
nosy: +hynek
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7644>
_______________________________________

From report at bugs.python.org  Mon Feb 13 10:10:25 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 13 Feb 2012 09:10:25 +0000
Subject: [issue13992] Segfault in PyTrash_destroy_chain
In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za>
Message-ID: <1329124225.0.0.00548939242592.issue13992@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

(I'm adding Antoine to the noisy list).

You could maybe try building with '--without-pymalloc', and run under valgrind (--suppressions=Misc/valgrind-python.supp), see http://hg.python.org/cpython/file/6653328a02d0/Misc/README.valgrind

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13992>
_______________________________________

From report at bugs.python.org  Mon Feb 13 10:13:27 2012
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 13 Feb 2012 09:13:27 +0000
Subject: [issue13997] Clearly explain the bare minimum Python 3 users should
	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329124407.86.0.138867628624.issue13997@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/issue13997>
_______________________________________

From report at bugs.python.org  Mon Feb 13 10:18:01 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 13 Feb 2012 09:18:01 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329124681.11.0.863913383831.issue13988@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

FWIW the JSON doc doesn't even mention the acceleration module _json, but since people here are used to import cElementTree I think it should be mentioned that it's now deprecated and accelerations are used automatically, so something like this would work:

.. versionchanged:: 3.3
   The :mod:`xml.etree.cElementTree` module is now deprecated.
   A fast implementation will be used automatically whenever available.

I also agree with ?ric that there's no need to mention _elementtree (people might try to import that instead, and other implementations might use a different name).

Lib/test/test_xml_etree_c.py could also be removed, and the other tests could import cElementTree too (even though I'm not sure that works too well with doctests).

Shouldn't cElementTree raise an error when _elementtree is missing?
A DeprecationWarning should be added too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Mon Feb 13 10:42:40 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 13 Feb 2012 09:42:40 +0000
Subject: [issue13993] Handling of broken end tags in HTMLParser
In-Reply-To: <1328968197.87.0.293618482144.issue13993@psf.upfronthosting.co.za>
Message-ID: <E1RwsQg-0000PM-Cb@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset df5e5eea7833 by Ezio Melotti in branch '3.2':
#13993: HTMLParser is now able to handle broken end tags when strict=False.
http://hg.python.org/cpython/rev/df5e5eea7833

New changeset 2e66baa1d86a by Ezio Melotti in branch 'default':
#13993: merge with 3.2.
http://hg.python.org/cpython/rev/2e66baa1d86a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13993>
_______________________________________

From report at bugs.python.org  Mon Feb 13 10:45:36 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 13 Feb 2012 09:45:36 +0000
Subject: [issue13997] Clearly explain the bare minimum Python 3 users should
	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329126336.32.0.346013264368.issue13997@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Mon Feb 13 10:54:09 2012
From: report at bugs.python.org (Andrew Moffat)
Date: Mon, 13 Feb 2012 09:54:09 +0000
Subject: [issue14000] Subprocess stdin.flush does not flush
Message-ID: <1329126849.72.0.845817080547.issue14000@psf.upfronthosting.co.za>


New submission from Andrew Moffat <andrew.robert.moffat at gmail.com>:

The following code only works if the "p.stdin.close()" line is uncommented.  It seems that stdin only flushes to the process on stdin.close(), not on stdin.flush().

-----------------------------------

import subprocess as subp
import threading
import time


p = subp.Popen(["tr", "[:lower:]", "[:upper:]"],
    stdin=subp.PIPE, stderr=subp.PIPE, stdout=subp.PIPE, close_fds=True)


def read(stdout):
    while True:
        line = stdout.readline()
        if not line: break
        print(line.decode("utf8"))

t = threading.Thread(target=read, args=(p.stdout,))
t.daemon = True
t.start()

p.stdin.write("uppercase\n".encode())
p.stdin.flush()
#p.stdin.close()

time.sleep(1)

----------
components: None
messages: 153257
nosy: amoffat
priority: normal
severity: normal
status: open
title: Subprocess stdin.flush does not flush
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14000>
_______________________________________

From report at bugs.python.org  Mon Feb 13 11:04:54 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 13 Feb 2012 10:04:54 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <E1RwsmD-0002No-9j@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 65fc79fb4eb2 by Florent Xicluna in branch 'default':
Issue #13988: cElementTree is deprecated and the _elementtree accelerator is automatically used whenever available.
http://hg.python.org/cpython/rev/65fc79fb4eb2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Mon Feb 13 11:23:09 2012
From: report at bugs.python.org (Catalin Iacob)
Date: Mon, 13 Feb 2012 10:23:09 +0000
Subject: [issue8739] Update to smtpd.py to RFC 5321
In-Reply-To: <1274103249.44.0.284620021799.issue8739@psf.upfronthosting.co.za>
Message-ID: <1329128589.45.0.0283145685754.issue8739@psf.upfronthosting.co.za>


Changes by Catalin Iacob <iacobcatalin at gmail.com>:


----------
nosy: +catalin.iacob

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8739>
_______________________________________

From report at bugs.python.org  Mon Feb 13 12:15:19 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 13 Feb 2012 11:15:19 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <E1RwtsL-0000lw-IY@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e9cf34d56ff1 by Florent Xicluna in branch 'default':
Fix xml_etree_c test error (follow up of issue #13988).
http://hg.python.org/cpython/rev/e9cf34d56ff1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Mon Feb 13 12:55:21 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 13 Feb 2012 11:55:21 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1329134121.38.0.724916549121.issue6721@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Mon Feb 13 12:57:42 2012
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 13 Feb 2012 11:57:42 +0000
Subject: [issue13897] Move fields relevant to sys.exc_info out of frame into
	generator/threadstate
In-Reply-To: <1327767887.13.0.0676848614688.issue13897@psf.upfronthosting.co.za>
Message-ID: <1329134262.16.0.763214322859.issue13897@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

This issue was too broad. The new patch is focussed on sys.exc_info.
All hints of coroutines have been removed and f_yieldfrom is untouched.

New patch reduces code by 65 lines and does not conflict with issue 13607.

----------
title: Move fields relevant to coroutine/generators out of	frame into generator/threadstate -> Move fields relevant to sys.exc_info out of frame into generator/threadstate
Added file: http://bugs.python.org/file24508/exc_info.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13897>
_______________________________________

From report at bugs.python.org  Mon Feb 13 13:00:12 2012
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 13 Feb 2012 12:00:12 +0000
Subject: [issue13897] Move fields relevant to sys.exc_info out of frame into
	generator/threadstate
In-Reply-To: <1327767887.13.0.0676848614688.issue13897@psf.upfronthosting.co.za>
Message-ID: <1329134412.66.0.491775631907.issue13897@psf.upfronthosting.co.za>


Changes by Mark Shannon <mark at hotpy.org>:


Removed file: http://bugs.python.org/file24350/coro.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13897>
_______________________________________

From report at bugs.python.org  Mon Feb 13 13:02:32 2012
From: report at bugs.python.org (andrea crotti)
Date: Mon, 13 Feb 2012 12:02:32 +0000
Subject: [issue13991] namespace packages depending on order
In-Reply-To: <1328907203.29.0.677752935093.issue13991@psf.upfronthosting.co.za>
Message-ID: <1329134552.94.0.132463772837.issue13991@psf.upfronthosting.co.za>


andrea crotti <andrea.crotti.0 at gmail.com> added the comment:

I reopen the ticket because I'm still not convinced..

I tried to substitute the setuptools namespace declaration with the more standard python:

from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)

It behaves exactly in the same way, which makes me think that is more a problem in the importer, that doesn't behave as it should in case of namespace packages..

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13991>
_______________________________________

From report at bugs.python.org  Mon Feb 13 13:02:49 2012
From: report at bugs.python.org (Shivam)
Date: Mon, 13 Feb 2012 12:02:49 +0000
Subject: [issue13986] ValueError: cannot convert float NaN to integer
In-Reply-To: <1328874238.47.0.897260032056.issue13986@psf.upfronthosting.co.za>
Message-ID: <1329134569.47.0.971908019756.issue13986@psf.upfronthosting.co.za>


Shivam <shivam.agarwal at aricent.com> added the comment:

Hi Terry,
  Thanks for your reply.

  I am made changes suggested by you but still getting the same error:

  Below is the change that have been made:

        try:
            local_var = (os.fstat(f.fileno()).st_mtime) --> added line
            print "Value of local_var",local_var --> added line
            timestamp = long(os.fstat(f.fileno()).st_mtime)

Regards
Shivam Agarwal

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13986>
_______________________________________

From report at bugs.python.org  Mon Feb 13 13:31:17 2012
From: report at bugs.python.org (Aaron Staley)
Date: Mon, 13 Feb 2012 12:31:17 +0000
Subject: [issue13992] Segfault in PyTrash_destroy_chain
In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za>
Message-ID: <1329136277.44.0.235722072242.issue13992@psf.upfronthosting.co.za>


Aaron Staley <usaar33 at gmail.com> added the comment:

Unfortunately, my application is running so slow under valgrind that behavior is changing, namely the sockets are all timing out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13992>
_______________________________________

From report at bugs.python.org  Mon Feb 13 13:31:32 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Feb 2012 12:31:32 +0000
Subject: [issue8739] Update to smtpd.py to RFC 5321
In-Reply-To: <1274103249.44.0.284620021799.issue8739@psf.upfronthosting.co.za>
Message-ID: <1329136292.25.0.323849420701.issue8739@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Gah, that's what I get for trying to do something quick.  By changing the name of that variable I introduced a backward incompatibility, since that change was released in 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8739>
_______________________________________

From report at bugs.python.org  Mon Feb 13 13:34:52 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 13 Feb 2012 12:34:52 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329136492.99.0.581354976096.issue13988@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Now the merge is done. Thank you Eli for the effort, and to the other contributors for the review.

Following topics may need further work:

 - add a Deprecation warning for cElementTree? it will annoy the package maintainers which support both 3.2 and >= 3.3, because either they'll use the non-accelerated version in 3.2, or they will have the Deprecation warning in 3.3 ... IMHO, it's better to do nothing, and just keep the mention in the documentation that it is deprecated.

 - raise the Deprecation warnings for the functions and methods which are marked as deprecated in the documentation (the Python code does it, but not the C accelerator)

 - convert _elementtree.c Python bootstrap code to C

 - refactor the test suite


These topics are not high priority. A specific issue should be opened if any of them require some attention.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Mon Feb 13 14:07:33 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 13 Feb 2012 13:07:33 +0000
Subject: [issue13986] ValueError: cannot convert float NaN to integer
In-Reply-To: <1328874238.47.0.897260032056.issue13986@psf.upfronthosting.co.za>
Message-ID: <1329138453.78.0.85819030325.issue13986@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It's going to be tricky for any of the core Python developers to solve this based on the current level of information---unless anyone has access to a MIPs machine and can reproduce the error, that is.  Can you find a local expert who knows C to look into the issue?  The most relevant file is probably Modules/posixmodule.c.

Things to look at:

- do the stat-related values in pyconfig.h (which is generated at configure time) look correct for your platform?  Perhaps if you attach a copy of the pyconfig.h file produced at build time that could help.

- are there any relevant warnings or errors at compile time?  E.g., is there any compiler output near the point where Modules/posixmodule.c is defined?  Can you look back at the 'make' output and find out why the 'datetime' module failed to build?

What was the output from the 'print' statement that Terry suggested you add?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13986>
_______________________________________

From report at bugs.python.org  Mon Feb 13 14:35:37 2012
From: report at bugs.python.org (Tim Lesher)
Date: Mon, 13 Feb 2012 13:35:37 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1329140137.35.0.375932145811.issue3905@psf.upfronthosting.co.za>


Changes by Tim Lesher <tlesher at gmail.com>:


----------
nosy: +tlesher

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Mon Feb 13 14:45:34 2012
From: report at bugs.python.org (Jan Lieskovsky)
Date: Mon, 13 Feb 2012 13:45:34 +0000
Subject: [issue14001] Python v2.7.2 / v3.2.2 (SimpleXMLRPCServer): DoS
	(excessive CPU usage) by processing malformed XMLRPC / HTTP
	POST request
Message-ID: <1329140734.41.0.0376676358855.issue14001@psf.upfronthosting.co.za>


New submission from Jan Lieskovsky <iankko at seznam.cz>:

A denial of service flaw was found in the way Simple XML-RPC Server module of Python processed client connections, that were closed prior the complete request body has been received. A remote attacker could use this flaw to cause Python Simple XML-RPC based server process to consume excessive amount of CPU.

Credit:
Issue reported by Daniel Callaghan

References:
[1] https://bugzilla.redhat.com/show_bug.cgi?id=789790

Steps to reproduce:
------------------
A) for v3.2.2 version:

1) start server:
cat s.py 
#!/usr/local/bin/python3

from xmlrpc.server import SimpleXMLRPCServer
server = SimpleXMLRPCServer(('127.0.0.1', 12345))
server.serve_forever()

2) # top

3) issue request from client:
echo -e 'POST /RPC2 HTTP/1.0\r\nContent-Length: 100\r\n\r\nlol bye' | nc localhost 12345

Return to 'top' screen and see, how CPU consumption on particular host quickly moves to 100%.

B) for v2.7.2 version:

1) start server:

cat s.py 
#!/usr/bin/python

from SimpleXMLRPCServer import SimpleXMLRPCServer

server = SimpleXMLRPCServer(('127.0.0.1', 12345))
server.serve_forever()

Steps 2) and 3) for v2.7.2 version are identical to
those for v3.2.2 version.

----------
components: Library (Lib)
messages: 153267
nosy: iankko
priority: normal
severity: normal
status: open
title: Python v2.7.2 / v3.2.2 (SimpleXMLRPCServer): DoS (excessive CPU usage) by processing malformed XMLRPC / HTTP POST request
type: security
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14001>
_______________________________________

From report at bugs.python.org  Mon Feb 13 14:48:51 2012
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 13 Feb 2012 13:48:51 +0000
Subject: [issue14001] Python v2.7.2 / v3.2.2 (SimpleXMLRPCServer): DoS
	(excessive CPU usage) by processing malformed XMLRPC / HTTP
	POST request
In-Reply-To: <1329140734.41.0.0376676358855.issue14001@psf.upfronthosting.co.za>
Message-ID: <1329140931.98.0.966088197175.issue14001@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <python-bugs at systemexit.de>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14001>
_______________________________________

From report at bugs.python.org  Mon Feb 13 14:51:27 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 13 Feb 2012 13:51:27 +0000
Subject: [issue13992] Segfault in PyTrash_destroy_chain
In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za>
Message-ID: <1329141087.53.0.117868228644.issue13992@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Unfortunately, my application is running so slow under valgrind that 
> behavior is changing, namely the sockets are all timing out.

Did you see any invalid read/write?

By the way, a google search returned me this:
https://github.com/paramiko/paramiko/issues/17#issuecomment-2382818

The commenter says the crashes don't happen with Python 2.6.7.
If that's true, then you could try bisecting the commit (but it'll take some time).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13992>
_______________________________________

From report at bugs.python.org  Mon Feb 13 14:52:54 2012
From: report at bugs.python.org (andrea crotti)
Date: Mon, 13 Feb 2012 13:52:54 +0000
Subject: [issue13991] namespace packages depending on order
In-Reply-To: <1328907203.29.0.677752935093.issue13991@psf.upfronthosting.co.za>
Message-ID: <1329141174.33.0.0207458637526.issue13991@psf.upfronthosting.co.za>


Changes by andrea crotti <andrea.crotti.0 at gmail.com>:


----------
resolution: invalid -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13991>
_______________________________________

From report at bugs.python.org  Mon Feb 13 14:54:05 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 13 Feb 2012 13:54:05 +0000
Subject: [issue14001] Python v2.7.2 / v3.2.2 (SimpleXMLRPCServer): DoS
	(excessive CPU usage) by processing malformed XMLRPC / HTTP
	POST request
In-Reply-To: <1329140734.41.0.0376676358855.issue14001@psf.upfronthosting.co.za>
Message-ID: <1329141245.17.0.989071402098.issue14001@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, loewis
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14001>
_______________________________________

From report at bugs.python.org  Mon Feb 13 14:54:40 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 13 Feb 2012 13:54:40 +0000
Subject: [issue13992] Segfault in PyTrash_destroy_chain
In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za>
Message-ID: <1329141280.52.0.882149477686.issue13992@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> and I do occasionally use PyThreadState_SetAsyncExc to asynchronously
> terminate threads.
Did you write an extension module for this?  It is possible that there is a refcount error there.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13992>
_______________________________________

From report at bugs.python.org  Mon Feb 13 15:06:26 2012
From: report at bugs.python.org (Jan Lieskovsky)
Date: Mon, 13 Feb 2012 14:06:26 +0000
Subject: [issue14001] Python v2.7.2 / v3.2.2 (SimpleXMLRPCServer): DoS
	(excessive CPU usage) by processing malformed XMLRPC / HTTP
	POST request
In-Reply-To: <1329140734.41.0.0376676358855.issue14001@psf.upfronthosting.co.za>
Message-ID: <1329141986.53.0.939054014819.issue14001@psf.upfronthosting.co.za>


Jan Lieskovsky <iankko at seznam.cz> added the comment:

CVE request:
[2] http://www.openwall.com/lists/oss-security/2012/02/13/3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14001>
_______________________________________

From report at bugs.python.org  Mon Feb 13 15:10:59 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 13 Feb 2012 14:10:59 +0000
Subject: [issue13960] Handling of broken comments in HTMLParser
In-Reply-To: <1328615796.36.0.0693404155355.issue13960@psf.upfronthosting.co.za>
Message-ID: <E1RwwcL-0002PJ-TN@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 333e3acf2008 by Ezio Melotti in branch '2.7':
#13960: HTMLParser is now able to handle broken comments.
http://hg.python.org/cpython/rev/333e3acf2008

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13960>
_______________________________________

From report at bugs.python.org  Mon Feb 13 15:15:00 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 13 Feb 2012 14:15:00 +0000
Subject: [issue13960] Handling of broken comments in HTMLParser
In-Reply-To: <1328615796.36.0.0693404155355.issue13960@psf.upfronthosting.co.za>
Message-ID: <1329142500.19.0.214234714649.issue13960@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I now backported this to 2.7, together with some improvements in the handling of declarations that I committed on 3.2 (4c4ff9fd19b6) and 3.3 (06a6fed0da56).
Apparently <!> is not a valid comment in HTML5, but it is considered a bogus comment and should still emit a "comment" with no content.  This is now fixed too.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13960>
_______________________________________

From report at bugs.python.org  Mon Feb 13 15:18:50 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 13 Feb 2012 14:18:50 +0000
Subject: [issue14001] Python v2.7.2 / v3.2.2 (SimpleXMLRPCServer): DoS
	(excessive CPU usage) by processing malformed XMLRPC / HTTP
	POST request
In-Reply-To: <1329140734.41.0.0376676358855.issue14001@psf.upfronthosting.co.za>
Message-ID: <1329142730.54.0.900736514547.issue14001@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
components: +XML
nosy: +flox
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14001>
_______________________________________

From report at bugs.python.org  Mon Feb 13 15:29:06 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 13 Feb 2012 14:29:06 +0000
Subject: [issue13993] Handling of broken end tags in HTMLParser
In-Reply-To: <1328968197.87.0.293618482144.issue13993@psf.upfronthosting.co.za>
Message-ID: <E1Rwwts-0004Aw-KH@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a349448474ea by Ezio Melotti in branch '2.7':
#13993: HTMLParser is now able to handle broken end tags.
http://hg.python.org/cpython/rev/a349448474ea

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13993>
_______________________________________

From report at bugs.python.org  Mon Feb 13 15:29:51 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 13 Feb 2012 14:29:51 +0000
Subject: [issue13993] Handling of broken end tags in HTMLParser
In-Reply-To: <1328968197.87.0.293618482144.issue13993@psf.upfronthosting.co.za>
Message-ID: <1329143391.56.0.943285009862.issue13993@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is now fixed.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13993>
_______________________________________

From report at bugs.python.org  Mon Feb 13 15:42:16 2012
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 13 Feb 2012 14:42:16 +0000
Subject: [issue13607] Move generator specific sections out of ceval.
In-Reply-To: <1323993774.57.0.570625937446.issue13607@psf.upfronthosting.co.za>
Message-ID: <1329144136.0.0.909175824882.issue13607@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

Why do the codes used internally by ceval have to be the same as those made public?

Have you considered returning the exit code directly, rather than
adding another field to frameobject?

yieldfrom can be handled in a similar way to yield by returning the iterator (instead of the yielded value).

See attached file for example code.

----------
nosy: +Mark.Shannon
Added file: http://bugs.python.org/file24509/exit_code_example.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13607>
_______________________________________

From report at bugs.python.org  Mon Feb 13 16:21:34 2012
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 13 Feb 2012 15:21:34 +0000
Subject: [issue13903] New shared-keys dictionary implementation
In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za>
Message-ID: <1329146494.77.0.900113356075.issue13903@psf.upfronthosting.co.za>


Changes by Mark Shannon <mark at hotpy.org>:


Added file: http://bugs.python.org/file24510/691ce331f955.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13903>
_______________________________________

From report at bugs.python.org  Mon Feb 13 16:23:21 2012
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 13 Feb 2012 15:23:21 +0000
Subject: [issue13903] New shared-keys dictionary implementation
In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za>
Message-ID: <1329146601.14.0.496342983485.issue13903@psf.upfronthosting.co.za>


Changes by Mark Shannon <mark at hotpy.org>:


Removed file: http://bugs.python.org/file24465/e50db1b7ad7b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13903>
_______________________________________

From report at bugs.python.org  Mon Feb 13 16:28:11 2012
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBCYXJ0aMOpbMOpbXk=?=)
Date: Mon, 13 Feb 2012 15:28:11 +0000
Subject: [issue13979] Automatic *libc.so loading behaviour
In-Reply-To: <1328821808.41.0.811189579105.issue13979@psf.upfronthosting.co.za>
Message-ID: <1329146891.01.0.104973273759.issue13979@psf.upfronthosting.co.za>


Changes by S?bastien Barth?l?my <barthelemy at crans.org>:


----------
nosy: +sbarthelemy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13979>
_______________________________________

From report at bugs.python.org  Mon Feb 13 16:31:21 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 13 Feb 2012 15:31:21 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1329147081.3.0.0619905804077.issue10227@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Sure.  Flagging this as fixed.  Can?t close it until 10181 is closed due to some dependency thing. (perhaps someone else knows what to do?)

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10227>
_______________________________________

From report at bugs.python.org  Mon Feb 13 16:32:08 2012
From: report at bugs.python.org (Paul Moore)
Date: Mon, 13 Feb 2012 15:32:08 +0000
Subject: [issue14002] distutils2 fails to install a package from PyPI on
	Python 2.7.2
Message-ID: <1329147128.07.0.548553326464.issue14002@psf.upfronthosting.co.za>


New submission from Paul Moore <p.f.moore at gmail.com>:

I created a bdist_wininst installer for distutils2 and installed it into my Python 2.7.2 installation. This is on Wondows, 32-bit. I then tried to do a simple install to test it was working.

>python -m distutils2.run install stemming
Checking the installation location...
Getting information about 'stemming'...
extensions in requires.txt are not supported (used by u'Genshi' 0.6)
u'pywin32': u'214' is not a valid version (field 'Version')
extensions in requires.txt are not supported (used by u'sqlpython' 1.7.2)
Traceback (most recent call last):
  File "D:\Apps\Python27\lib\runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "D:\Apps\Python27\lib\runpy.py", line 72, in _run_code
    exec code in run_globals
  File "D:\Apps\Python27\lib\site-packages\distutils2\run.py", line 664, in <module>
    sys.exit(main())
  File "D:\Apps\Python27\lib\site-packages\distutils2\run.py", line 651, in main
    return dispatcher()
  File "D:\Apps\Python27\lib\site-packages\distutils2\run.py", line 639, in __call__
    return func(self, self.args)
  File "D:\Apps\Python27\lib\site-packages\distutils2\run.py", line 91, in wrapper
    return f(*args, **kwargs)
  File "D:\Apps\Python27\lib\site-packages\distutils2\run.py", line 167, in _install
    return not install(target)
  File "D:\Apps\Python27\lib\site-packages\distutils2\install.py", line 514, in install
    info = get_infos(project)
  File "D:\Apps\Python27\lib\site-packages\distutils2\install.py", line 338, in get_infos
    release = index.get_release(requirements)
  File "D:\Apps\Python27\lib\site-packages\distutils2\pypi\wrapper.py", line 28, in decorator
    if f != func.im_self and hasattr(f, func.f_name):
AttributeError: 'function' object has no attribute 'f_name'

The initial errors look like complaints about existing packages I have installed by other means (setuptools or bdist_wininst). The final one looks like a bug in distutils2, though.

----------
assignee: tarek
components: Distutils2
messages: 153278
nosy: alexis, eric.araujo, pmoore, tarek
priority: normal
severity: normal
status: open
title: distutils2 fails to install a package from PyPI on Python 2.7.2
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14002>
_______________________________________

From report at bugs.python.org  Mon Feb 13 16:39:54 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 13 Feb 2012 15:39:54 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1329147594.19.0.393113700903.issue10227@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Great. I removed the dependency since it's fixed in both cpython
and pep-3118.

----------
dependencies:  -Problems with Py_buffer management in memoryobject.c (and elsewhere?)
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10227>
_______________________________________

From report at bugs.python.org  Mon Feb 13 17:30:48 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 13 Feb 2012 16:30:48 +0000
Subject: [issue14001] Python v2.7.2 / v3.2.2 (SimpleXMLRPCServer): DoS
	(excessive CPU usage) by processing malformed XMLRPC / HTTP
	POST request
In-Reply-To: <1329140734.41.0.0376676358855.issue14001@psf.upfronthosting.co.za>
Message-ID: <1329150648.26.0.278808980452.issue14001@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/issue14001>
_______________________________________

From report at bugs.python.org  Mon Feb 13 17:37:29 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 13 Feb 2012 16:37:29 +0000
Subject: [issue14001] Python v2.7.2 / v3.2.2 (SimpleXMLRPCServer): DoS
	(excessive CPU usage) by processing malformed XMLRPC / HTTP
	POST request
In-Reply-To: <1329140734.41.0.0376676358855.issue14001@psf.upfronthosting.co.za>
Message-ID: <1329151049.18.0.714985318723.issue14001@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14001>
_______________________________________

From report at bugs.python.org  Mon Feb 13 17:40:07 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 13 Feb 2012 16:40:07 +0000
Subject: [issue14000] Subprocess stdin.flush does not flush
In-Reply-To: <1329126849.72.0.845817080547.issue14000@psf.upfronthosting.co.za>
Message-ID: <1329151207.08.0.217166924419.issue14000@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

This appears to be a buffering issue with the tr program. Replace with ["cat", "-"] and it works whether the close() is in or not.

To fix this, you need to open up the child process so that it is connected to a tty. man 4 pts if you want to investigate this further.

----------
nosy: +rosslagerwall
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14000>
_______________________________________

From report at bugs.python.org  Mon Feb 13 18:17:29 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 13 Feb 2012 17:17:29 +0000
Subject: [issue4966] Improving Lib Doc Sequence Types Section
In-Reply-To: <1232149418.64.0.0450574767427.issue4966@psf.upfronthosting.co.za>
Message-ID: <1329153449.73.0.81255682703.issue4966@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file24511/0a49f6382467.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4966>
_______________________________________

From report at bugs.python.org  Mon Feb 13 18:20:32 2012
From: report at bugs.python.org (Yuval Greenfield)
Date: Mon, 13 Feb 2012 17:20:32 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1329153632.5.0.452239857307.issue13968@psf.upfronthosting.co.za>


Yuval Greenfield <ubershmekel at gmail.com> added the comment:

I noticed this implementation on PyPI http://packages.python.org/rglob/ which sort of has rglob defined as

    def rglob(pattern, base='.'):

Which seems like the most comprehensible way of doing this, though not the most compact.

The code itself isn't in the best shape http://cpiekarski.com/2011/09/23/python-recursive-glob/ eg it uses list comprehensions instead of generators. But I think I like this API better as it really is easier to explain.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Mon Feb 13 18:21:01 2012
From: report at bugs.python.org (Alberto Trevino)
Date: Mon, 13 Feb 2012 17:21:01 +0000
Subject: [issue8739] Update to smtpd.py to RFC 5321
In-Reply-To: <1274103249.44.0.284620021799.issue8739@psf.upfronthosting.co.za>
Message-ID: <1329153661.02.0.555248397501.issue8739@psf.upfronthosting.co.za>


Alberto Trevino <alberto at byu.edu> added the comment:

David, I'd be happy to help, but I'm pretty busy for the next month. I read the description of your patch, and it sounds good to me. Anything that moves the project forward is always welcomed. Thanks for your work on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8739>
_______________________________________

From report at bugs.python.org  Mon Feb 13 18:30:26 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Feb 2012 17:30:26 +0000
Subject: [issue8739] Update to smtpd.py to RFC 5321
In-Reply-To: <1274103249.44.0.284620021799.issue8739@psf.upfronthosting.co.za>
Message-ID: <1329154226.28.0.283699504483.issue8739@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK.  Maybe someone else will want to work on it, too.  I'll see if I can get it taken care of one way or another during the PyCon sprints.

I'm going to mark this as easy, because really other than expanding test coverage I think the only thing that needs done is to fix MAIL FROM/RCPT TO.  Another pair of eyes going through the RFC would be good too, of course.  Maybe someone from the core-mentorship list will be interested.

----------
keywords: +easy
stage: test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8739>
_______________________________________

From report at bugs.python.org  Mon Feb 13 18:39:22 2012
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 13 Feb 2012 17:39:22 +0000
Subject: [issue13998] Lookbehind assertions go behind the start position for
	the match
In-Reply-To: <1329036883.7.0.662970564139.issue13998@psf.upfronthosting.co.za>
Message-ID: <1329154762.94.0.869272232004.issue13998@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

The documentation says of the 'pos' parameter "This is not completely equivalent to slicing the string" and of the 'endpos' parameter "it will be as if the string is endpos characters long".

In other words, it starts searching at 'pos' but truncates at 'endpos'.

Yes, it's inconsistent, but it's documented.

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13998>
_______________________________________

From report at bugs.python.org  Mon Feb 13 18:54:25 2012
From: report at bugs.python.org (Devin Jeanpierre)
Date: Mon, 13 Feb 2012 17:54:25 +0000
Subject: [issue13998] Lookbehind assertions go behind the start position for
	the match
In-Reply-To: <1329036883.7.0.662970564139.issue13998@psf.upfronthosting.co.za>
Message-ID: <1329155665.38.0.876537952165.issue13998@psf.upfronthosting.co.za>


Devin Jeanpierre <jeanpierreda at gmail.com> added the comment:

If it's intended behaviour, then I'd request that the documentation specifically mention lookbehind assertions the way it does with "^".

Saying "it's slightly different" doesn't make clear the ways in which it is different, and that's important for people writing or using regular expressions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13998>
_______________________________________

From report at bugs.python.org  Mon Feb 13 20:01:13 2012
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 13 Feb 2012 19:01:13 +0000
Subject: [issue13922] argparse handling multiple "--" in args improperly
In-Reply-To: <1328132556.72.0.92385645061.issue13922@psf.upfronthosting.co.za>
Message-ID: <1329159673.0.0.344914926286.issue13922@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

See nargs=argparse.REMAINDER for an approach that doesn't require that first '--':

http://docs.python.org/library/argparse.html#nargs

But yeah, removing more than one '--' is probably a bug. Fixing it would be a little backwards incompatible though. Is it possible that anyone actually depends on the behavior of consuming multiple '--' arguments?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13922>
_______________________________________

From report at bugs.python.org  Mon Feb 13 20:05:35 2012
From: report at bugs.python.org (=?utf-8?b?0KDQvtC80LDQvSDQlNC+0L3Rh9C10L3QutC+?=)
Date: Mon, 13 Feb 2012 19:05:35 +0000
Subject: [issue14003] __self__ on built-in functions is not as documented
Message-ID: <1329159935.3.0.264942191971.issue14003@psf.upfronthosting.co.za>


New submission from ????? ???????? <DXDragon at yandex.ru>:

The language reference says this in section 3.2:
 
~
Built-in functions
 
A built-in function object is a wrapper around a C function. Examples of built-in functions are len() and math.sin() <...> Special read-only attributes: <...> __self__ is set to None (but see the next item) <...>.
~

That is not the case:

ActivePython 3.2.2.3 (ActiveState Software Inc.) based on
Python 3.2.2 (default, Sep  8 2011, 10:55:13) [MSC v.1500 64 bit (AMD64)]  
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> len.__self__
<module 'builtins' (built-in)>
>>> open.__self__
<module 'io' (built-in)>
>>> import math
>>> math.sin.__self__
<module 'math' (built-in)>

----------
assignee: docs at python
components: Documentation
messages: 153287
nosy: SpecLad, docs at python
priority: normal
severity: normal
status: open
title: __self__ on built-in functions is not as documented
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14003>
_______________________________________

From report at bugs.python.org  Mon Feb 13 20:20:27 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Feb 2012 19:20:27 +0000
Subject: [issue14003] __self__ on built-in functions is not as documented
In-Reply-To: <1329159935.3.0.264942191971.issue14003@psf.upfronthosting.co.za>
Message-ID: <1329160827.21.0.514734583338.issue14003@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It looks like this changed between 2.x and 3.x but the docs were not updated.  None makes more sense than the module as __self__, though, so perhaps it is actually a bug.  Then, again, since Python functions don't have a __self__, the __self__ of built-in functions seems like an anomaly to begin with...

----------
nosy: +r.david.murray
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14003>
_______________________________________

From report at bugs.python.org  Mon Feb 13 20:27:24 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 13 Feb 2012 19:27:24 +0000
Subject: [issue13193] packaging.tests.test_manifest and
	distutils.tests.test_filelist failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1329161244.53.0.562461342345.issue13193@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Apply!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Mon Feb 13 20:34:20 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 13 Feb 2012 19:34:20 +0000
Subject: [issue13193] packaging.tests.test_manifest and
	distutils.tests.test_filelist failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <E1Rx1fH-0004GD-Dg@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3925081a7ca0 by Nadeem Vawda in branch '2.7':
Issue #13193: Fix distutils.filelist tests to always use / as path separator.
http://hg.python.org/cpython/rev/3925081a7ca0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Mon Feb 13 20:46:08 2012
From: report at bugs.python.org (Anthony Kong)
Date: Mon, 13 Feb 2012 19:46:08 +0000
Subject: [issue8739] Update to smtpd.py to RFC 5321
In-Reply-To: <1274103249.44.0.284620021799.issue8739@psf.upfronthosting.co.za>
Message-ID: <1329162368.21.0.584929258352.issue8739@psf.upfronthosting.co.za>


Changes by Anthony Kong <anthony.hw.kong at gmail.com>:


----------
nosy: +Anthony.Kong

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8739>
_______________________________________

From report at bugs.python.org  Mon Feb 13 20:59:30 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Mon, 13 Feb 2012 19:59:30 +0000
Subject: [issue13579] string.Formatter doesn't understand the !a conversion
	specifier
In-Reply-To: <1323587450.48.0.625379374057.issue13579@psf.upfronthosting.co.za>
Message-ID: <1329163170.62.0.192909252799.issue13579@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

Hi,
here's a patch with the changes proposed by Terry

Cheers,
francis

----------
keywords: +patch
nosy: +francismb
Added file: http://bugs.python.org/file24512/issue13579_80a50b7ad88f.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13579>
_______________________________________

From report at bugs.python.org  Mon Feb 13 21:00:33 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 13 Feb 2012 20:00:33 +0000
Subject: [issue13930] lib2to3 ability to output files into a different
	directory and alter their names
In-Reply-To: <1328254888.57.0.86339015419.issue13930@psf.upfronthosting.co.za>
Message-ID: <1329163233.16.0.319340195957.issue13930@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Tests are failing on all the Windows buildbots (e.g. http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/5966/steps/test/logs/stdio ).

The problem seems to be that the test in question is hardwired to expect "/" as the directory separator.

----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13930>
_______________________________________

From report at bugs.python.org  Mon Feb 13 21:01:35 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 13 Feb 2012 20:01:35 +0000
Subject: [issue8739] Update to smtpd.py to RFC 5321
In-Reply-To: <1274103249.44.0.284620021799.issue8739@psf.upfronthosting.co.za>
Message-ID: <1329163295.81.0.0157872699154.issue8739@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


----------
nosy: +hynek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8739>
_______________________________________

From report at bugs.python.org  Mon Feb 13 21:05:54 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Feb 2012 20:05:54 +0000
Subject: [issue7644] bug in nntplib.body() method with possible fix
In-Reply-To: <1262773754.82.0.67564143033.issue7644@psf.upfronthosting.co.za>
Message-ID: <1329163554.09.0.82942435515.issue7644@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

test_nntplib doesn't seem to exercise the second argument to body() (the file object). Perhaps you want to add a test for that?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7644>
_______________________________________

From report at bugs.python.org  Mon Feb 13 21:12:58 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Feb 2012 20:12:58 +0000
Subject: [issue13229] Improve tools for iterating over filesystem directories
In-Reply-To: <1319076330.7.0.757546324527.issue13229@psf.upfronthosting.co.za>
Message-ID: <1329163978.15.0.573059583936.issue13229@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Not sure this is the right place to mention this, but I'm realizing handling symlink loops will be interesting. It is "interesting" because, when e.g. you are globbing, your glob's results may not include the symlinks' target path; so there are cases where you need to keep the symlink in the results.
(and in the general case you may or may not want to keep some duplicates, depending on what you do with the links)

I am adding rglob() to pathlib and currently ignoring (i.e. crashing :-)) symlink loops. I would be interested in any ideas as to how handle them correctly.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13229>
_______________________________________

From report at bugs.python.org  Mon Feb 13 21:16:36 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Feb 2012 20:16:36 +0000
Subject: [issue13229] Improve tools for iterating over filesystem directories
In-Reply-To: <1319076330.7.0.757546324527.issue13229@psf.upfronthosting.co.za>
Message-ID: <1329164196.35.0.361622148187.issue13229@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oh, forgot to mention, the term "symlink loop" itself is ambiguous.

There are direct symlink loops: an example is a "some_dir/linky" link pointing to "../some_dir/linky". These will fail when resolving them.

There are indirect symlink loops: "some_dir/linky" pointing to "../some_dir". Resolving them works fine, but recursively walking them produces an infinite recursion.

Lots of fun :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13229>
_______________________________________

From report at bugs.python.org  Mon Feb 13 21:27:48 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 13 Feb 2012 20:27:48 +0000
Subject: [issue14001] Python v2.7.2 / v3.2.2 (SimpleXMLRPCServer): DoS
	(excessive CPU usage) by processing malformed XMLRPC / HTTP
	POST request
In-Reply-To: <1329140734.41.0.0376676358855.issue14001@psf.upfronthosting.co.za>
Message-ID: <1329164868.44.0.148053344187.issue14001@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

SimpleXMLRPCRequestHandler.do_POST() is simply looping on EOF.
The patch attached fixes this (the server doesn't seem to generate an error in response to this partial request though).

----------
keywords: +patch
nosy: +neologix
Added file: http://bugs.python.org/file24513/xmlrpc_loop.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14001>
_______________________________________

From report at bugs.python.org  Mon Feb 13 21:38:29 2012
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 13 Feb 2012 20:38:29 +0000
Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes
	lag
In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za>
Message-ID: <1329165509.18.0.247346087738.issue6085@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <python-bugs at systemexit.de>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6085>
_______________________________________

From report at bugs.python.org  Mon Feb 13 21:39:55 2012
From: report at bugs.python.org (Michael Foord)
Date: Mon, 13 Feb 2012 20:39:55 +0000
Subject: [issue14003] __self__ on built-in functions is not as documented
In-Reply-To: <1329159935.3.0.264942191971.issue14003@psf.upfronthosting.co.za>
Message-ID: <1329165595.33.0.807482837612.issue14003@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

It's nicer for introspection if __self__ is None on builtin functions. But fixing the docs is easier (and more backwards compatible).

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14003>
_______________________________________

From report at bugs.python.org  Mon Feb 13 21:46:46 2012
From: report at bugs.python.org (Stephen Day)
Date: Mon, 13 Feb 2012 20:46:46 +0000
Subject: [issue13866] {urllib,
	urllib.parse}.urlencode should not use quote_plus
In-Reply-To: <1327529522.13.0.464287316871.issue13866@psf.upfronthosting.co.za>
Message-ID: <1329166006.99.0.645855905419.issue13866@psf.upfronthosting.co.za>


Stephen Day <stevvooe at gmail.com> added the comment:

I apologize for reopening this bug, but I find your interpretation to be inaccurate. While technically valid, the combination of the documentation, the function name and the main use cases yields pathological invocations of urlencode. My bug report is to help mitigate these problems.

The main use case for "url encoding" of mapping types is not for posting form data; the main use case is appending url parameters to a url:

>>> from urllib import urlencode
>>> from urlparse import urlunparse
>>> urlunparse(('http', 'example.com', '/', None, urlencode({'a': 'some string'}), None))
'http://example.com/?a=some+string'

Any sane person would naturally gravitate to a function called "urlencode" to url encode a mapping type. If the urllib.urlencode function is indeed intended for form-encoding, as I agree is hinted in the documentation, it should indicate that its result is 'application/x-www-form-urlencoded' or it should be called "formencode".

The quote or quote_plus is not at all "what I am looking for"; I am quite familiar with these library functions. These functions are for encoding component strings; they don't meet the use case described at all:

>>> quote({'a': 1})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib.py", line 1248, in quote
    if not s.rstrip(safe):
AttributeError: 'dict' object has no attribute 'rstrip'

In addition, Java's URLEncoder implementation is hardly a good example of standards compliant URL manipulation. Python is not Java. The Python community needs to make its own, independent, mature language decisions. In general, the use of '+' to encode spaces in content, even if it is compliant against an arbitrary standard, is pathological, especially when used in urls. Even though python's quote_plus function works symmetrically on its own, when pluses are used in a multi-language environment it can become impossible to tell whether a plus is a literal '+' or an encoded space. In addition, the usage of '%20' for spaces will work in almost all cases.

RFC3986, Section 2 [1] describes the use of percent-encoding as a solution to representing reserved characters. In practice, percent-encoding is used on the value component of 'key=value' productions and this works in nearly all cases. The referenced standard [2], while relevant to the "implied" use case, is not applicable to url assembly.

Given your interpretation, it seems that there is no function in the python standard library to meet the use case of correctly assembling url parameter values, leaving application developers to come up with something like this:

>>> '&'.join(['='.join((quote(k), quote(v))) for k,v in {'a': '1', 'b': 'with spaces'}.iteritems()])
'a=1&b=with%20spaces'

In most cases, people will just use urlencode, which uses pluses for spaces, yielding pathological, noncompliant urls.

In deference to this bug closure, there are a few options:

1. Close this issue and keep polluting the world's urls with pluses for spaces.

2. Make urlencode target path/query parameter encoding and then create a new function, formencode, for use in encoding form data, breaking backwards compatibility.

3. Simply add a keyword argument to urlencode to allow the caller to specify the encoding function and separator, retaining compatibility and satisfying all of the above use cases.

Naturally, 3 seems to be a very reasonable solution to this bug.

[1] http://tools.ietf.org/html/rfc3986#section-2 explicitly covers 
[2] http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1

----------
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13866>
_______________________________________

From report at bugs.python.org  Mon Feb 13 21:48:46 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Feb 2012 20:48:46 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1329153632.5.0.452239857307.issue13968@psf.upfronthosting.co.za>
Message-ID: <1329165943.3397.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> But I think I like this API better as it really is easier to explain.

I think you got it wrong. Looking at the implementation, it is no
different from the API proposed above, except that it also lets you
choose the start dir.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Mon Feb 13 21:50:09 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 13 Feb 2012 20:50:09 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1329165382.27728.1.camel@surprise>
Message-ID: <4F39777C.40706@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Dave Malcolm wrote:
> [new patch]

Please change how the env vars work as discussed earlier on this ticket.

Quick summary:

We only need one env var for the randomization logic: PYTHONHASHSEED.
If not set, 0 is used as seed. If set to a number, a fixed seed
is used. If set to "random", a random seed is generated at
interpreter startup.

Same for the -R cmd line option.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Mon Feb 13 21:57:08 2012
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 13 Feb 2012 20:57:08 +0000
Subject: [issue14004] Distutils filelist selects too many files on Windows
Message-ID: <1329166628.27.0.616152401371.issue14004@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

When using a MANIFEST.in with only "include *.txt", on Windows, distutils grabs too many files. I set DISTUTILS_DEBUG=1 and ran ./setup.py sdist on the keyring library and it included this output:

    include *.txt
    include_pattern: applying regex r'^[^/]*\.txt\Z(?ms)'
     adding CHANGES.txt
     adding CONTRIBUTORS.txt
     adding .hg\last-message.txt
     adding keyring.egg-info\dependency_links.txt
     adding keyring.egg-info\requires.txt
     adding keyring.egg-info\SOURCES.txt
     adding keyring.egg-info\top_level.txt

As you can see, this is not a recursive include, but it's matching several files not in the supplied pattern (files in .hg/ and keyring.egg-info/).

It's obvious from the regular expression that the regex doesn't properly account for os.sep.

----------
assignee: tarek
components: Distutils
messages: 153302
nosy: eric.araujo, jason.coombs, tarek
priority: normal
severity: normal
status: open
title: Distutils filelist selects too many files on Windows
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14004>
_______________________________________

From report at bugs.python.org  Mon Feb 13 21:57:51 2012
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 13 Feb 2012 20:57:51 +0000
Subject: [issue14004] Distutils filelist selects too many files on Windows
In-Reply-To: <1329166628.27.0.616152401371.issue14004@psf.upfronthosting.co.za>
Message-ID: <1329166671.3.0.261757932213.issue14004@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
components: +Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14004>
_______________________________________

From report at bugs.python.org  Mon Feb 13 22:01:17 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 13 Feb 2012 21:01:17 +0000
Subject: [issue14004] Distutils filelist selects too many files on Windows
In-Reply-To: <1329166628.27.0.616152401371.issue14004@psf.upfronthosting.co.za>
Message-ID: <1329166877.2.0.249540850804.issue14004@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14004>
_______________________________________

From report at bugs.python.org  Mon Feb 13 22:06:36 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 13 Feb 2012 21:06:36 +0000
Subject: [issue12627] Implement PEP 394: The "python" Command on Unix-Like
	Systems
In-Reply-To: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>
Message-ID: <1329167196.74.0.961785443317.issue12627@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The 2.7 patch needs to remove an existing python2 link before creating it.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12627>
_______________________________________

From report at bugs.python.org  Mon Feb 13 22:11:44 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 13 Feb 2012 21:11:44 +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: <1329167504.24.0.90192829553.issue7475@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Mon Feb 13 22:17:56 2012
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Feb 2012 21:17:56 +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: <1329167876.26.0.0250631729123.issue7475@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

What is the status of this issue? Is there still a fan of this issue motivated to write a PEP, a patch or something like that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Mon Feb 13 21:37:13 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 13 Feb 2012 20:37:13 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1329012688.13.0.62888644637.issue13703@psf.upfronthosting.co.za>
Message-ID: <1329165382.27728.1.camel@surprise>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

On Sun, 2012-02-12 at 02:11 +0000, Gregory P. Smith wrote:
> Gregory P. Smith <greg at krypto.org> added the comment:
> 
> Comments to be addressed added on the code review.

Thanks.  I'm attaching new patches:
  add-randomization-to-2.6-dmalcolm-2012-02-13-001.patch
  add-randomization-to-3.1-dmalcolm-2012-02-13-001.patch

I incorporated the feedback from Gregory P Smith's review.

I haven't changed the way the command-line options or env variables
work, though.

Changes relative to *-2012-02-11-001.patch:
  * added versionadded 2.6.8 and 3.1.5 to hash_randomization/-R within
Docs/library/sys.rst and Docs/using/cmdline.rst (these will need
changing to "2.7.3" and "3.2.3" in the forward ports to the 2.7 and 3.2
branches)
  * fixed line wrapping within the --help text in Modules/main.c
  * reverted text of urandom__doc__
  * added comments about the specialcasing of length 0:
    /*
      We make the hash of the empty string be 0, rather than using
      (prefix ^ suffix), since this slightly obfuscates the hash secret
    */
    (see discussion in http://bugs.python.org/issue13703#msg151664
onwards)

I didn't change the range of values for PYTHONHASHSEED on 64-bit

----------
Added file: http://bugs.python.org/file24514/add-randomization-to-2.6-dmalcolm-2012-02-13-001.patch
Added file: http://bugs.python.org/file24515/add-randomization-to-3.1-dmalcolm-2012-02-13-001.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________
-------------- next part --------------
diff -r 9a4131ada792 Doc/library/sys.rst
--- a/Doc/library/sys.rst	Fri Jan 27 09:42:45 2012 +0100
+++ b/Doc/library/sys.rst	Mon Feb 13 15:34:04 2012 -0500
@@ -289,6 +289,10 @@
    +------------------------------+------------------------------------------+
    | :const:`bytes_warning`       | -b                                       |
    +------------------------------+------------------------------------------+
+   | :const:`hash_randomization`  | -R                                       |
+   |                              |                                          |
+   |                              | .. versionadded:: 2.6.8                  |
+   +------------------------------+------------------------------------------+
 
    .. versionadded:: 2.6
 
diff -r 9a4131ada792 Doc/reference/datamodel.rst
--- a/Doc/reference/datamodel.rst	Fri Jan 27 09:42:45 2012 +0100
+++ b/Doc/reference/datamodel.rst	Mon Feb 13 15:34:04 2012 -0500
@@ -1273,6 +1273,8 @@
       modules are still available at the time when the :meth:`__del__` method is
       called.
 
+   See also the :option:`-R` command-line option.
+
 
 .. method:: object.__repr__(self)
 
diff -r 9a4131ada792 Doc/using/cmdline.rst
--- a/Doc/using/cmdline.rst	Fri Jan 27 09:42:45 2012 +0100
+++ b/Doc/using/cmdline.rst	Mon Feb 13 15:34:04 2012 -0500
@@ -21,7 +21,7 @@
 
 When invoking Python, you may specify any of these options::
 
-    python [-BdEiOQsStuUvVWxX3?] [-c command | -m module-name | script | - ] [args]
+    python [-BdEiOQsRStuUvVWxX3?] [-c command | -m module-name | script | - ] [args]
 
 The most common use case is, of course, a simple invocation of a script::
 
@@ -239,6 +239,32 @@
       :pep:`238` -- Changing the division operator
 
 
+.. cmdoption:: -R
+
+   Turn on hash randomization, so that the :meth:`__hash__` values of str,
+   bytes and datetime objects are "salted" with an unpredictable random value.
+   Although they remain constant within an individual Python process, they
+   are not predictable between repeated invocations of Python.
+
+   This is intended to provide protection against a denial-of-service
+   caused by carefully-chosen inputs that exploit the worst case performance
+   of a dict lookup, O(n^2) complexity.  See:
+
+       http://www.ocert.org/advisories/ocert-2011-003.html
+
+   for details.
+
+   Changing hash values affects the order in which keys are retrieved from
+   a dict.  Although Python has never made guarantees about this ordering
+   (and it typically varies between 32-bit and 64-bit builds), enough
+   real-world code implicitly relies on this non-guaranteed behavior that
+   the randomization is disabled by default.
+
+   See also :envvar:`PYTHONHASHRANDOMIZATION`.
+
+   .. versionadded:: 2.6.8
+
+
 .. cmdoption:: -s
 
    Don't add user site directory to sys.path
@@ -501,6 +527,34 @@
 
    .. versionadded:: 2.6
 
+.. envvar:: PYTHONHASHRANDOMIZATION
+
+   If this is set to a non-empty string it is equivalent to specifying the
+   :option:`-R` option.
+
+   .. versionadded:: 2.6.8
+
+
+.. envvar:: PYTHONHASHSEED
+
+   This environment variable only has an effect when hash randomization has
+   been enabled (via the :option:`-R` option, or its equivalent environment
+   variable, :envvar:`PYTHONHASHRANDOMIZATION`).
+
+   If :envvar:`PYTHONHASHSEED` is set, it is used as a fixed seed for
+   generating the hash() of the types covered by the hash randomization.
+
+   Its purpose is to allow repeatable hashing, such as for selftests for the
+   interpreter itself, or to allow a cluster of python processes to share hash
+   values.
+
+   It should be a decimal number in the range [0; 4294967295].  Specifying
+   the value 0 will lead to the same hash values as when hash randomization
+   is disabled.
+
+   .. versionadded:: 2.6.8
+
+
 .. envvar:: PYTHONIOENCODING
 
    Overrides the encoding used for stdin/stdout/stderr, in the syntax
diff -r 9a4131ada792 Include/object.h
--- a/Include/object.h	Fri Jan 27 09:42:45 2012 +0100
+++ b/Include/object.h	Mon Feb 13 15:34:04 2012 -0500
@@ -506,6 +506,12 @@
 PyAPI_FUNC(long) _Py_HashDouble(double);
 PyAPI_FUNC(long) _Py_HashPointer(void*);
 
+typedef struct {
+    long prefix;
+    long suffix;
+} _Py_HashSecret_t;
+PyAPI_DATA(_Py_HashSecret_t) _Py_HashSecret;
+
 /* Helper for passing objects to printf and the like */
 #define PyObject_REPR(obj) PyString_AS_STRING(PyObject_Repr(obj))
 
diff -r 9a4131ada792 Include/pydebug.h
--- a/Include/pydebug.h	Fri Jan 27 09:42:45 2012 +0100
+++ b/Include/pydebug.h	Mon Feb 13 15:34:04 2012 -0500
@@ -26,6 +26,7 @@
 PyAPI_DATA(int) _Py_QnewFlag;
 /* Warn about 3.x issues */
 PyAPI_DATA(int) Py_Py3kWarningFlag;
+PyAPI_DATA(int) Py_HashRandomizationFlag;
 
 /* this is a wrapper around getenv() that pays attention to
    Py_IgnoreEnvironmentFlag.  It should be used for getting variables like
diff -r 9a4131ada792 Include/pythonrun.h
--- a/Include/pythonrun.h	Fri Jan 27 09:42:45 2012 +0100
+++ b/Include/pythonrun.h	Mon Feb 13 15:34:04 2012 -0500
@@ -168,6 +168,8 @@
 PyAPI_FUNC(PyOS_sighandler_t) PyOS_getsig(int);
 PyAPI_FUNC(PyOS_sighandler_t) PyOS_setsig(int, PyOS_sighandler_t);
 
+/* Random */
+PyAPI_FUNC(int) _PyOS_URandom (void *buffer, Py_ssize_t size);
 
 #ifdef __cplusplus
 }
diff -r 9a4131ada792 Lib/os.py
--- a/Lib/os.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/os.py	Mon Feb 13 15:34:04 2012 -0500
@@ -742,22 +742,3 @@
                      _make_statvfs_result)
 except NameError: # statvfs_result may not exist
     pass
-
-if not _exists("urandom"):
-    def urandom(n):
-        """urandom(n) -> str
-
-        Return a string of n random bytes suitable for cryptographic use.
-
-        """
-        try:
-            _urandomfd = open("/dev/urandom", O_RDONLY)
-        except (OSError, IOError):
-            raise NotImplementedError("/dev/urandom (or equivalent) not found")
-        try:
-            bs = b""
-            while n - len(bs) >= 1:
-                bs += read(_urandomfd, n - len(bs))
-        finally:
-            close(_urandomfd)
-        return bs
diff -r 9a4131ada792 Lib/test/test_cmd_line.py
--- a/Lib/test/test_cmd_line.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_cmd_line.py	Mon Feb 13 15:34:04 2012 -0500
@@ -103,6 +103,20 @@
             self.exit_code('-c', 'pass'),
             0)
 
+    def test_hash_randomization(self):
+        # Verify that -R enables hash randomization:
+        self.verify_valid_flag('-R')
+        hashes = []
+        for i in range(2):
+            code = 'print(hash("spam"))'
+            data = self.start_python('-R', '-c', code)
+            hashes.append(data)
+        self.assertNotEqual(hashes[0], hashes[1])
+
+        # Verify that sys.flags contains hash_randomization
+        code = 'import sys; print(sys.flags)'
+        data = self.start_python('-R', '-c', code)
+        self.assertTrue('hash_randomization=1' in data)
 
 def test_main():
     test.test_support.run_unittest(CmdLineTest)
diff -r 9a4131ada792 Lib/test/test_hash.py
--- a/Lib/test/test_hash.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_hash.py	Mon Feb 13 15:34:04 2012 -0500
@@ -3,10 +3,15 @@
 #
 # Also test that hash implementations are inherited as expected
 
+import os
+import struct
+import subprocess
+import sys
 import unittest
 from test import test_support
 from collections import Hashable
 
+IS_64BIT = (struct.calcsize('l') == 8)
 
 class HashEqualityTestCase(unittest.TestCase):
 
@@ -133,10 +138,85 @@
         for obj in self.hashes_to_check:
             self.assertEqual(hash(obj), _default_hash(obj))
 
+class HashRandomizationTests(unittest.TestCase):
+
+    # Each subclass should define a field "repr_", containing the repr() of
+    # an object to be tested
+
+    def get_hash_command(self, repr_):
+        return 'print(hash(%s))' % repr_
+
+    def get_hash(self, repr_, randomization=None, seed=None):
+        env = os.environ.copy()
+        if randomization is not None:
+            env['PYTHONHASHRANDOMIZATION'] = str(randomization)
+        if seed is not None:
+            env['PYTHONHASHSEED'] = str(seed)
+        cmd_line = [sys.executable,
+                    '-c', self.get_hash_command(repr_)]
+        p = subprocess.Popen(cmd_line, stdin=subprocess.PIPE,
+                             stdout=subprocess.PIPE, stderr=subprocess.STDOUT,
+                             env=env)
+        out, err = p.communicate()
+        out = test_support.strip_python_stderr(out)
+        return int(out.strip())
+
+    def test_randomized_hash(self):
+        # two runs should return different hashes
+        run1 = self.get_hash(self.repr_, randomization=1)
+        run2 = self.get_hash(self.repr_, randomization=1)
+        self.assertNotEqual(run1, run2)
+
+class StringlikeHashRandomizationTests(HashRandomizationTests):
+    def test_null_hash(self):
+        # PYTHONHASHSEED=0 disables the randomized hash
+        if IS_64BIT:
+            known_hash_of_obj = 1453079729188098211
+        else:
+            known_hash_of_obj = -1600925533
+
+        # Randomization is disabled by default:
+        self.assertEqual(self.get_hash(self.repr_), known_hash_of_obj)
+
+        # If enabled, it can still be disabled by setting the seed to 0:
+        self.assertEqual(self.get_hash(self.repr_, randomization=1, seed=0),
+                         known_hash_of_obj)
+
+    def test_fixed_hash(self):
+        # test a fixed seed for the randomized hash
+        # Note that all types share the same values:
+        if IS_64BIT:
+            h = -4410911502303878509
+        else:
+            h = -206076799
+        self.assertEqual(self.get_hash(self.repr_, randomization=1, seed=42),
+                         h)
+
+class StrHashRandomizationTests(StringlikeHashRandomizationTests):
+    repr_ = repr('abc')
+
+    def test_empty_string(self):
+        self.assertEqual(hash(""), 0)
+
+class UnicodeHashRandomizationTests(StringlikeHashRandomizationTests):
+    repr_ = repr(u'abc')
+
+    def test_empty_string(self):
+        self.assertEqual(hash(u""), 0)
+
+class BufferHashRandomizationTests(StringlikeHashRandomizationTests):
+    repr_ = 'buffer("abc")'
+
+    def test_empty_string(self):
+        self.assertEqual(hash(buffer("")), 0)
+
 def test_main():
     test_support.run_unittest(HashEqualityTestCase,
                               HashInheritanceTestCase,
-                              HashBuiltinsTestCase)
+                              HashBuiltinsTestCase,
+                              StrHashRandomizationTests,
+                              UnicodeHashRandomizationTests,
+                              BufferHashRandomizationTests)
 
 
 if __name__ == "__main__":
diff -r 9a4131ada792 Lib/test/test_os.py
--- a/Lib/test/test_os.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_os.py	Mon Feb 13 15:34:04 2012 -0500
@@ -5,6 +5,7 @@
 import os
 import unittest
 import warnings
+import subprocess
 import sys
 from test import test_support
 
@@ -499,18 +500,46 @@
 
 class URandomTests (unittest.TestCase):
     def test_urandom(self):
-        try:
-            with test_support.check_warnings():
-                self.assertEqual(len(os.urandom(1)), 1)
-                self.assertEqual(len(os.urandom(10)), 10)
-                self.assertEqual(len(os.urandom(100)), 100)
-                self.assertEqual(len(os.urandom(1000)), 1000)
-                # see http://bugs.python.org/issue3708
-                self.assertEqual(len(os.urandom(0.9)), 0)
-                self.assertEqual(len(os.urandom(1.1)), 1)
-                self.assertEqual(len(os.urandom(2.0)), 2)
-        except NotImplementedError:
-            pass
+        with test_support.check_warnings():
+            self.assertEqual(len(os.urandom(1)), 1)
+            self.assertEqual(len(os.urandom(10)), 10)
+            self.assertEqual(len(os.urandom(100)), 100)
+            self.assertEqual(len(os.urandom(1000)), 1000)
+            # see http://bugs.python.org/issue3708
+            self.assertEqual(len(os.urandom(0.9)), 0)
+            self.assertEqual(len(os.urandom(1.1)), 1)
+            self.assertEqual(len(os.urandom(2.0)), 2)
+
+    def test_urandom_length(self):
+        self.assertEqual(len(os.urandom(0)), 0)
+        self.assertEqual(len(os.urandom(1)), 1)
+        self.assertEqual(len(os.urandom(10)), 10)
+        self.assertEqual(len(os.urandom(100)), 100)
+        self.assertEqual(len(os.urandom(1000)), 1000)
+
+    def test_urandom_value(self):
+        data1 = os.urandom(16)
+        data2 = os.urandom(16)
+        self.assertNotEqual(data1, data2)
+
+    def get_urandom_subprocess(self, count):
+        code = '\n'.join((
+            'import os, sys',
+            'data = os.urandom(%s)' % count,
+            'sys.stdout.write(data)'))
+        cmd_line = [sys.executable,
+                    '-c', code]
+        p = subprocess.Popen(cmd_line, stdin=subprocess.PIPE,
+                             stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
+        out, err = p.communicate()
+        out = test_support.strip_python_stderr(out)
+        self.assertEqual(len(out), count)
+        return out
+
+    def test_urandom_subprocess(self):
+        data1 = self.get_urandom_subprocess(16)
+        data2 = self.get_urandom_subprocess(16)
+        self.assertNotEqual(data1, data2)
 
 class Win32ErrorTests(unittest.TestCase):
     def test_rename(self):
diff -r 9a4131ada792 Lib/test/test_set.py
--- a/Lib/test/test_set.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_set.py	Mon Feb 13 15:34:04 2012 -0500
@@ -688,6 +688,17 @@
         if self.repr is not None:
             self.assertEqual(repr(self.set), self.repr)
 
+    def check_repr_against_values(self):
+        text = repr(self.set)
+        self.assertTrue(text.startswith('{'))
+        self.assertTrue(text.endswith('}'))
+
+        result = text[1:-1].split(', ')
+        result.sort()
+        sorted_repr_values = [repr(value) for value in self.values]
+        sorted_repr_values.sort()
+        self.assertEqual(result, sorted_repr_values)
+
     def test_print(self):
         fo = open(test_support.TESTFN, "wb")
         try:
diff -r 9a4131ada792 Lib/test/test_support.py
--- a/Lib/test/test_support.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_support.py	Mon Feb 13 15:34:04 2012 -0500
@@ -893,3 +893,13 @@
                     break
             except:
                 break
+
+def strip_python_stderr(stderr):
+    """Strip the stderr of a Python process from potential debug output
+    emitted by the interpreter.
+
+    This will typically be run on the result of the communicate() method
+    of a subprocess.Popen object.
+    """
+    stderr = re.sub(br"\[\d+ refs\]\r?\n?$", b"", stderr).strip()
+    return stderr
diff -r 9a4131ada792 Lib/test/test_sys.py
--- a/Lib/test/test_sys.py	Fri Jan 27 09:42:45 2012 +0100
+++ b/Lib/test/test_sys.py	Mon Feb 13 15:34:04 2012 -0500
@@ -384,7 +384,7 @@
         attrs = ("debug", "py3k_warning", "division_warning", "division_new",
                  "inspect", "interactive", "optimize", "dont_write_bytecode",
                  "no_site", "ignore_environment", "tabcheck", "verbose",
-                 "unicode", "bytes_warning")
+                 "unicode", "bytes_warning", "hash_randomization")
         for attr in attrs:
             self.assert_(hasattr(sys.flags, attr), attr)
             self.assertEqual(type(getattr(sys.flags, attr)), int, attr)
diff -r 9a4131ada792 Makefile.pre.in
--- a/Makefile.pre.in	Fri Jan 27 09:42:45 2012 +0100
+++ b/Makefile.pre.in	Mon Feb 13 15:34:04 2012 -0500
@@ -280,6 +280,7 @@
 		Python/pymath.o \
 		Python/pystate.o \
 		Python/pythonrun.o \
+		Python/random.o \
 		Python/structmember.o \
 		Python/symtable.o \
 		Python/sysmodule.o \
diff -r 9a4131ada792 Misc/NEWS
--- a/Misc/NEWS	Fri Jan 27 09:42:45 2012 +0100
+++ b/Misc/NEWS	Mon Feb 13 15:34:04 2012 -0500
@@ -10,6 +10,12 @@
 Core and Builtins
 -----------------
 
+- Issue #13703: oCERT-2011-003: add -R command-line option and
+  PYTHONHASHRANDOMIZATION (and PYTHONHASHSEED) environment variables, to
+  provide an opt-in way to protect against denial of service attacks due to
+  hash collisions within the dict and set types.  Patch by David Malcolm,
+  based on work by Victor Stinner.
+
 Library
 -------
 
diff -r 9a4131ada792 Misc/python.man
--- a/Misc/python.man	Fri Jan 27 09:42:45 2012 +0100
+++ b/Misc/python.man	Mon Feb 13 15:34:04 2012 -0500
@@ -34,6 +34,9 @@
 .B \-O0
 ]
 [
+.B \-R
+]
+[
 .B -Q
 .I argument
 ]
@@ -151,6 +154,18 @@
 .B \-O0
 Discard docstrings in addition to the \fB-O\fP optimizations.
 .TP
+.B \-R
+Turn on "hash randomization", so that the hash() values of str, bytes and
+datetime objects are "salted" with an unpredictable pseudo-random value.
+Although they remain constant within an individual Python process, they are
+not predictable between repeated invocations of Python.
+.IP
+This is intended to provide protection against a denial of service
+caused by carefully-chosen inputs that exploit the worst case performance
+of a dict lookup, O(n^2) complexity.  See
+http://www.ocert.org/advisories/ocert-2011-003.html
+for details.
+.TP
 .BI "\-Q " argument
 Division control; see PEP 238.  The argument must be one of "old" (the
 default, int/int and long/long return an int or long), "new" (new
@@ -411,6 +426,24 @@
 If this is set to a non-empty string it is equivalent to specifying
 the \fB\-v\fP option. If set to an integer, it is equivalent to
 specifying \fB\-v\fP multiple times. 
+.IP PYTHONHASHRANDOMIZATION
+If this is set to a non-empty string it is equivalent to specifying the
+\fB\-R\fP option.
+.IP PYTHONHASHSEED
+This environment variable only has an effect when hash randomization has
+been enabled (via the \fB\-R\fP option, or its equivalent environment
+variable, \fB\PYTHONHASHRANDOMIZATION\fP).
+
+If PYTHONHASHSEED is set, it is used as a fixed seed for
+generating the hash() of the types covered by the hash randomization.
+
+Its purpose is to allow repeatable hashing, such as for selftests for the
+interpreter itself, or to allow a cluster of python processes to share hash
+values.
+
+It should be a decimal number in the range [0; 4294967295].  Specifying
+the value 0 will lead to the same hash values as when hash randomization
+is disabled.
 .SH AUTHOR
 The Python Software Foundation: http://www.python.org/psf
 .SH INTERNET RESOURCES
diff -r 9a4131ada792 Modules/main.c
--- a/Modules/main.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Modules/main.c	Mon Feb 13 15:34:04 2012 -0500
@@ -40,7 +40,7 @@
 static int  orig_argc;
 
 /* command line options */
-#define BASE_OPTS "3bBc:dEhiJm:OQ:sStuUvVW:xX?"
+#define BASE_OPTS "3bBc:dEhiJm:OQ:RsStuUvVW:xX?"
 
 #ifndef RISCOS
 #define PROGRAM_OPTS BASE_OPTS
@@ -72,6 +72,9 @@
 -O     : optimize generated bytecode slightly; also PYTHONOPTIMIZE=x\n\
 -OO    : remove doc-strings in addition to the -O optimizations\n\
 -Q arg : division options: -Qold (default), -Qwarn, -Qwarnall, -Qnew\n\
+-R     : use a pseudo-random salt to make hash() values of various types be\n\
+         unpredictable between separate invocations of the interpreter, as\n\
+         a defence against denial-of-service attacks\n\
 -s     : don't add user site directory to sys.path; also PYTHONNOUSERSITE\n\
 -S     : don't imply 'import site' on initialization\n\
 -t     : issue warnings about inconsistent tab usage (-tt: issue errors)\n\
@@ -101,6 +104,22 @@
 PYTHONCASEOK : ignore case in 'import' statements (Windows).\n\
 PYTHONIOENCODING: Encoding[:errors] used for stdin/stdout/stderr.\n\
 ";
+static char *usage_6 = "\
+PYTHONHASHRANDOMIZATION : make hash() values of various types be\n\
+   unpredictable between separate invocations of the interpreter, as a\n\
+   defence against denial-of-service attacks\n\
+PYTHONHASHSEED: this environment variable only has an effect when hash\n\
+   randomization has been enabled (via the -R option, or its equivalent\n\
+   environment variable, PYTHONHASHRANDOMIZATION)\n\
+   If set, it is used as a fixed seed for generating the hash() of the types\n\
+   covered by the hash randomization\n\
+   Its purpose is to allow repeatable hashing, such as for selftests for the\n\
+   interpreter itself, or to allow a cluster of python processes to share\n\
+   hash values.\n\
+   It should be a decimal number in the range [0; 4294967295]. Specifying\n\
+   the value 0 will lead to the same hash values as when hash randomization\n\
+   is disabled.\n\
+";
 
 
 static int
@@ -117,6 +136,7 @@
         fputs(usage_3, f);
         fprintf(f, usage_4, DELIM);
         fprintf(f, usage_5, DELIM, PYTHONHOMEHELP);
+        fputs(usage_6, f);
     }
 #if defined(__VMS)
     if (exitcode == 0) {
@@ -388,6 +408,10 @@
             PySys_AddWarnOption(_PyOS_optarg);
             break;
 
+        case 'R':
+            Py_HashRandomizationFlag++;
+            break;
+
         /* This space reserved for other options */
 
         default:
diff -r 9a4131ada792 Modules/posixmodule.c
--- a/Modules/posixmodule.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Modules/posixmodule.c	Mon Feb 13 15:34:04 2012 -0500
@@ -8371,117 +8371,35 @@
 }
 #endif
 
-#ifdef MS_WINDOWS
-
-PyDoc_STRVAR(win32_urandom__doc__,
+PyDoc_STRVAR(posix_urandom__doc__,
 "urandom(n) -> str\n\n\
-Return a string of n random bytes suitable for cryptographic use.");
-
-typedef BOOL (WINAPI *CRYPTACQUIRECONTEXTA)(HCRYPTPROV *phProv,\
-              LPCSTR pszContainer, LPCSTR pszProvider, DWORD dwProvType,\
-              DWORD dwFlags );
-typedef BOOL (WINAPI *CRYPTGENRANDOM)(HCRYPTPROV hProv, DWORD dwLen,\
-              BYTE *pbBuffer );
-
-static CRYPTGENRANDOM pCryptGenRandom = NULL;
-/* This handle is never explicitly released. Instead, the operating
-   system will release it when the process terminates. */
-static HCRYPTPROV hCryptProv = 0;
-
-static PyObject*
-win32_urandom(PyObject *self, PyObject *args)
-{
-    int howMany;
-    PyObject* result;
-
-    /* Read arguments */
-    if (! PyArg_ParseTuple(args, "i:urandom", &howMany))
-        return NULL;
-    if (howMany < 0)
-        return PyErr_Format(PyExc_ValueError,
-                            "negative argument not allowed");
-
-    if (hCryptProv == 0) {
-        HINSTANCE hAdvAPI32 = NULL;
-        CRYPTACQUIRECONTEXTA pCryptAcquireContext = NULL;
-
-        /* Obtain handle to the DLL containing CryptoAPI
-           This should not fail         */
-        hAdvAPI32 = GetModuleHandle("advapi32.dll");
-        if(hAdvAPI32 == NULL)
-            return win32_error("GetModuleHandle", NULL);
-
-        /* Obtain pointers to the CryptoAPI functions
-           This will fail on some early versions of Win95 */
-        pCryptAcquireContext = (CRYPTACQUIRECONTEXTA)GetProcAddress(
-                                        hAdvAPI32,
-                                        "CryptAcquireContextA");
-        if (pCryptAcquireContext == NULL)
-            return PyErr_Format(PyExc_NotImplementedError,
-                                "CryptAcquireContextA not found");
-
-        pCryptGenRandom = (CRYPTGENRANDOM)GetProcAddress(
-                                        hAdvAPI32, "CryptGenRandom");
-        if (pCryptGenRandom == NULL)
-            return PyErr_Format(PyExc_NotImplementedError,
-                                "CryptGenRandom not found");
-
-        /* Acquire context */
-        if (! pCryptAcquireContext(&hCryptProv, NULL, NULL,
-                                   PROV_RSA_FULL, CRYPT_VERIFYCONTEXT))
-            return win32_error("CryptAcquireContext", NULL);
-    }
-
-    /* Allocate bytes */
-    result = PyString_FromStringAndSize(NULL, howMany);
-    if (result != NULL) {
-        /* Get random data */
-        memset(PyString_AS_STRING(result), 0, howMany); /* zero seed */
-        if (! pCryptGenRandom(hCryptProv, howMany, (unsigned char*)
-                              PyString_AS_STRING(result))) {
-            Py_DECREF(result);
-            return win32_error("CryptGenRandom", NULL);
-        }
+Return n random bytes suitable for cryptographic use.");
+
+static PyObject *
+posix_urandom(PyObject *self, PyObject *args)
+{
+    Py_ssize_t size;
+    PyObject *result;
+    int ret;
+ 
+     /* Read arguments */
+    if (!PyArg_ParseTuple(args, "n:urandom", &size))
+        return NULL;
+    if (size < 0)
+         return PyErr_Format(PyExc_ValueError,
+                             "negative argument not allowed");
+    result = PyBytes_FromStringAndSize(NULL, size);
+    if (result == NULL)
+        return NULL;
+
+    ret = _PyOS_URandom(PyBytes_AS_STRING(result),
+                        PyBytes_GET_SIZE(result));
+    if (ret == -1) {
+        Py_DECREF(result);
+        return NULL;
     }
     return result;
 }
-#endif
-
-#ifdef __VMS
-/* Use openssl random routine */
-#include <openssl/rand.h>
-PyDoc_STRVAR(vms_urandom__doc__,
-"urandom(n) -> str\n\n\
-Return a string of n random bytes suitable for cryptographic use.");
-
-static PyObject*
-vms_urandom(PyObject *self, PyObject *args)
-{
-    int howMany;
-    PyObject* result;
-
-    /* Read arguments */
-    if (! PyArg_ParseTuple(args, "i:urandom", &howMany))
-        return NULL;
-    if (howMany < 0)
-        return PyErr_Format(PyExc_ValueError,
-                            "negative argument not allowed");
-
-    /* Allocate bytes */
-    result = PyString_FromStringAndSize(NULL, howMany);
-    if (result != NULL) {
-        /* Get random data */
-        if (RAND_pseudo_bytes((unsigned char*)
-                              PyString_AS_STRING(result),
-                              howMany) < 0) {
-            Py_DECREF(result);
-            return PyErr_Format(PyExc_ValueError,
-                                "RAND_pseudo_bytes");
-        }
-    }
-    return result;
-}
-#endif
 
 static PyMethodDef posix_methods[] = {
     {"access",          posix_access, METH_VARARGS, posix_access__doc__},
@@ -8787,12 +8705,7 @@
 #ifdef HAVE_GETLOADAVG
     {"getloadavg",      posix_getloadavg, METH_NOARGS, posix_getloadavg__doc__},
 #endif
- #ifdef MS_WINDOWS
-    {"urandom", win32_urandom, METH_VARARGS, win32_urandom__doc__},
- #endif
- #ifdef __VMS
-    {"urandom", vms_urandom, METH_VARARGS, vms_urandom__doc__},
- #endif
+    {"urandom",         posix_urandom,   METH_VARARGS, posix_urandom__doc__},
     {NULL,              NULL}            /* Sentinel */
 };
 
diff -r 9a4131ada792 Objects/bufferobject.c
--- a/Objects/bufferobject.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Objects/bufferobject.c	Mon Feb 13 15:34:04 2012 -0500
@@ -334,10 +334,20 @@
         return -1;
     p = (unsigned char *) ptr;
     len = size;
-    x = *p << 7;
+    /*
+      We make the hash of the empty buffer be 0, rather than using
+      (prefix ^ suffix), since this slightly obfuscates the hash secret
+    */
+    if (len == 0) {
+        self->b_hash = 0;
+        return 0;
+    }
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= size;
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
     self->b_hash = x;
diff -r 9a4131ada792 Objects/object.c
--- a/Objects/object.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Objects/object.c	Mon Feb 13 15:34:04 2012 -0500
@@ -1101,6 +1101,8 @@
     return -1;
 }
 
+_Py_HashSecret_t _Py_HashSecret;
+
 long
 PyObject_Hash(PyObject *v)
 {
diff -r 9a4131ada792 Objects/stringobject.c
--- a/Objects/stringobject.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Objects/stringobject.c	Mon Feb 13 15:34:04 2012 -0500
@@ -1212,11 +1212,21 @@
     if (a->ob_shash != -1)
         return a->ob_shash;
     len = Py_SIZE(a);
+    /*
+      We make the hash of the empty string be 0, rather than using
+      (prefix ^ suffix), since this slightly obfuscates the hash secret
+    */
+    if (len == 0) {
+        a->ob_shash = 0;
+        return 0;
+    }
     p = (unsigned char *) a->ob_sval;
-    x = *p << 7;
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= Py_SIZE(a);
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
     a->ob_shash = x;
diff -r 9a4131ada792 Objects/unicodeobject.c
--- a/Objects/unicodeobject.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Objects/unicodeobject.c	Mon Feb 13 15:34:04 2012 -0500
@@ -6695,11 +6695,21 @@
     if (self->hash != -1)
         return self->hash;
     len = PyUnicode_GET_SIZE(self);
+    /*
+      We make the hash of the empty string be 0, rather than using
+      (prefix ^ suffix), since this slightly obfuscates the hash secret
+    */
+    if (len == 0) {
+        self->hash = 0;
+        return 0;
+    }
     p = PyUnicode_AS_UNICODE(self);
-    x = *p << 7;
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= PyUnicode_GET_SIZE(self);
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
     self->hash = x;
diff -r 9a4131ada792 PCbuild/pythoncore.vcproj
--- a/PCbuild/pythoncore.vcproj	Fri Jan 27 09:42:45 2012 +0100
+++ b/PCbuild/pythoncore.vcproj	Mon Feb 13 15:34:04 2012 -0500
@@ -1779,6 +1779,10 @@
 				>
 			</File>
 			<File
+				RelativePath="..\Python\random.c"
+				>
+			</File>
+			<File
 				RelativePath="..\Python\structmember.c"
 				>
 			</File>
diff -r 9a4131ada792 Python/pythonrun.c
--- a/Python/pythonrun.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Python/pythonrun.c	Mon Feb 13 15:34:04 2012 -0500
@@ -67,6 +67,7 @@
 static void call_ll_exitfuncs(void);
 extern void _PyUnicode_Init(void);
 extern void _PyUnicode_Fini(void);
+extern void _PyRandom_Init(void);
 
 #ifdef WITH_THREAD
 extern void _PyGILState_Init(PyInterpreterState *, PyThreadState *);
@@ -89,6 +90,7 @@
   true divisions (which they will be in 2.3). */
 int _Py_QnewFlag = 0;
 int Py_NoUserSiteDirectory = 0; /* for -s and site.py */
+int Py_HashRandomizationFlag = 0; /* for -R and PYTHONHASHRANDOMIZATION */
 
 /* PyModule_GetWarningsModule is no longer necessary as of 2.6
 since _warnings is builtin.  This API should not be used. */
@@ -166,6 +168,10 @@
         Py_OptimizeFlag = add_flag(Py_OptimizeFlag, p);
     if ((p = Py_GETENV("PYTHONDONTWRITEBYTECODE")) && *p != '\0')
         Py_DontWriteBytecodeFlag = add_flag(Py_DontWriteBytecodeFlag, p);
+    if ((p = Py_GETENV("PYTHONHASHRANDOMIZATION")) && *p != '\0')
+        Py_HashRandomizationFlag = add_flag(Py_HashRandomizationFlag, p);
+    
+    _PyRandom_Init();
 
     interp = PyInterpreterState_New();
     if (interp == NULL)
diff -r 9a4131ada792 Python/random.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Python/random.c	Mon Feb 13 15:34:04 2012 -0500
@@ -0,0 +1,303 @@
+#include "Python.h"
+#ifdef MS_WINDOWS
+#include <windows.h>
+#else
+#include <fcntl.h>
+#endif
+
+static int random_initialized = 0;
+
+#ifdef MS_WINDOWS
+typedef BOOL (WINAPI *CRYPTACQUIRECONTEXTA)(HCRYPTPROV *phProv,\
+              LPCSTR pszContainer, LPCSTR pszProvider, DWORD dwProvType,\
+              DWORD dwFlags );
+typedef BOOL (WINAPI *CRYPTGENRANDOM)(HCRYPTPROV hProv, DWORD dwLen,\
+              BYTE *pbBuffer );
+
+static CRYPTGENRANDOM pCryptGenRandom = NULL;
+/* This handle is never explicitly released. Instead, the operating
+   system will release it when the process terminates. */
+static HCRYPTPROV hCryptProv = 0;
+
+static int
+win32_urandom_init(int raise)
+{
+    HINSTANCE hAdvAPI32 = NULL;
+    CRYPTACQUIRECONTEXTA pCryptAcquireContext = NULL;
+
+    /* Obtain handle to the DLL containing CryptoAPI. This should not fail. */
+    hAdvAPI32 = GetModuleHandle("advapi32.dll");
+    if(hAdvAPI32 == NULL)
+        goto error;
+
+    /* Obtain pointers to the CryptoAPI functions. This will fail on some early
+       versions of Win95. */
+    pCryptAcquireContext = (CRYPTACQUIRECONTEXTA)GetProcAddress(
+                               hAdvAPI32, "CryptAcquireContextA");
+    if (pCryptAcquireContext == NULL)
+        goto error;
+
+    pCryptGenRandom = (CRYPTGENRANDOM)GetProcAddress(hAdvAPI32,
+                                                     "CryptGenRandom");
+    if (pCryptGenRandom == NULL)
+        goto error;
+
+    /* Acquire context */
+    if (! pCryptAcquireContext(&hCryptProv, NULL, NULL,
+                               PROV_RSA_FULL, CRYPT_VERIFYCONTEXT))
+        goto error;
+
+    return 0;
+
+error:
+    if (raise)
+        PyErr_SetFromWindowsErr(0);
+    else
+        Py_FatalError("Failed to initialize Windows random API (CryptoGen)");
+    return -1;
+}
+
+/* Fill buffer with size pseudo-random bytes generated by the Windows CryptoGen
+   API. Return 0 on success, or -1 on error. */
+static int
+win32_urandom(unsigned char *buffer, Py_ssize_t size, int raise)
+{
+    Py_ssize_t chunk;
+
+    if (hCryptProv == 0)
+    {
+        if (win32_urandom_init(raise) == -1)
+            return -1;
+    }
+
+    while (size > 0)
+    {
+        chunk = size > INT_MAX ? INT_MAX : size;
+        if (!pCryptGenRandom(hCryptProv, chunk, buffer))
+        {
+            /* CryptGenRandom() failed */
+            if (raise)
+                PyErr_SetFromWindowsErr(0);
+            else
+                Py_FatalError("Failed to initialize the randomized hash "
+                        "secret using CryptoGen)");
+            return -1;
+        }
+        buffer += chunk;
+        size -= chunk;
+    }
+    return 0;
+}
+#endif /* MS_WINDOWS */
+
+
+#ifdef __VMS
+/* Use openssl random routine */
+#include <openssl/rand.h>
+static int
+vms_urandom(unsigned char *buffer, Py_ssize_t size, int raise)
+{
+    if (RAND_pseudo_bytes(buffer, size) < 0) {
+        if (raise) {
+            PyErr_Format(PyExc_ValueError,
+                         "RAND_pseudo_bytes");
+        } else {
+            Py_FatalError("Failed to initialize the randomized hash "
+                          "secret using RAND_pseudo_bytes");
+        }
+        return -1;
+    }
+    return 0;
+}
+#endif /* __VMS */
+
+
+#if !defined(MS_WINDOWS) && !defined(__VMS)
+
+/* Read size bytes from /dev/urandom into buffer.
+   Call Py_FatalError() on error. */
+static void
+dev_urandom_noraise(char *buffer, Py_ssize_t size)
+{
+    int fd;
+    Py_ssize_t n;
+
+    assert (0 < size);
+
+    fd = open("/dev/urandom", O_RDONLY);
+    if (fd < 0)
+        Py_FatalError("Failed to open /dev/urandom");
+
+    while (0 < size)
+    {
+        do {
+            n = read(fd, buffer, (size_t)size);
+        } while (n < 0 && errno == EINTR);
+        if (n <= 0)
+        {
+            /* stop on error or if read(size) returned 0 */
+            Py_FatalError("Failed to read bytes from /dev/urandom");
+            break;
+        }
+        buffer += n;
+        size -= (Py_ssize_t)n;
+    }
+    close(fd);
+}
+
+/* Read size bytes from /dev/urandom into buffer.
+   Return 0 on success, raise an exception and return -1 on error. */
+static int
+dev_urandom_python(char *buffer, Py_ssize_t size)
+{
+    int fd;
+    Py_ssize_t n;
+
+    if (size <= 0)
+        return 0;
+
+    Py_BEGIN_ALLOW_THREADS
+    fd = open("/dev/urandom", O_RDONLY);
+    Py_END_ALLOW_THREADS
+    if (fd < 0)
+    {
+        PyErr_SetFromErrnoWithFilename(PyExc_OSError, "/dev/urandom");
+        return -1;
+    }
+
+    Py_BEGIN_ALLOW_THREADS
+    do {
+        do {
+            n = read(fd, buffer, (size_t)size);
+        } while (n < 0 && errno == EINTR);
+        if (n <= 0)
+            break;
+        buffer += n;
+        size -= (Py_ssize_t)n;
+    } while (0 < size);
+    Py_END_ALLOW_THREADS
+
+    if (n <= 0)
+    {
+        /* stop on error or if read(size) returned 0 */
+        if (n < 0)
+            PyErr_SetFromErrno(PyExc_OSError);
+        else
+            PyErr_Format(PyExc_RuntimeError,
+                         "Failed to read %zi bytes from /dev/urandom",
+                         size);
+        close(fd);
+        return -1;
+    }
+    close(fd);
+    return 0;
+}
+#endif /* !defined(MS_WINDOWS) && !defined(__VMS) */
+
+/* Fill buffer with pseudo-random bytes generated by a linear congruent
+   generator (LCG):
+
+       x(n+1) = (x(n) * 214013 + 2531011) % 2^32
+
+   Use bits 23..16 of x(n) to generate a byte. */
+static void
+lcg_urandom(unsigned int x0, unsigned char *buffer, size_t size)
+{
+    size_t index;
+    unsigned int x;
+
+    x = x0;
+    for (index=0; index < size; index++) {
+        x *= 214013;
+        x += 2531011;
+        /* modulo 2 ^ (8 * sizeof(int)) */
+        buffer[index] = (x >> 16) & 0xff;
+    }
+}
+
+/* Fill buffer with size pseudo-random bytes, not suitable for cryptographic
+   use, from the operating random number generator (RNG).
+
+   Return 0 on success, raise an exception and return -1 on error. */
+int
+_PyOS_URandom(void *buffer, Py_ssize_t size)
+{
+    if (size < 0) {
+        PyErr_Format(PyExc_ValueError,
+                     "negative argument not allowed");
+        return -1;
+    }
+    if (size == 0)
+        return 0;
+
+#ifdef MS_WINDOWS
+    return win32_urandom((unsigned char *)buffer, size, 1);
+#else
+ #ifdef __VMS
+    return vms_urandom((unsigned char *)secret, secret_size, 1);
+ #else
+    return dev_urandom_python((char*)buffer, size);
+ #endif
+#endif/* #else clause of #ifdef MS_WINDOWS */
+}
+
+void
+_PyRandom_Init(void)
+{
+    char *env;
+    void *secret = &_Py_HashSecret;
+    Py_ssize_t secret_size = sizeof(_Py_HashSecret);
+
+    if (random_initialized)
+        return;
+    random_initialized = 1;
+
+    /*
+      By default, hash randomization is disabled, and only
+      enabled if PYTHONHASHRANDOMIZATION is set to non-empty
+      or if "-R" is provided at the command line:
+    */
+    if (!Py_HashRandomizationFlag) {
+        /* Disable the randomized hash: */
+        memset(secret, 0, secret_size);
+        return;
+    }
+
+    /*
+      PYTHONHASHRANDOMIZATION was found; generate a per-process secret,
+      using PYTHONHASHSEED if provided.
+    */
+
+    env = Py_GETENV("PYTHONHASHSEED");
+    if (env && *env != '\0') {
+        char *endptr = env;
+        unsigned long seed;
+        seed = strtoul(env, &endptr, 10);
+        if (*endptr != '\0'
+            || seed > 4294967295UL
+            || (errno == ERANGE && seed == ULONG_MAX))
+        {
+            Py_FatalError("PYTHONHASHSEED must be an integer "
+                          "in range [0; 4294967295]");
+        }
+        if (seed == 0) {
+            /* disable the randomized hash */
+            memset(secret, 0, secret_size);
+        }
+        else {
+            lcg_urandom(seed, (unsigned char*)secret, secret_size);
+        }
+    }
+    else {
+#ifdef MS_WINDOWS
+        (void)win32_urandom((unsigned char *)secret, secret_size, 0);
+#else /* #ifdef MS_WINDOWS */
+ #ifdef __VMS
+        vms_urandom((unsigned char *)secret, secret_size, 0);
+ #else
+        dev_urandom_noraise((char*)secret, secret_size);
+ #endif
+#endif/* #else clause of #ifdef MS_WINDOWS */
+    }
+}
+
diff -r 9a4131ada792 Python/sysmodule.c
--- a/Python/sysmodule.c	Fri Jan 27 09:42:45 2012 +0100
+++ b/Python/sysmodule.c	Mon Feb 13 15:34:04 2012 -0500
@@ -1224,6 +1224,7 @@
     {"unicode",                 "-U"},
     /* {"skip_first",                   "-x"}, */
     {"bytes_warning", "-b"},
+    {"hash_randomization", "-R"},
     {0}
 };
 
@@ -1232,9 +1233,9 @@
     flags__doc__,       /* doc */
     flags_fields,       /* fields */
 #ifdef RISCOS
+    17
+#else
     16
-#else
-    15
 #endif
 };
 
@@ -1271,6 +1272,7 @@
     SetFlag(Py_UnicodeFlag);
     /* SetFlag(skipfirstline); */
     SetFlag(Py_BytesWarningFlag);
+    SetFlag(Py_HashRandomizationFlag);
 #undef SetFlag
 
     if (PyErr_Occurred()) {
-------------- next part --------------
diff -r e7706bdaaa0d Doc/library/sys.rst
--- a/Doc/library/sys.rst	Fri Jan 27 09:48:47 2012 +0100
+++ b/Doc/library/sys.rst	Mon Feb 13 15:34:17 2012 -0500
@@ -220,6 +220,9 @@
    :const:`ignore_environment`   :option:`-E`
    :const:`verbose`              :option:`-v`
    :const:`bytes_warning`        :option:`-b`
+   :const:`hash_randomization`   :option:`-R`
+
+                                 .. versionadded:: 3.1.5
    ============================= =============================
 
 
diff -r e7706bdaaa0d Doc/reference/datamodel.rst
--- a/Doc/reference/datamodel.rst	Fri Jan 27 09:48:47 2012 +0100
+++ b/Doc/reference/datamodel.rst	Mon Feb 13 15:34:17 2012 -0500
@@ -1265,6 +1265,8 @@
    inheritance of :meth:`__hash__` will be blocked, just as if :attr:`__hash__`
    had been explicitly set to :const:`None`.
 
+   See also the :option:`-R` command-line option.
+
 
 .. method:: object.__bool__(self)
 
diff -r e7706bdaaa0d Doc/using/cmdline.rst
--- a/Doc/using/cmdline.rst	Fri Jan 27 09:48:47 2012 +0100
+++ b/Doc/using/cmdline.rst	Mon Feb 13 15:34:17 2012 -0500
@@ -21,7 +21,7 @@
 
 When invoking Python, you may specify any of these options::
 
-    python [-bBdEhiOsSuvVWx?] [-c command | -m module-name | script | - ] [args]
+    python [-bBdEhiORsSuvVWx?] [-c command | -m module-name | script | - ] [args]
 
 The most common use case is, of course, a simple invocation of a script::
 
@@ -215,6 +215,32 @@
    Discard docstrings in addition to the :option:`-O` optimizations.
 
 
+.. cmdoption:: -R
+
+   Turn on hash randomization, so that the :meth:`__hash__` values of str,
+   bytes and datetime objects are "salted" with an unpredictable random value.
+   Although they remain constant within an individual Python process, they
+   are not predictable between repeated invocations of Python.
+
+   This is intended to provide protection against a denial-of-service
+   caused by carefully-chosen inputs that exploit the worst case performance
+   of a dict lookup, O(n^2) complexity.  See:
+
+       http://www.ocert.org/advisories/ocert-2011-003.html
+
+   for details.
+
+   Changing hash values affects the order in which keys are retrieved from
+   a dict.  Although Python has never made guarantees about this ordering
+   (and it typically varies between 32-bit and 64-bit builds), enough
+   real-world code implicitly relies on this non-guaranteed behavior that
+   the randomization is disabled by default.
+
+   See also :envvar:`PYTHONHASHRANDOMIZATION`.
+
+   .. versionadded:: 3.1.5
+
+
 .. cmdoption:: -s
 
    Don't add user site directory to sys.path
@@ -435,6 +461,34 @@
    import of source modules.
 
 
+.. envvar:: PYTHONHASHRANDOMIZATION
+
+   If this is set to a non-empty string it is equivalent to specifying the
+   :option:`-R` option.
+
+   .. versionadded:: 3.1.5
+
+
+.. envvar:: PYTHONHASHSEED
+
+   This environment variable only has an effect when hash randomization has
+   been enabled (via the :option:`-R` option, or its equivalent environment
+   variable, :envvar:`PYTHONHASHRANDOMIZATION`).
+
+   If :envvar:`PYTHONHASHSEED` is set, it is used as a fixed seed for
+   generating the hash() of the types covered by the hash randomization.
+
+   Its purpose is to allow repeatable hashing, such as for selftests for the
+   interpreter itself, or to allow a cluster of python processes to share hash
+   values.
+
+   It should be a decimal number in the range [0; 4294967295].  Specifying
+   the value 0 will lead to the same hash values as when hash randomization
+   is disabled.
+
+   .. versionadded:: 3.1.5
+
+
 .. envvar:: PYTHONIOENCODING
 
    Overrides the encoding used for stdin/stdout/stderr, in the syntax
diff -r e7706bdaaa0d Include/object.h
--- a/Include/object.h	Fri Jan 27 09:48:47 2012 +0100
+++ b/Include/object.h	Mon Feb 13 15:34:17 2012 -0500
@@ -473,6 +473,12 @@
 PyAPI_FUNC(long) _Py_HashDouble(double);
 PyAPI_FUNC(long) _Py_HashPointer(void*);
 
+typedef struct {
+    long prefix;
+    long suffix;
+} _Py_HashSecret_t;
+PyAPI_DATA(_Py_HashSecret_t) _Py_HashSecret;
+
 /* Helper for passing objects to printf and the like */
 #define PyObject_REPR(obj) _PyUnicode_AsString(PyObject_Repr(obj))
 
diff -r e7706bdaaa0d Include/pydebug.h
--- a/Include/pydebug.h	Fri Jan 27 09:48:47 2012 +0100
+++ b/Include/pydebug.h	Mon Feb 13 15:34:17 2012 -0500
@@ -19,6 +19,7 @@
 PyAPI_DATA(int) Py_DontWriteBytecodeFlag;
 PyAPI_DATA(int) Py_NoUserSiteDirectory;
 PyAPI_DATA(int) Py_UnbufferedStdioFlag;
+PyAPI_DATA(int) Py_HashRandomizationFlag;
 
 /* this is a wrapper around getenv() that pays attention to
    Py_IgnoreEnvironmentFlag.  It should be used for getting variables like
diff -r e7706bdaaa0d Include/pythonrun.h
--- a/Include/pythonrun.h	Fri Jan 27 09:48:47 2012 +0100
+++ b/Include/pythonrun.h	Mon Feb 13 15:34:17 2012 -0500
@@ -174,6 +174,8 @@
 PyAPI_FUNC(PyOS_sighandler_t) PyOS_getsig(int);
 PyAPI_FUNC(PyOS_sighandler_t) PyOS_setsig(int, PyOS_sighandler_t);
 
+/* Random */
+PyAPI_FUNC(int) _PyOS_URandom (void *buffer, Py_ssize_t size);
 
 #ifdef __cplusplus
 }
diff -r e7706bdaaa0d Lib/os.py
--- a/Lib/os.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/os.py	Mon Feb 13 15:34:17 2012 -0500
@@ -611,23 +611,6 @@
 except NameError: # statvfs_result may not exist
     pass
 
-if not _exists("urandom"):
-    def urandom(n):
-        """urandom(n) -> str
-
-        Return a string of n random bytes suitable for cryptographic use.
-
-        """
-        try:
-            _urandomfd = open("/dev/urandom", O_RDONLY)
-        except (OSError, IOError):
-            raise NotImplementedError("/dev/urandom (or equivalent) not found")
-        bs = b""
-        while len(bs) < n:
-            bs += read(_urandomfd, n - len(bs))
-        close(_urandomfd)
-        return bs
-
 # Supply os.popen()
 def popen(cmd, mode="r", buffering=-1):
     if not isinstance(cmd, str):
diff -r e7706bdaaa0d Lib/test/regrtest.py
--- a/Lib/test/regrtest.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/regrtest.py	Mon Feb 13 15:34:17 2012 -0500
@@ -428,6 +428,11 @@
         except ValueError:
             print("Couldn't find starting test (%s), using all tests" % start)
     if randomize:
+        hashseed = os.getenv('PYTHONHASHSEED')
+        if not hashseed:
+            os.environ['PYTHONHASHSEED'] = str(random_seed)
+            os.execv(sys.executable, [sys.executable] + sys.argv)
+            return
         random.seed(random_seed)
         print("Using random seed", random_seed)
         random.shuffle(tests)
diff -r e7706bdaaa0d Lib/test/test_cmd_line.py
--- a/Lib/test/test_cmd_line.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_cmd_line.py	Mon Feb 13 15:34:17 2012 -0500
@@ -190,6 +190,22 @@
             self.assertTrue(path1.encode('ascii') in stdout)
             self.assertTrue(path2.encode('ascii') in stdout)
 
+    def test_hash_randomization(self):
+        # Verify that -R enables hash randomization:
+        self.verify_valid_flag('-R')
+        hashes = []
+        for i in range(2):
+            code = 'print(hash("spam"))'
+            data, rc = self.start_python_and_exit_code('-R', '-c', code)
+            self.assertEqual(rc, 0)
+            hashes.append(data)
+        self.assertNotEqual(hashes[0], hashes[1])
+
+        # Verify that sys.flags contains hash_randomization
+        code = 'import sys; print(sys.flags)'
+        data, rc = self.start_python_and_exit_code('-R', '-c', code)
+        self.assertEqual(rc,0)
+        self.assertIn(b'hash_randomization=1', data)
 
 def test_main():
     test.support.run_unittest(CmdLineTest)
diff -r e7706bdaaa0d Lib/test/test_hash.py
--- a/Lib/test/test_hash.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_hash.py	Mon Feb 13 15:34:17 2012 -0500
@@ -3,10 +3,16 @@
 #
 # Also test that hash implementations are inherited as expected
 
+import datetime
+import os
+import struct
 import unittest
 from test import support
+from test.script_helper import assert_python_ok
 from collections import Hashable
 
+IS_64BIT = (struct.calcsize('l') == 8)
+
 
 class HashEqualityTestCase(unittest.TestCase):
 
@@ -118,10 +124,92 @@
         for obj in self.hashes_to_check:
             self.assertEqual(hash(obj), _default_hash(obj))
 
+class HashRandomizationTests(unittest.TestCase):
+
+    # Each subclass should define a field "repr_", containing the repr() of
+    # an object to be tested
+
+    def get_hash_command(self, repr_):
+        return 'print(hash(%s))' % repr_
+
+    def get_hash(self, repr_, randomization=None, seed=None):
+        env = os.environ.copy()
+        if randomization is not None:
+            env['PYTHONHASHRANDOMIZATION'] = str(randomization)
+        if seed is not None:
+            env['PYTHONHASHSEED'] = str(seed)
+        out = assert_python_ok(
+            '-c', self.get_hash_command(repr_),
+            **env)
+        stdout = out[1].strip()
+        return int(stdout)
+
+    def test_randomized_hash(self):
+        # two runs should return different hashes
+        run1 = self.get_hash(self.repr_, randomization=1)
+        run2 = self.get_hash(self.repr_, randomization=1)
+        self.assertNotEqual(run1, run2)
+
+class StringlikeHashRandomizationTests(HashRandomizationTests):
+    def test_null_hash(self):
+        # PYTHONHASHSEED=0 disables the randomized hash
+        if IS_64BIT:
+            known_hash_of_obj = 1453079729188098211
+        else:
+            known_hash_of_obj = -1600925533
+
+        # Randomization is disabled by default:
+        self.assertEqual(self.get_hash(self.repr_), known_hash_of_obj)
+
+        # If enabled, it can still be disabled by setting the seed to 0:
+        self.assertEqual(self.get_hash(self.repr_, randomization=1, seed=0),
+                         known_hash_of_obj)
+
+    def test_fixed_hash(self):
+        # test a fixed seed for the randomized hash
+        # Note that all types share the same values:
+        if IS_64BIT:
+            h = -4410911502303878509
+        else:
+            h = -206076799
+        self.assertEqual(self.get_hash(self.repr_, randomization=1, seed=42),
+                         h)
+
+class StrHashRandomizationTests(StringlikeHashRandomizationTests):
+    repr_ = repr('abc')
+
+    def test_empty_string(self):
+        self.assertEqual(hash(""), 0)
+
+class BytesHashRandomizationTests(StringlikeHashRandomizationTests):
+    repr_ = repr(b'abc')
+
+    def test_empty_string(self):
+        self.assertEqual(hash(b""), 0)
+
+class DatetimeTests(HashRandomizationTests):
+    def get_hash_command(self, repr_):
+        return 'import datetime; print(hash(%s))' % repr_
+
+class DatetimeDateTests(DatetimeTests):
+    repr_ = repr(datetime.date(1066, 10, 14))
+
+class DatetimeDatetimeTests(DatetimeTests):
+    repr_ = repr(datetime.datetime(1, 2, 3, 4, 5, 6, 7))
+
+class DatetimeTimeTests(DatetimeTests):
+    repr_ = repr(datetime.time(0))
+
 def test_main():
     support.run_unittest(HashEqualityTestCase,
                               HashInheritanceTestCase,
-                              HashBuiltinsTestCase)
+                              HashBuiltinsTestCase,
+                         StrHashRandomizationTests,
+                         BytesHashRandomizationTests,
+                         DatetimeDateTests,
+                         DatetimeDatetimeTests,
+                         DatetimeTimeTests)
+
 
 
 if __name__ == "__main__":
diff -r e7706bdaaa0d Lib/test/test_os.py
--- a/Lib/test/test_os.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_os.py	Mon Feb 13 15:34:17 2012 -0500
@@ -9,6 +9,7 @@
 import sys
 import shutil
 from test import support
+from test.script_helper import assert_python_ok
 
 # Detect whether we're on a Linux system that uses the (now outdated
 # and unmaintained) linuxthreads threading library.  There's an issue
@@ -574,14 +575,33 @@
         f.close()
 
 class URandomTests(unittest.TestCase):
-    def test_urandom(self):
-        try:
-            self.assertEqual(len(os.urandom(1)), 1)
-            self.assertEqual(len(os.urandom(10)), 10)
-            self.assertEqual(len(os.urandom(100)), 100)
-            self.assertEqual(len(os.urandom(1000)), 1000)
-        except NotImplementedError:
-            pass
+    def test_urandom_length(self):
+        self.assertEqual(len(os.urandom(0)), 0)
+        self.assertEqual(len(os.urandom(1)), 1)
+        self.assertEqual(len(os.urandom(10)), 10)
+        self.assertEqual(len(os.urandom(100)), 100)
+        self.assertEqual(len(os.urandom(1000)), 1000)
+
+    def test_urandom_value(self):
+        data1 = os.urandom(16)
+        data2 = os.urandom(16)
+        self.assertNotEqual(data1, data2)
+
+    def get_urandom_subprocess(self, count):
+        code = '\n'.join((
+            'import os, sys',
+            'data = os.urandom(%s)' % count,
+            'sys.stdout.buffer.write(data)',
+            'sys.stdout.buffer.flush()'))
+        out = assert_python_ok('-c', code)
+        stdout = out[1]
+        self.assertEqual(len(stdout), 16)
+        return stdout
+
+    def test_urandom_subprocess(self):
+        data1 = self.get_urandom_subprocess(16)
+        data2 = self.get_urandom_subprocess(16)
+        self.assertNotEqual(data1, data2)
 
 class ExecTests(unittest.TestCase):
     @unittest.skipIf(USING_LINUXTHREADS,
diff -r e7706bdaaa0d Lib/test/test_sys.py
--- a/Lib/test/test_sys.py	Fri Jan 27 09:48:47 2012 +0100
+++ b/Lib/test/test_sys.py	Mon Feb 13 15:34:17 2012 -0500
@@ -446,7 +446,7 @@
         attrs = ("debug", "division_warning",
                  "inspect", "interactive", "optimize", "dont_write_bytecode",
                  "no_user_site", "no_site", "ignore_environment", "verbose",
-                 "bytes_warning")
+                 "bytes_warning", "hash_randomization")
         for attr in attrs:
             self.assertTrue(hasattr(sys.flags, attr), attr)
             self.assertEqual(type(getattr(sys.flags, attr)), int, attr)
diff -r e7706bdaaa0d Makefile.pre.in
--- a/Makefile.pre.in	Fri Jan 27 09:48:47 2012 +0100
+++ b/Makefile.pre.in	Mon Feb 13 15:34:17 2012 -0500
@@ -305,6 +305,7 @@
 		Python/pymath.o \
 		Python/pystate.o \
 		Python/pythonrun.o \
+		Python/random.o \
 		Python/structmember.o \
 		Python/symtable.o \
 		Python/sysmodule.o \
diff -r e7706bdaaa0d Misc/NEWS
--- a/Misc/NEWS	Fri Jan 27 09:48:47 2012 +0100
+++ b/Misc/NEWS	Mon Feb 13 15:34:17 2012 -0500
@@ -10,6 +10,12 @@
 Core and Builtins
 -----------------
 
+- Issue #13703: oCERT-2011-003: add -R command-line option and
+  PYTHONHASHRANDOMIZATION (and PYTHONHASHSEED) environment variables, to
+  provide an opt-in way to protect against denial of service attacks due to
+  hash collisions within the dict and set types.  Patch by David Malcolm,
+  based on work by Victor Stinner.
+
 Library
 -------
 
diff -r e7706bdaaa0d Misc/python.man
--- a/Misc/python.man	Fri Jan 27 09:48:47 2012 +0100
+++ b/Misc/python.man	Mon Feb 13 15:34:17 2012 -0500
@@ -34,6 +34,9 @@
 .B \-OO
 ]
 [
+.B \-R
+]
+[
 .B -Q
 .I argument
 ]
@@ -145,6 +148,18 @@
 .B \-OO
 Discard docstrings in addition to the \fB-O\fP optimizations.
 .TP
+.B \-R
+Turn on "hash randomization", so that the hash() values of str, bytes and
+datetime objects are "salted" with an unpredictable pseudo-random value.
+Although they remain constant within an individual Python process, they are
+not predictable between repeated invocations of Python.
+.IP
+This is intended to provide protection against a denial of service
+caused by carefully-chosen inputs that exploit the worst case performance
+of a dict lookup, O(n^2) complexity.  See
+http://www.ocert.org/advisories/ocert-2011-003.html
+for details.
+.TP
 .BI "\-Q " argument
 Division control; see PEP 238.  The argument must be one of "old" (the
 default, int/int and long/long return an int or long), "new" (new
@@ -403,6 +418,24 @@
 If this is set to a non-empty string it is equivalent to specifying
 the \fB\-v\fP option. If set to an integer, it is equivalent to
 specifying \fB\-v\fP multiple times. 
+.IP PYTHONHASHRANDOMIZATION
+If this is set to a non-empty string it is equivalent to specifying the
+\fB\-R\fP option.
+.IP PYTHONHASHSEED
+This environment variable only has an effect when hash randomization has
+been enabled (via the \fB\-R\fP option, or its equivalent environment
+variable, \fB\PYTHONHASHRANDOMIZATION\fP).
+
+If PYTHONHASHSEED is set, it is used as a fixed seed for
+generating the hash() of the types covered by the hash randomization.
+
+Its purpose is to allow repeatable hashing, such as for selftests for the
+interpreter itself, or to allow a cluster of python processes to share hash
+values.
+
+It should be a decimal number in the range [0; 4294967295].  Specifying
+the value 0 will lead to the same hash values as when hash randomization
+is disabled.
 .SH AUTHOR
 The Python Software Foundation: http://www.python.org/psf
 .SH INTERNET RESOURCES
diff -r e7706bdaaa0d Modules/datetimemodule.c
--- a/Modules/datetimemodule.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Modules/datetimemodule.c	Mon Feb 13 15:34:17 2012 -0500
@@ -2566,10 +2566,12 @@
     register long x;
 
     p = (unsigned char *) data;
-    x = *p << 7;
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= len;
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
 
diff -r e7706bdaaa0d Modules/main.c
--- a/Modules/main.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Modules/main.c	Mon Feb 13 15:34:17 2012 -0500
@@ -47,7 +47,7 @@
 static int  orig_argc;
 
 /* command line options */
-#define BASE_OPTS L"bBc:dEhiJm:OsStuvVW:xX?"
+#define BASE_OPTS L"bBc:dEhiJm:ORsStuvVW:xX?"
 
 #define PROGRAM_OPTS BASE_OPTS
 
@@ -72,6 +72,9 @@
 -m mod : run library module as a script (terminates option list)\n\
 -O     : optimize generated bytecode slightly; also PYTHONOPTIMIZE=x\n\
 -OO    : remove doc-strings in addition to the -O optimizations\n\
+-R     : use a pseudo-random salt to make hash() values of various types be\n\
+         unpredictable between separate invocations of the interpreter, as\n\
+         a defence against denial-of-service attacks\n\
 -s     : don't add user site directory to sys.path; also PYTHONNOUSERSITE\n\
 -S     : don't imply 'import site' on initialization\n\
 ";
@@ -99,6 +102,22 @@
 PYTHONCASEOK : ignore case in 'import' statements (Windows).\n\
 PYTHONIOENCODING: Encoding[:errors] used for stdin/stdout/stderr.\n\
 ";
+static char *usage_6 = "\
+PYTHONHASHRANDOMIZATION : make hash() values of various types be\n\
+   unpredictable between separate invocations of the interpreter, as a\n\
+   defence against denial-of-service attacks\n\
+PYTHONHASHSEED: this environment variable only has an effect when hash\n\
+   randomization has been enabled (via the -R option, or its equivalent\n\
+   environment variable, PYTHONHASHRANDOMIZATION)\n\
+   If set, it is used as a fixed seed for generating the hash() of the types\n\
+   covered by the hash randomization\n\
+   Its purpose is to allow repeatable hashing, such as for selftests for the\n\
+   interpreter itself, or to allow a cluster of python processes to share\n\
+   hash values.\n\
+   It should be a decimal number in the range [0; 4294967295]. Specifying\n\
+   the value 0 will lead to the same hash values as when hash randomization\n\
+   is disabled.\n\
+";
 
 #ifndef MS_WINDOWS
 static FILE*
@@ -136,6 +155,7 @@
         fputs(usage_3, f);
         fprintf(f, usage_4, DELIM);
         fprintf(f, usage_5, DELIM, PYTHONHOMEHELP);
+        fputs(usage_6, f);
     }
 #if defined(__VMS)
     if (exitcode == 0) {
@@ -373,6 +393,10 @@
             PySys_AddWarnOption(_PyOS_optarg);
             break;
 
+        case 'R':
+            Py_HashRandomizationFlag++;
+            break;
+
         /* This space reserved for other options */
 
         default:
diff -r e7706bdaaa0d Modules/posixmodule.c
--- a/Modules/posixmodule.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Modules/posixmodule.c	Mon Feb 13 15:34:17 2012 -0500
@@ -6942,82 +6942,6 @@
 }
 #endif
 
-#ifdef MS_WINDOWS
-
-PyDoc_STRVAR(win32_urandom__doc__,
-"urandom(n) -> str\n\n\
-Return n random bytes suitable for cryptographic use.");
-
-typedef BOOL (WINAPI *CRYPTACQUIRECONTEXTA)(HCRYPTPROV *phProv,\
-              LPCSTR pszContainer, LPCSTR pszProvider, DWORD dwProvType,\
-              DWORD dwFlags );
-typedef BOOL (WINAPI *CRYPTGENRANDOM)(HCRYPTPROV hProv, DWORD dwLen,\
-              BYTE *pbBuffer );
-
-static CRYPTGENRANDOM pCryptGenRandom = NULL;
-/* This handle is never explicitly released. Instead, the operating
-   system will release it when the process terminates. */
-static HCRYPTPROV hCryptProv = 0;
-
-static PyObject*
-win32_urandom(PyObject *self, PyObject *args)
-{
-    int howMany;
-    PyObject* result;
-
-    /* Read arguments */
-    if (! PyArg_ParseTuple(args, "i:urandom", &howMany))
-        return NULL;
-    if (howMany < 0)
-        return PyErr_Format(PyExc_ValueError,
-                            "negative argument not allowed");
-
-    if (hCryptProv == 0) {
-        HINSTANCE hAdvAPI32 = NULL;
-        CRYPTACQUIRECONTEXTA pCryptAcquireContext = NULL;
-
-        /* Obtain handle to the DLL containing CryptoAPI
-           This should not fail         */
-        hAdvAPI32 = GetModuleHandle("advapi32.dll");
-        if(hAdvAPI32 == NULL)
-            return win32_error("GetModuleHandle", NULL);
-
-        /* Obtain pointers to the CryptoAPI functions
-           This will fail on some early versions of Win95 */
-        pCryptAcquireContext = (CRYPTACQUIRECONTEXTA)GetProcAddress(
-                                        hAdvAPI32,
-                                        "CryptAcquireContextA");
-        if (pCryptAcquireContext == NULL)
-            return PyErr_Format(PyExc_NotImplementedError,
-                                "CryptAcquireContextA not found");
-
-        pCryptGenRandom = (CRYPTGENRANDOM)GetProcAddress(
-                                        hAdvAPI32, "CryptGenRandom");
-        if (pCryptGenRandom == NULL)
-            return PyErr_Format(PyExc_NotImplementedError,
-                                "CryptGenRandom not found");
-
-        /* Acquire context */
-        if (! pCryptAcquireContext(&hCryptProv, NULL, NULL,
-                                   PROV_RSA_FULL, CRYPT_VERIFYCONTEXT))
-            return win32_error("CryptAcquireContext", NULL);
-    }
-
-    /* Allocate bytes */
-    result = PyBytes_FromStringAndSize(NULL, howMany);
-    if (result != NULL) {
-        /* Get random data */
-        memset(PyBytes_AS_STRING(result), 0, howMany); /* zero seed */
-        if (! pCryptGenRandom(hCryptProv, howMany, (unsigned char*)
-                              PyBytes_AS_STRING(result))) {
-            Py_DECREF(result);
-            return win32_error("CryptGenRandom", NULL);
-        }
-    }
-    return result;
-}
-#endif
-
 PyDoc_STRVAR(device_encoding__doc__,
 "device_encoding(fd) -> str\n\n\
 Return a string describing the encoding of the device\n\
@@ -7055,41 +6979,35 @@
     return Py_None;
 }
 
-#ifdef __VMS
-/* Use openssl random routine */
-#include <openssl/rand.h>
-PyDoc_STRVAR(vms_urandom__doc__,
+PyDoc_STRVAR(posix_urandom__doc__,
 "urandom(n) -> str\n\n\
 Return n random bytes suitable for cryptographic use.");
 
-static PyObject*
-vms_urandom(PyObject *self, PyObject *args)
-{
-    int howMany;
-    PyObject* result;
-
-    /* Read arguments */
-    if (! PyArg_ParseTuple(args, "i:urandom", &howMany))
-        return NULL;
-    if (howMany < 0)
+static PyObject *
+posix_urandom(PyObject *self, PyObject *args)
+{
+    Py_ssize_t size;
+    PyObject *result;
+    int ret;
+ 
+     /* Read arguments */
+    if (!PyArg_ParseTuple(args, "n:urandom", &size))
+        return NULL;
+    if (size < 0)
         return PyErr_Format(PyExc_ValueError,
                             "negative argument not allowed");
-
-    /* Allocate bytes */
-    result = PyBytes_FromStringAndSize(NULL, howMany);
-    if (result != NULL) {
-        /* Get random data */
-        if (RAND_pseudo_bytes((unsigned char*)
-                              PyBytes_AS_STRING(result),
-                              howMany) < 0) {
-            Py_DECREF(result);
-            return PyErr_Format(PyExc_ValueError,
-                                "RAND_pseudo_bytes");
-        }
+    result = PyBytes_FromStringAndSize(NULL, size);
+    if (result == NULL)
+        return NULL;
+
+    ret = _PyOS_URandom(PyBytes_AS_STRING(result),
+                        PyBytes_GET_SIZE(result));
+    if (ret == -1) {
+        Py_DECREF(result);
+        return NULL;
     }
     return result;
 }
-#endif
 
 static PyMethodDef posix_methods[] = {
     {"access",          posix_access, METH_VARARGS, posix_access__doc__},
@@ -7374,12 +7292,7 @@
 #ifdef HAVE_GETLOADAVG
     {"getloadavg",      posix_getloadavg, METH_NOARGS, posix_getloadavg__doc__},
 #endif
- #ifdef MS_WINDOWS
-    {"urandom", win32_urandom, METH_VARARGS, win32_urandom__doc__},
- #endif
- #ifdef __VMS
-    {"urandom", vms_urandom, METH_VARARGS, vms_urandom__doc__},
- #endif
+    {"urandom",         posix_urandom,   METH_VARARGS, posix_urandom__doc__},
     {NULL,              NULL}            /* Sentinel */
 };
 
diff -r e7706bdaaa0d Objects/bytesobject.c
--- a/Objects/bytesobject.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Objects/bytesobject.c	Mon Feb 13 15:34:17 2012 -0500
@@ -899,11 +899,21 @@
     if (a->ob_shash != -1)
         return a->ob_shash;
     len = Py_SIZE(a);
+    /*
+      We make the hash of the empty string be 0, rather than using
+      (prefix ^ suffix), since this slightly obfuscates the hash secret
+    */
+    if (len == 0) {
+        a->ob_shash = 0;
+        return 0;
+    }
     p = (unsigned char *) a->ob_sval;
-    x = *p << 7;
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= Py_SIZE(a);
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
     a->ob_shash = x;
diff -r e7706bdaaa0d Objects/object.c
--- a/Objects/object.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Objects/object.c	Mon Feb 13 15:34:17 2012 -0500
@@ -712,6 +712,8 @@
     return -1;
 }
 
+_Py_HashSecret_t _Py_HashSecret;
+
 long
 PyObject_Hash(PyObject *v)
 {
diff -r e7706bdaaa0d Objects/unicodeobject.c
--- a/Objects/unicodeobject.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Objects/unicodeobject.c	Mon Feb 13 15:34:17 2012 -0500
@@ -7344,11 +7344,21 @@
     if (self->hash != -1)
         return self->hash;
     len = Py_SIZE(self);
+    /*
+      We make the hash of the empty string be 0, rather than using
+      (prefix ^ suffix), since this slightly obfuscates the hash secret
+    */
+    if (len == 0) {
+        self->hash = 0;
+        return 0;
+    }
     p = self->str;
-    x = *p << 7;
+    x = _Py_HashSecret.prefix;
+    x ^= *p << 7;
     while (--len >= 0)
         x = (1000003*x) ^ *p++;
     x ^= Py_SIZE(self);
+    x ^= _Py_HashSecret.suffix;
     if (x == -1)
         x = -2;
     self->hash = x;
diff -r e7706bdaaa0d PCbuild/pythoncore.vcproj
--- a/PCbuild/pythoncore.vcproj	Fri Jan 27 09:48:47 2012 +0100
+++ b/PCbuild/pythoncore.vcproj	Mon Feb 13 15:34:17 2012 -0500
@@ -1778,6 +1778,10 @@
 				RelativePath="..\Python\pythonrun.c"
 				>
 			</File>
+ 			<File
+				RelativePath="..\Python\random.c"
+				>
+			</File>
 			<File
 				RelativePath="..\Python\structmember.c"
 				>
diff -r e7706bdaaa0d Python/pythonrun.c
--- a/Python/pythonrun.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Python/pythonrun.c	Mon Feb 13 15:34:17 2012 -0500
@@ -73,6 +73,7 @@
 extern void _PyUnicode_Fini(void);
 extern int _PyLong_Init(void);
 extern void PyLong_Fini(void);
+extern void _PyRandom_Init(void);
 
 #ifdef WITH_THREAD
 extern void _PyGILState_Init(PyInterpreterState *, PyThreadState *);
@@ -91,6 +92,7 @@
 int Py_IgnoreEnvironmentFlag; /* e.g. PYTHONPATH, PYTHONHOME */
 int Py_NoUserSiteDirectory = 0; /* for -s and site.py */
 int Py_UnbufferedStdioFlag = 0; /* Unbuffered binary std{in,out,err} */
+int Py_HashRandomizationFlag = 0; /* for -R and PYTHONHASHRANDOMIZATION */
 
 /* PyModule_GetWarningsModule is no longer necessary as of 2.6
 since _warnings is builtin.  This API should not be used. */
@@ -195,6 +197,10 @@
         Py_OptimizeFlag = add_flag(Py_OptimizeFlag, p);
     if ((p = Py_GETENV("PYTHONDONTWRITEBYTECODE")) && *p != '\0')
         Py_DontWriteBytecodeFlag = add_flag(Py_DontWriteBytecodeFlag, p);
+    if ((p = Py_GETENV("PYTHONHASHRANDOMIZATION")) && *p != '\0')
+        Py_HashRandomizationFlag = add_flag(Py_HashRandomizationFlag, p);
+    
+    _PyRandom_Init();
 
     interp = PyInterpreterState_New();
     if (interp == NULL)
diff -r e7706bdaaa0d Python/random.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Python/random.c	Mon Feb 13 15:34:17 2012 -0500
@@ -0,0 +1,299 @@
+#include "Python.h"
+#ifdef MS_WINDOWS
+#include <windows.h>
+#else
+#include <fcntl.h>
+#endif
+
+static int random_initialized = 0;
+
+#ifdef MS_WINDOWS
+typedef BOOL (WINAPI *CRYPTACQUIRECONTEXTA)(HCRYPTPROV *phProv,\
+              LPCSTR pszContainer, LPCSTR pszProvider, DWORD dwProvType,\
+              DWORD dwFlags );
+typedef BOOL (WINAPI *CRYPTGENRANDOM)(HCRYPTPROV hProv, DWORD dwLen,\
+              BYTE *pbBuffer );
+
+static CRYPTGENRANDOM pCryptGenRandom = NULL;
+/* This handle is never explicitly released. Instead, the operating
+   system will release it when the process terminates. */
+static HCRYPTPROV hCryptProv = 0;
+
+static int
+win32_urandom_init(int raise)
+{
+    HINSTANCE hAdvAPI32 = NULL;
+    CRYPTACQUIRECONTEXTA pCryptAcquireContext = NULL;
+
+    /* Obtain handle to the DLL containing CryptoAPI. This should not fail. */
+    hAdvAPI32 = GetModuleHandle("advapi32.dll");
+    if(hAdvAPI32 == NULL)
+        goto error;
+
+    /* Obtain pointers to the CryptoAPI functions. This will fail on some early
+       versions of Win95. */
+    pCryptAcquireContext = (CRYPTACQUIRECONTEXTA)GetProcAddress(
+                               hAdvAPI32, "CryptAcquireContextA");
+    if (pCryptAcquireContext == NULL)
+        goto error;
+
+    pCryptGenRandom = (CRYPTGENRANDOM)GetProcAddress(hAdvAPI32,
+                                                     "CryptGenRandom");
+    if (pCryptGenRandom == NULL)
+        goto error;
+
+    /* Acquire context */
+    if (! pCryptAcquireContext(&hCryptProv, NULL, NULL,
+                               PROV_RSA_FULL, CRYPT_VERIFYCONTEXT))
+        goto error;
+
+    return 0;
+
+error:
+    if (raise)
+        PyErr_SetFromWindowsErr(0);
+    else
+        Py_FatalError("Failed to initialize Windows random API (CryptoGen)");
+    return -1;
+}
+
+/* Fill buffer with size pseudo-random bytes generated by the Windows CryptoGen
+   API. Return 0 on success, or -1 on error. */
+static int
+win32_urandom(unsigned char *buffer, Py_ssize_t size, int raise)
+{
+    Py_ssize_t chunk;
+
+    if (hCryptProv == 0)
+    {
+        if (win32_urandom_init(raise) == -1)
+            return -1;
+    }
+
+    while (size > 0)
+    {
+        chunk = size > INT_MAX ? INT_MAX : size;
+        if (!pCryptGenRandom(hCryptProv, chunk, buffer))
+        {
+            /* CryptGenRandom() failed */
+            if (raise)
+                PyErr_SetFromWindowsErr(0);
+            else
+                Py_FatalError("Failed to initialized the randomized hash "
+                        "secret using CryptoGen)");
+            return -1;
+        }
+        buffer += chunk;
+        size -= chunk;
+    }
+    return 0;
+}
+#endif /* MS_WINDOWS */
+
+
+#ifdef __VMS
+/* Use openssl random routine */
+#include <openssl/rand.h>
+static int
+vms_urandom(unsigned char *buffer, Py_ssize_t size, int raise)
+{
+    if (RAND_pseudo_bytes(buffer, size) < 0) {
+        if (raise) {
+            PyErr_Format(PyExc_ValueError,
+                         "RAND_pseudo_bytes");
+        } else {
+            Py_FatalError("Failed to initialize the randomized hash "
+                          "secret using RAND_pseudo_bytes");
+        }
+        return -1;
+    }
+    return 0;
+}
+#endif /* __VMS */
+
+
+#if !defined(MS_WINDOWS) && !defined(__VMS)
+
+/* Read size bytes from /dev/urandom into buffer.
+   Call Py_FatalError() on error. */
+static void
+dev_urandom_noraise(char *buffer, Py_ssize_t size)
+{
+    int fd;
+    Py_ssize_t n;
+
+    assert (0 < size);
+
+    fd = open("/dev/urandom", O_RDONLY);
+    if (fd < 0)
+        Py_FatalError("Failed to open /dev/urandom");
+
+    while (0 < size)
+    {
+        do {
+            n = read(fd, buffer, (size_t)size);
+        } while (n < 0 && errno == EINTR);
+        if (n <= 0)
+        {
+            /* stop on error or if read(size) returned 0 */
+            Py_FatalError("Failed to read bytes from /dev/urandom");
+            break;
+        }
+        buffer += n;
+        size -= (Py_ssize_t)n;
+    }
+    close(fd);
+}
+
+/* Read size bytes from /dev/urandom into buffer.
+   Return 0 on success, raise an exception and return -1 on error. */
+static int
+dev_urandom_python(char *buffer, Py_ssize_t size)
+{
+    int fd;
+    Py_ssize_t n;
+
+    if (size <= 0)
+        return 0;
+
+    Py_BEGIN_ALLOW_THREADS
+    fd = open("/dev/urandom", O_RDONLY);
+    Py_END_ALLOW_THREADS
+    if (fd < 0)
+    {
+        PyErr_SetFromErrnoWithFilename(PyExc_OSError, "/dev/urandom");
+        return -1;
+    }
+
+    Py_BEGIN_ALLOW_THREADS
+    do {
+        do {
+            n = read(fd, buffer, (size_t)size);
+        } while (n < 0 && errno == EINTR);
+        if (n <= 0)
+            break;
+        buffer += n;
+        size -= (Py_ssize_t)n;
+    } while (0 < size);
+    Py_END_ALLOW_THREADS
+
+    if (n <= 0)
+    {
+        /* stop on error or if read(size) returned 0 */
+        if (n < 0)
+            PyErr_SetFromErrno(PyExc_OSError);
+        else
+            PyErr_Format(PyExc_RuntimeError,
+                         "Failed to read %zi bytes from /dev/urandom",
+                         size);
+        close(fd);
+        return -1;
+    }
+    close(fd);
+    return 0;
+}
+#endif /* !defined(MS_WINDOWS) && !defined(__VMS) */
+
+/* Fill buffer with pseudo-random bytes generated by a linear congruent
+   generator (LCG):
+
+       x(n+1) = (x(n) * 214013 + 2531011) % 2^32
+
+   Use bits 23..16 of x(n) to generate a byte. */
+static void
+lcg_urandom(unsigned int x0, unsigned char *buffer, size_t size)
+{
+    size_t index;
+    unsigned int x;
+
+    x = x0;
+    for (index=0; index < size; index++) {
+        x *= 214013;
+        x += 2531011;
+        /* modulo 2 ^ (8 * sizeof(int)) */
+        buffer[index] = (x >> 16) & 0xff;
+    }
+}
+
+/* Fill buffer with size pseudo-random bytes, not suitable for cryptographic
+   use, from the operating random number generator (RNG).
+
+   Return 0 on success, raise an exception and return -1 on error. */
+int
+_PyOS_URandom(void *buffer, Py_ssize_t size)
+{
+    if (size < 0) {
+        PyErr_Format(PyExc_ValueError,
+                     "negative argument not allowed");
+        return -1;
+    }
+    if (size == 0)
+        return 0;
+
+#ifdef MS_WINDOWS
+    return win32_urandom((unsigned char *)buffer, size, 1);
+#else
+    return dev_urandom_python((char*)buffer, size);
+#endif
+}
+
+void
+_PyRandom_Init(void)
+{
+    char *env;
+    void *secret = &_Py_HashSecret;
+    Py_ssize_t secret_size = sizeof(_Py_HashSecret);
+
+    if (random_initialized)
+        return;
+    random_initialized = 1;
+
+    /*
+      By default, hash randomization is disabled, and only
+      enabled if PYTHONHASHRANDOMIZATION is set to non-empty
+      or if "-R" is provided at the command line:
+    */
+    if (!Py_HashRandomizationFlag) {
+        /* Disable the randomized hash: */
+        memset(secret, 0, secret_size);
+        return;
+    }
+
+    /*
+      Hash randomization is enabled.  Generate a per-process secret,
+      using PYTHONHASHSEED if provided.
+    */
+
+    env = Py_GETENV("PYTHONHASHSEED");
+    if (env && *env != '\0') {
+        char *endptr = env;
+        unsigned long seed;
+        seed = strtoul(env, &endptr, 10);
+        if (*endptr != '\0'
+            || seed > 4294967295UL
+            || (errno == ERANGE && seed == ULONG_MAX))
+        {
+            Py_FatalError("PYTHONHASHSEED must be an integer "
+                          "in range [0; 4294967295]");
+        }
+        if (seed == 0) {
+            /* disable the randomized hash */
+            memset(secret, 0, secret_size);
+        }
+        else {
+            lcg_urandom(seed, (unsigned char*)secret, secret_size);
+        }
+    }
+    else {
+#ifdef MS_WINDOWS
+        (void)win32_urandom((unsigned char *)secret, secret_size, 0);
+#else /* #ifdef MS_WINDOWS */
+ #ifdef __VMS
+        vms_urandom((unsigned char *)secret, secret_size, 0);
+ #else
+        dev_urandom_noraise((char*)secret, secret_size);
+ #endif
+#endif
+    }
+}
+
diff -r e7706bdaaa0d Python/sysmodule.c
--- a/Python/sysmodule.c	Fri Jan 27 09:48:47 2012 +0100
+++ b/Python/sysmodule.c	Mon Feb 13 15:34:17 2012 -0500
@@ -1126,6 +1126,7 @@
     /* {"unbuffered",                   "-u"}, */
     /* {"skip_first",                   "-x"}, */
     {"bytes_warning", "-b"},
+    {"hash_randomization", "-R"},
     {0}
 };
 
@@ -1134,9 +1135,9 @@
     flags__doc__,       /* doc */
     flags_fields,       /* fields */
 #ifdef RISCOS
+    13
+#else
     12
-#else
-    11
 #endif
 };
 
@@ -1169,6 +1170,7 @@
     /* SetFlag(saw_unbuffered_flag); */
     /* SetFlag(skipfirstline); */
     SetFlag(Py_BytesWarningFlag);
+    SetFlag(Py_HashRandomizationFlag);
 #undef SetFlag
 
     if (PyErr_Occurred()) {

From report at bugs.python.org  Mon Feb 13 22:26:21 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 13 Feb 2012 21:26:21 +0000
Subject: [issue14001] Python v2.7.2 / v3.2.2 (SimpleXMLRPCServer): DoS
	(excessive CPU usage) by processing malformed XMLRPC / HTTP
	POST request
In-Reply-To: <1329140734.41.0.0376676358855.issue14001@psf.upfronthosting.co.za>
Message-ID: <1329168381.58.0.471116719034.issue14001@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/issue14001>
_______________________________________

From report at bugs.python.org  Mon Feb 13 23:25:58 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Feb 2012 22:25:58 +0000
Subject: [issue13930] lib2to3 ability to output files into a different
	directory and alter their names
In-Reply-To: <1328254888.57.0.86339015419.issue13930@psf.upfronthosting.co.za>
Message-ID: <1329171958.84.0.485502065622.issue13930@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: patch review -> committed/rejected
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13930>
_______________________________________

From report at bugs.python.org  Mon Feb 13 23:51:06 2012
From: report at bugs.python.org (Scott Bowman)
Date: Mon, 13 Feb 2012 22:51:06 +0000
Subject: [issue14005] IDLE Crash when running/saving a file
Message-ID: <1329173466.12.0.791681771945.issue14005@psf.upfronthosting.co.za>


New submission from Scott Bowman <scott.thomas.bowman at gmail.com>:

Whenever I save or try to run a program from the text editor window, IDLE crashes. Any suggestions? I'm running Windows 7, btw.

----------
components: None
messages: 153305
nosy: Scott.Bowman
priority: normal
severity: normal
status: open
title: IDLE Crash when running/saving a file
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14005>
_______________________________________

From report at bugs.python.org  Tue Feb 14 01:10:09 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Feb 2012 00:10:09 +0000
Subject: [issue13951] Seg Fault in .so called by ctypes causes the interpreter
	to Seg Fault
In-Reply-To: <1328535030.63.0.73417525944.issue13951@psf.upfronthosting.co.za>
Message-ID: <1329178209.77.0.433619471916.issue13951@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Should it seg fault or just throw an exception?

Python cannot do anything useful on such fatal error. In Python 3.3, there is a faulthandler module which can help to debug: it dumps the traceback of all threads on such fatal error. It is also available as a third party module on PyPI:
http://pypi.python.org/pypi/faulthandler

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13951>
_______________________________________

From report at bugs.python.org  Tue Feb 14 01:13:02 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 14 Feb 2012 00:13:02 +0000
Subject: [issue13930] lib2to3 ability to output files into a different
	directory and alter their names
In-Reply-To: <1328254888.57.0.86339015419.issue13930@psf.upfronthosting.co.za>
Message-ID: <1329178382.1.0.622669889298.issue13930@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

oh did I miss a / vs os.sep somewhere?  Looking.  I'll fix this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13930>
_______________________________________

From report at bugs.python.org  Tue Feb 14 01:17:37 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 14 Feb 2012 00:17:37 +0000
Subject: [issue13913] utf-8 or utf8 or utf-8 (codec display name inconsistency)
In-Reply-To: <1328030876.68.0.627537179228.issue13913@psf.upfronthosting.co.za>
Message-ID: <E1Rx65P-0007UK-Ln@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c861c0a7f40c by Victor Stinner in branch '3.2':
Issue #13913: normalize utf-8 codec name in UTF-8 decoder
http://hg.python.org/cpython/rev/c861c0a7f40c

New changeset af1a9508f7fa by Victor Stinner in branch 'default':
(Merge 3.2) Issue #13913: normalize utf-8 codec name in UTF-8 decoder
http://hg.python.org/cpython/rev/af1a9508f7fa

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13913>
_______________________________________

From report at bugs.python.org  Tue Feb 14 01:19:46 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Feb 2012 00:19:46 +0000
Subject: [issue13913] utf-8 or utf8 or utf-8 (codec display name inconsistency)
In-Reply-To: <1328030876.68.0.627537179228.issue13913@psf.upfronthosting.co.za>
Message-ID: <1329178786.48.0.327450213288.issue13913@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Use codecs.lookup(alias).name to the the normalize name of a codec. Examples:

>>> import codecs
>>> codecs.lookup('utf-8').name
'utf-8'
>>> codecs.lookup('iso-8859-1').name
'iso8859-1'
>>> codecs.lookup('latin1').name
'iso8859-1'
>>> codecs.lookup('iso2022_jp').name
'iso2022_jp'

All issues look to be addressed, so I close the issue. Thanks for the report!

----------
nosy: +haypo
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13913>
_______________________________________

From report at bugs.python.org  Tue Feb 14 01:23:27 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Feb 2012 00:23:27 +0000
Subject: [issue13927] Extra spaces in the output of time.ctime
In-Reply-To: <1328215776.48.0.974828105123.issue13927@psf.upfronthosting.co.za>
Message-ID: <1329179007.15.0.720575652887.issue13927@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> asctime() docs say it's a 24 char string.

I'm not sure that all platform conform to this "specification"... which is not future proof!

$ ./python 
Python 3.3.0a0 (default:af1a9508f7fa, Feb 14 2012, 01:18:15) 
[GCC 4.6.2 20111027 (Red Hat 4.6.2-1)] on linux
>>> import time
>>> time.ctime(2**38)
'Wed Jul 14 08:09:04 10680'
>>> len(time.ctime(2**38))
25

I suppose that you can say that the month day is formatted as 2 characters (padded with a space if needed).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13927>
_______________________________________

From report at bugs.python.org  Tue Feb 14 01:25:57 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Feb 2012 00:25:57 +0000
Subject: [issue13927] Extra spaces in the output of time.ctime
In-Reply-To: <1328215776.48.0.974828105123.issue13927@psf.upfronthosting.co.za>
Message-ID: <1329179157.29.0.842349886477.issue13927@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Or you could give the strftime specification string that produces the equivalent output.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13927>
_______________________________________

From report at bugs.python.org  Tue Feb 14 01:28:52 2012
From: report at bugs.python.org (Aaron Staley)
Date: Tue, 14 Feb 2012 00:28:52 +0000
Subject: [issue13992] Segfault in PyTrash_destroy_chain
In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za>
Message-ID: <1329179332.58.0.464996045355.issue13992@psf.upfronthosting.co.za>


Aaron Staley <usaar33 at gmail.com> added the comment:

I see no invalid read/write. Only warnings are some conditional jump depends on uninitialized value in pycrypto's libraries very early on though.

The link seems to be a different bug from mine.  I did test in python 2.6.7 and the crash still occurs.  (I also never get a segfault on my system with the link's test case - perhaps that only occurs in osx?)

To do the async exception, I use ctypes.pythonapi.PyThreadState_SetAsyncExc in python itself.  This is relatively rarely used however.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13992>
_______________________________________

From report at bugs.python.org  Tue Feb 14 01:29:37 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 14 Feb 2012 00:29:37 +0000
Subject: [issue13930] lib2to3 ability to output files into a different
	directory and alter their names
In-Reply-To: <1328254888.57.0.86339015419.issue13930@psf.upfronthosting.co.za>
Message-ID: <E1Rx6H2-0008Hs-6U@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6fd16782ecb8 by Gregory P. Smith in branch '3.2':
Issue #13930: fix a / to use os.sep so that the test works on Windows.
http://hg.python.org/cpython/rev/6fd16782ecb8

New changeset f13fbd848d50 by Gregory P. Smith in branch 'default':
Issue #13930: fix a / to use os.sep so that the test works on Windows.
http://hg.python.org/cpython/rev/f13fbd848d50

New changeset 34445738954b by Gregory P. Smith in branch '2.7':
Issue #13930: fix a / to use os.sep so that the test works on Windows.
http://hg.python.org/cpython/rev/34445738954b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13930>
_______________________________________

From report at bugs.python.org  Tue Feb 14 02:35:27 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Feb 2012 01:35:27 +0000
Subject: [issue13706] non-ascii fill characters no longer work in formatting
In-Reply-To: <1325630185.42.0.0487894537415.issue13706@psf.upfronthosting.co.za>
Message-ID: <1329183327.38.0.659769275835.issue13706@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

thousands_separator.patch:
 - Remove the unused _PyUnicode_InsertThousandsGroupingLocale() function
 - Add a test for non-ASCII thousands separator (depend on the locale)
 - _PyUnicode_InsertThousandsGrouping() expects thousands separator as a Unicode object and return the maximum character if unicode is NULL
 - Fix str.__format__() for non-ASCII thousands separator

Note: the patch handles also non-ASCII decimal point, even I don't know any locale using such point.

----------
keywords: +patch
Added file: http://bugs.python.org/file24516/thousands_separator.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13706>
_______________________________________

From report at bugs.python.org  Tue Feb 14 03:27:54 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 14 Feb 2012 02:27:54 +0000
Subject: [issue13930] lib2to3 ability to output files into a different
	directory and alter their names
In-Reply-To: <1328254888.57.0.86339015419.issue13930@psf.upfronthosting.co.za>
Message-ID: <1329186474.48.0.366880134617.issue13930@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13930>
_______________________________________

From report at bugs.python.org  Tue Feb 14 03:35:46 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Feb 2012 02:35:46 +0000
Subject: [issue13193] packaging.tests.test_manifest and
	distutils.tests.test_filelist failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1329186946.4.0.588449980981.issue13193@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Sorry I was unavailable.  I read and approved of the patch but could not push, so thanks for doing it :)

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Tue Feb 14 04:22:09 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 14 Feb 2012 03:22:09 +0000
Subject: [issue13229] Improve tools for iterating over filesystem directories
In-Reply-To: <1319076330.7.0.757546324527.issue13229@psf.upfronthosting.co.za>
Message-ID: <1329189729.95.0.872063380238.issue13229@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

WalkDir attempts to handle symlink loops, but the test suite doesn't currently ensure that that handling works as expected (I did some initial manual tests and haven't updated it since, though).

It's... not trivial: https://bitbucket.org/ncoghlan/walkdir/src/1b239056e9d5/walkdir.py#cl-163

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13229>
_______________________________________

From report at bugs.python.org  Tue Feb 14 04:25:59 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 14 Feb 2012 03:25:59 +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: <1329189959.45.0.669253001543.issue7475@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It's still on my radar to come back and have a look at it. Feedback from the web folks doing Python 3 migrations is that it would have helped them in quite a few cases.

I want to get a couple of other open PEPs out of the way first, though (mainly 394 and 409)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Tue Feb 14 04:28:45 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 14 Feb 2012 03:28:45 +0000
Subject: [issue14006] Improve the documentation of xml.etree.ElementTree
Message-ID: <1329190125.69.0.69162565954.issue14006@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

The documentation of xml.etree.ElementTree has to be improved. The first, very obvious step, would be to start the documentation page with a general overview of the module + some simple examples. The current opening section makes no sense for this module.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 153318
nosy: docs at python, eli.bendersky, eric.araujo, ezio.melotti, flox, scoder
priority: normal
severity: normal
status: open
title: Improve the documentation of xml.etree.ElementTree
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14006>
_______________________________________

From report at bugs.python.org  Tue Feb 14 04:31:23 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 14 Feb 2012 03:31:23 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329190283.0.0.938647320372.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I would add to the TODO - improve the documentation of the module. Opened issue 14006 for this.

----------
resolution: fixed -> 
stage: committed/rejected -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Tue Feb 14 04:32:56 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 14 Feb 2012 03:32:56 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329190376.13.0.824514351341.issue13988@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Tue Feb 14 04:40:15 2012
From: report at bugs.python.org (Jeremy Fishman)
Date: Tue, 14 Feb 2012 03:40:15 +0000
Subject: [issue11380] "close failed in file object destructor" when "Broken
	pipe" happens on stdout
In-Reply-To: <1299115966.12.0.337666295395.issue11380@psf.upfronthosting.co.za>
Message-ID: <1329190815.43.0.809543975922.issue11380@psf.upfronthosting.co.za>


Jeremy Fishman <jeremy.r.fishman at gmail.com> added the comment:

The behavior under question here is how the interpreter handles a broken pipe during shutdown.  The following code behaves as expected when either (a) the process receives a SIGINT or (b) the output pipe is closed

import sys
try:
    while True:
        print 'y'
except KeyboardInterrupt:
    sys.exit(130)
except (IOError, OSError):
    sys.exit(141)

However, in the case of a SIGINT sent to the entire process group e.g. from a shell prompt, the interpreter may receive the SIGINT before detecting the broken pipe.  In this case, the interpreter prints an error somewhere during the SIGINT handler or subsequent shutdown.

In Python 2.4.6 and 2.5.2 the error is
    close failed: [Errno 32] Broken pipe

In Python 2.7.2 the error is
    close failed in file object destructor:
    sys.excepthook is missing
    lost sys.stderr

In Python 3.2 the error is
    Exception IOError: IOError(32, 'Broken pipe') in <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> ignored

I have not succeeded in triggering the error in Python 3.1.2, despite ensuring the signal arrived before the next write(2) call after the output pipe was closed.  I have attached some straces, but this difference is probably spurious unless reproduced with one of the later bugfix 3.1 releases.

In all versions, the program properly terminates with code 130, or 141 if the write(2) error occurs first.

I would say the bug here if any is inconsistent behavior, though that isn't surprising between major versions.  The 2.7 error message is the only misleading one - stderr was never "lost", and we don't really care about sys.excepthook here.

----------
nosy: +Jeremy.Fishman
Added file: http://bugs.python.org/file24517/python-sigint_and_epipe_straces.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11380>
_______________________________________

From report at bugs.python.org  Tue Feb 14 04:56:59 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 14 Feb 2012 03:56:59 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329191819.73.0.208372825048.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I started going over the deprecated methods in ElementTree and ran into a more serious problem. XmlParser.doctype() is listed as deprecated, and indeed ElementTree (the Python version) issues a deprecation warning. However, the C implementation doesn't have doctype() at all so I get AttributeError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Tue Feb 14 05:01:55 2012
From: report at bugs.python.org (Aaron Staley)
Date: Tue, 14 Feb 2012 04:01:55 +0000
Subject: [issue13992] Segfault in PyTrash_destroy_chain
In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za>
Message-ID: <1329192115.13.0.211613762365.issue13992@psf.upfronthosting.co.za>


Aaron Staley <usaar33 at gmail.com> added the comment:

BTW, I take back what I said about using PyThreadState_SetAsyncExc.  Turns out I had a bug where this function would never succeed (was always returning 0).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13992>
_______________________________________

From report at bugs.python.org  Tue Feb 14 05:08:06 2012
From: report at bugs.python.org (Philip Jenvey)
Date: Tue, 14 Feb 2012 04:08:06 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329192486.03.0.163933144057.issue13988@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

DeprecationWarnings aren't that annoying anymore now that they're silent by default. It should at least have a PendingDeprecationWarning

----------
nosy: +pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Tue Feb 14 05:16:28 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 14 Feb 2012 04:16:28 +0000
Subject: [issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's
	doctype() method missing
Message-ID: <1329192988.64.0.354189735973.issue14007@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

Although documented, the C accelerator of xml.etree.ElementTree (used by default since issue 13988) does not use or define the doctype() methods of the XMLParser and TreeBuilder classes, although this method is documented.

As far as I can tell, this problem exists in 3.2 as well and wasn't introduced by the changes in issue 13988.

----------
components: Library (Lib)
messages: 153324
nosy: effbot, eli.bendersky, ezio.melotti, flox
priority: high
severity: normal
stage: needs patch
status: open
title: xml.etree.ElementTree - XMLParser and TreeBuilder's doctype() method missing
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14007>
_______________________________________

From report at bugs.python.org  Tue Feb 14 05:18:18 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 14 Feb 2012 04:18:18 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329193098.72.0.606141563202.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

The doctype() problem is deeper, since neither does TreeBuilder implement it (although for this class it's not even deprecated). Since this appears to be a problem in 3.2 as well, I'm opening a new issue - 14007, to track this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Tue Feb 14 05:18:50 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 14 Feb 2012 04:18:50 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329193130.63.0.0190484890255.issue13988@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
Removed message: http://bugs.python.org/msg153325

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Tue Feb 14 05:19:08 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 14 Feb 2012 04:19:08 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329193148.05.0.0192538856072.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Opened issue 14007 to track the doctype() problem

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Tue Feb 14 05:19:09 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 14 Feb 2012 04:19:09 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329193149.35.0.509864716716.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Opened issue 14007 to track the doctype() problem

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Tue Feb 14 05:19:29 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 14 Feb 2012 04:19:29 +0000
Subject: [issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's
	doctype() method missing
Message-ID: <1329193169.95.0.608335539767.issue14007@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
Removed message: http://bugs.python.org/msg153324

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14007>
_______________________________________

From report at bugs.python.org  Tue Feb 14 05:19:50 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 14 Feb 2012 04:19:50 +0000
Subject: [issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's
	doctype() method missing
Message-ID: <1329193190.72.0.667201124226.issue14007@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

The C accelerator of xml.etree.ElementTree (used by default since issue 13988) does not use or define or use the doctype() methods of the XMLParser and TreeBuilder classes, although this method is documented.

As far as I can tell, this problem exists in 3.2 as well and wasn't introduced by the changes in issue 13988.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14007>
_______________________________________

From report at bugs.python.org  Tue Feb 14 05:20:02 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 14 Feb 2012 04:20:02 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329193202.21.0.953278577598.issue13988@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
Removed message: http://bugs.python.org/msg153327

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Tue Feb 14 05:25:49 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 14 Feb 2012 04:25:49 +0000
Subject: [issue13979] Automatic *libc.so loading behaviour
In-Reply-To: <1328821808.41.0.811189579105.issue13979@psf.upfronthosting.co.za>
Message-ID: <E1Rx9xb-0002pS-GR@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ac362fb3b86b by Meador Inge in branch '3.2':
Issue #13979: Fix ctypes.util.find_library ldconfig regex
http://hg.python.org/cpython/rev/ac362fb3b86b

New changeset be41abd74949 by Meador Inge in branch '2.7':
Issue #13979: Fix ctypes.util.find_library ldconfig regex
http://hg.python.org/cpython/rev/be41abd74949

New changeset 096e856a01aa by Meador Inge in branch 'default':
Issue #13979: Fix ctypes.util.find_library ldconfig regex
http://hg.python.org/cpython/rev/096e856a01aa

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13979>
_______________________________________

From report at bugs.python.org  Tue Feb 14 05:27:18 2012
From: report at bugs.python.org (Meador Inge)
Date: Tue, 14 Feb 2012 04:27:18 +0000
Subject: [issue13979] Automatic *libc.so loading behaviour
In-Reply-To: <1328821808.41.0.811189579105.issue13979@psf.upfronthosting.co.za>
Message-ID: <1329193638.32.0.444477612649.issue13979@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13979>
_______________________________________

From report at bugs.python.org  Tue Feb 14 05:39:50 2012
From: report at bugs.python.org (Meador Inge)
Date: Tue, 14 Feb 2012 04:39:50 +0000
Subject: [issue6259] ctypes pointer arithmetic
In-Reply-To: <1244662680.17.0.41540856406.issue6259@psf.upfronthosting.co.za>
Message-ID: <1329194390.05.0.474979778669.issue6259@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6259>
_______________________________________

From report at bugs.python.org  Tue Feb 14 05:51:47 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 14 Feb 2012 04:51:47 +0000
Subject: [issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's
	doctype() method missing
In-Reply-To: <1329193190.72.0.667201124226.issue14007@psf.upfronthosting.co.za>
Message-ID: <1329195107.23.0.191988399685.issue14007@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

The problem is deeper. _elementtree does not expose XMLParser and TreeBuilder as types at all, just as factory functions.

XMLParser: not sure if it was meant to be subclassed. If not, it should at least be documented. In any case, the XMLParser in _elementtree does not use the doctype() method on its target.

TreeBuilder: was definitely meant to be subclassed (it's documented explicitly), so it must be exposed as a type, not as a factory function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14007>
_______________________________________

From report at bugs.python.org  Tue Feb 14 06:44:52 2012
From: report at bugs.python.org (Meador Inge)
Date: Tue, 14 Feb 2012 05:44:52 +0000
Subject: [issue9041] raised exception is misleading
In-Reply-To: <1277123013.52.0.887079191328.issue9041@psf.upfronthosting.co.za>
Message-ID: <1329198292.17.0.730141258843.issue9041@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

After thinking about it a bit more I am OK with Vinay's proposal.  Attached is an updated patch.

Also, I also noticed that the 'struct' module has the same problem:

>>> big_int = int(sys.float_info.max) * 2
>>> struct.pack('d', big_int)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
struct.error: required argument is not a float

but the 'array' module does the right thing:

>>> big_int = int(sys.float_info.max) * 2
[68068 refs]
>>> array.array('d', [big_int])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to float
[68068 refs]
>>> array.array('d', [""])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: a float is required

Mark, do you have any opinions on the error handling here and in the struct module?

----------
nosy: +mark.dickinson
versions: +Python 2.7, Python 3.2
Added file: http://bugs.python.org/file24518/issue9041-v0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9041>
_______________________________________

From report at bugs.python.org  Tue Feb 14 08:33:50 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 14 Feb 2012 07:33:50 +0000
Subject: [issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's
	doctype() method missing
In-Reply-To: <1329193190.72.0.667201124226.issue14007@psf.upfronthosting.co.za>
Message-ID: <1329204830.09.0.293828169305.issue14007@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

For the doctype() issue, it might be removed, since it was already deprecated in 3.2 (in compliance with PEP 387). However the deprecation cycle is under discussion for the 3.x serie. (issue 13248)

For subclassing, you hit the same issue for all the functions exposed by _elementtree, including Element fatory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14007>
_______________________________________

From report at bugs.python.org  Tue Feb 14 10:19:19 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 14 Feb 2012 09:19:19 +0000
Subject: [issue13706] non-ascii fill characters no longer work in formatting
In-Reply-To: <1325630185.42.0.0487894537415.issue13706@psf.upfronthosting.co.za>
Message-ID: <1329211159.28.0.509675151215.issue13706@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I'm using ps_AF for testing:

$ ./localeconv_wchar ps_AF
size of wchar_t: 32 bits
decimal_point byte string: "\xd9\xab" (2 bytes)
decimal_point wide string: L"\u066b" (1 characters)
thousands_sep byte string: "\xd9\xac" (2 bytes)
thousands_sep wide string: L"\u066c" (1 characters)
currency_symbol byte string: "\xd8\xa7\xd9\x81\xd8\xba\xd8\xa7\xd9\x86\xdb\x8d" (12 bytes)
currency_symbol wide string: L"\u0627\u0641\u063a\u0627\u0646\u06cd" (6 characters)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13706>
_______________________________________

From report at bugs.python.org  Tue Feb 14 11:49:27 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 14 Feb 2012 10:49:27 +0000
Subject: [issue14006] Improve the documentation of xml.etree.ElementTree
In-Reply-To: <1329190125.69.0.69162565954.issue14006@psf.upfronthosting.co.za>
Message-ID: <1329216567.24.0.975886137791.issue14006@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/issue14006>
_______________________________________

From report at bugs.python.org  Tue Feb 14 11:49:41 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 14 Feb 2012 10:49:41 +0000
Subject: [issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's
	doctype() method missing
In-Reply-To: <1329193190.72.0.667201124226.issue14007@psf.upfronthosting.co.za>
Message-ID: <1329216581.68.0.778330298827.issue14007@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/issue14007>
_______________________________________

From report at bugs.python.org  Tue Feb 14 11:49:58 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 14 Feb 2012 10:49:58 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1329216598.61.0.885700553209.issue13248@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/issue13248>
_______________________________________

From report at bugs.python.org  Tue Feb 14 11:51:35 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 14 Feb 2012 10:51:35 +0000
Subject: [issue9856] Change object.__format__(s) where s is non-empty to a
	TypeError
In-Reply-To: <1284485218.75.0.159147258754.issue9856@psf.upfronthosting.co.za>
Message-ID: <1329216695.22.0.884393920604.issue9856@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/issue9856>
_______________________________________

From report at bugs.python.org  Tue Feb 14 12:00:34 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 14 Feb 2012 11:00:34 +0000
Subject: [issue14006] Improve the documentation of xml.etree.ElementTree
In-Reply-To: <1329190125.69.0.69162565954.issue14006@psf.upfronthosting.co.za>
Message-ID: <1329217234.18.0.582377834817.issue14006@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Both lxml and ElementTree have tutorials:

http://effbot.org/zone/element.htm

http://lxml.de/tutorial.html

Here is another tutorial that may server as a source for an intro:

http://infohost.nmt.edu/tcc/help/pubs/pylxml/web/index.html

And the general ET documentation is here:

http://effbot.org/zone/element-index.htm#documentation

In terms of licensing, I can't speak for any of the other sources, but as for the lxml documentation, feel free to copy any ET related parts of it that you see fit.

I think the lxml tutorial is gentle enough even for beginners to follow. Note, however, that it uses lxml specific APIs in some places. In the specific case of XPath, the examples should be easily replaced with ElementPath, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14006>
_______________________________________

From report at bugs.python.org  Tue Feb 14 12:03:38 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 14 Feb 2012 11:03:38 +0000
Subject: [issue14006] Improve the documentation of xml.etree.ElementTree
In-Reply-To: <1329190125.69.0.69162565954.issue14006@psf.upfronthosting.co.za>
Message-ID: <1329217418.32.0.312065385611.issue14006@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Oh, and here are the ReST sources of the lxml docs:

https://github.com/lxml/lxml/tree/master/doc/

Specifically the tutorial:

https://raw.github.com/lxml/lxml/master/doc/tutorial.txt

and the parsing part:

https://raw.github.com/lxml/lxml/master/doc/parsing.txt

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14006>
_______________________________________

From report at bugs.python.org  Tue Feb 14 12:14:58 2012
From: report at bugs.python.org (Geoffrey Spear)
Date: Tue, 14 Feb 2012 11:14:58 +0000
Subject: [issue8739] Update to smtpd.py to RFC 5321
In-Reply-To: <1274103249.44.0.284620021799.issue8739@psf.upfronthosting.co.za>
Message-ID: <1329218098.63.0.751056925302.issue8739@psf.upfronthosting.co.za>


Changes by Geoffrey Spear <geoffspear at gmail.com>:


----------
nosy: +wooble

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8739>
_______________________________________

From report at bugs.python.org  Tue Feb 14 12:25:31 2012
From: report at bugs.python.org (Jan Lieskovsky)
Date: Tue, 14 Feb 2012 11:25:31 +0000
Subject: [issue14001] CVE-2012-0845 Python v2.7.2 / v3.2.2
	(SimpleXMLRPCServer): DoS (excessive CPU usage) by processing
	malformed XMLRPC / HTTP POST request
In-Reply-To: <1329140734.41.0.0376676358855.issue14001@psf.upfronthosting.co.za>
Message-ID: <1329218731.35.0.999271685478.issue14001@psf.upfronthosting.co.za>


Jan Lieskovsky <iankko at seznam.cz> added the comment:

The CVE identifier of CVE-2012-0845 has been assigned to this issue:
[3] http://www.openwall.com/lists/oss-security/2012/02/13/4

----------
title: Python v2.7.2 / v3.2.2 (SimpleXMLRPCServer): DoS (excessive CPU usage) by processing malformed XMLRPC / HTTP POST request -> CVE-2012-0845 Python v2.7.2 / v3.2.2 (SimpleXMLRPCServer): DoS (excessive CPU usage) by processing malformed XMLRPC / HTTP POST request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14001>
_______________________________________

From report at bugs.python.org  Tue Feb 14 12:38:59 2012
From: report at bugs.python.org (Yuval Greenfield)
Date: Tue, 14 Feb 2012 11:38:59 +0000
Subject: [issue14008] Python uses the new source when reporting an old
	exception
Message-ID: <1329219539.12.0.054946832037.issue14008@psf.upfronthosting.co.za>


New submission from Yuval Greenfield <ubershmekel at gmail.com>:

I ran the following code:

    import time
    time.sleep(10)
    print 1 / 0


And then modified the source before it hit the exception, python prints out the wrong lines from the new source file.


    e:\Dropbox\dev\python\metricbot>c:\python32\python test.py
    Traceback (most recent call last):
      File "test.py", line 3, in <module>
        alkdf;alsdkf;l
    ZeroDivisionError: division by zero


What should have been printed out:

    e:\Dropbox\dev\python\metricbot>test.py
    Traceback (most recent call last):
      File "E:\Dropbox\dev\python\metricbot\test.py", line 3, in <module>
        print 1 / 0
    ZeroDivisionError: integer division or modulo by zero


Although this is a toy example, I did run in to the problem when working on a long running script that I was upgrading.

Tested it and got the same results on python 2.7 and 3.2.

----------
components: Interpreter Core
messages: 153337
nosy: ubershmekel
priority: normal
severity: normal
status: open
title: Python uses the new source when reporting an old exception
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14008>
_______________________________________

From report at bugs.python.org  Tue Feb 14 13:29:24 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 14 Feb 2012 12:29:24 +0000
Subject: [issue14001] CVE-2012-0845 Python v2.7.2 / v3.2.2
	(SimpleXMLRPCServer): DoS (excessive CPU usage) by processing
	malformed XMLRPC / HTTP POST request
In-Reply-To: <1329140734.41.0.0376676358855.issue14001@psf.upfronthosting.co.za>
Message-ID: <1329222564.61.0.182493563477.issue14001@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14001>
_______________________________________

From report at bugs.python.org  Tue Feb 14 14:17:51 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 14 Feb 2012 13:17:51 +0000
Subject: [issue14008] Python uses the new source when reporting an old
	exception
In-Reply-To: <1329219539.12.0.054946832037.issue14008@psf.upfronthosting.co.za>
Message-ID: <1329225471.41.0.34507030776.issue14008@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Unupdated source file in traceback

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14008>
_______________________________________

From report at bugs.python.org  Tue Feb 14 14:42:22 2012
From: report at bugs.python.org (Yuval Greenfield)
Date: Tue, 14 Feb 2012 13:42:22 +0000
Subject: [issue8087] Unupdated source file in traceback
In-Reply-To: <1267990809.73.0.116039880896.issue8087@psf.upfronthosting.co.za>
Message-ID: <1329226942.26.0.473486819993.issue8087@psf.upfronthosting.co.za>


Changes by Yuval Greenfield <ubershmekel at gmail.com>:


----------
nosy: +ubershmekel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8087>
_______________________________________

From report at bugs.python.org  Tue Feb 14 14:54:55 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Feb 2012 13:54:55 +0000
Subject: [issue14001] CVE-2012-0845 Python v2.7.2 / v3.2.2
	(SimpleXMLRPCServer): DoS (excessive CPU usage) by processing
	malformed XMLRPC / HTTP POST request
In-Reply-To: <1329140734.41.0.0376676358855.issue14001@psf.upfronthosting.co.za>
Message-ID: <1329227695.83.0.590769911838.issue14001@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14001>
_______________________________________

From report at bugs.python.org  Tue Feb 14 16:26:43 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Feb 2012 15:26:43 +0000
Subject: [issue14009] Clearer documentation for cElementTree
Message-ID: <1329233203.38.0.944311933185.issue14009@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

This patch should clarify how to use cElementTree usage, as well as improving indexing.

----------
assignee: docs at python
components: Documentation
messages: 153338
nosy: docs at python, eli.bendersky, eric.araujo
priority: normal
severity: normal
stage: commit review
status: open
title: Clearer documentation for cElementTree
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14009>
_______________________________________

From report at bugs.python.org  Tue Feb 14 16:27:43 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Feb 2012 15:27:43 +0000
Subject: [issue14009] Clearer documentation for cElementTree
In-Reply-To: <1329233203.38.0.944311933185.issue14009@psf.upfronthosting.co.za>
Message-ID: <1329233263.81.0.665544879212.issue14009@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file24519/doc-cET.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14009>
_______________________________________

From report at bugs.python.org  Tue Feb 14 16:37:37 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Feb 2012 15:37:37 +0000
Subject: [issue13953] Get rid of doctests in packaging.tests.test_version
In-Reply-To: <1328554740.27.0.167211242761.issue13953@psf.upfronthosting.co.za>
Message-ID: <1329233857.92.0.920179343772.issue13953@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Does a "doc test" test the output literally?
Yes, that?s the problem.  See doctest documentation for more info about how it works and what problems it has.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13953>
_______________________________________

From report at bugs.python.org  Tue Feb 14 16:37:42 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Feb 2012 15:37:42 +0000
Subject: [issue13198] Remove duplicate definition of write_record_file
In-Reply-To: <1318857154.54.0.641953188635.issue13198@psf.upfronthosting.co.za>
Message-ID: <1329233862.38.0.370790380444.issue13198@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Damn, bitten by the use of universal newlines!  I guess I should split on a literal '\n' instead of calling splitlines.  Could you make that change in your clone and tell me if it does the trick?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13198>
_______________________________________

From report at bugs.python.org  Tue Feb 14 16:38:12 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Feb 2012 15:38:12 +0000
Subject: [issue14004] Distutils filelist selects too many files on Windows
In-Reply-To: <1329166628.27.0.616152401371.issue14004@psf.upfronthosting.co.za>
Message-ID: <1329233892.84.0.80985871036.issue14004@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This code just got changed (#13193) to use '/' instead of os.path.join, as it is documented that paths in MANIFEST.in must use only '/'.  Can you build an up-to-date Python 2.7 from Mercurial and check again?

Your report comes timely, as there was some doubt about what the correct fix was.  Even if your bug is now gone, I?ll want to add a regression test for it.

----------
assignee: tarek -> eric.araujo
keywords: +easy
stage:  -> test needed
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14004>
_______________________________________

From report at bugs.python.org  Tue Feb 14 16:41:19 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Feb 2012 15:41:19 +0000
Subject: [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>
Message-ID: <1329234079.29.0.25765177872.issue13491@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think you can commit your patch, with our without merging execute_[12].py, as you think best.  Then you can do other patches (with or without pre-commit review) to fix or clean up the examples.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13491>
_______________________________________

From report at bugs.python.org  Tue Feb 14 16:48:31 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Feb 2012 15:48:31 +0000
Subject: [issue14002] distutils2 fails to install a package from PyPI on
	Python 2.7.2
In-Reply-To: <1329147128.07.0.548553326464.issue14002@psf.upfronthosting.co.za>
Message-ID: <1329234511.81.0.409084033967.issue14002@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The initial errors look like complaints about existing packages I have installed by other means
They?re logging messages, not errors.  They appear because distutils2 scans sys.path for egg-info and egg files/dirs and reports invalid versions (per PEP 386).  Can you report a bug about them?  We do want a warning or an error when someone puts an invalid version in their setup.cfg, but when we?re scanning installed distributions it?s useless to warn.

> The final one looks like a bug in distutils2
I can reproduce it on Debian.  A test should not be hard to add, adding the ?easy? keyword.

----------
assignee: tarek -> eric.araujo
keywords: +easy
stage:  -> test needed
versions: +3rd party, Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14002>
_______________________________________

From report at bugs.python.org  Tue Feb 14 16:58:26 2012
From: report at bugs.python.org (Alex Gaynor)
Date: Tue, 14 Feb 2012 15:58:26 +0000
Subject: [issue14010] deeply nested filter segfaults
Message-ID: <1329235106.54.0.737183388066.issue14010@psf.upfronthosting.co.za>


New submission from Alex Gaynor <alex.gaynor at gmail.com>:

http://paste.pocoo.org/show/550884/ will reliably segfault Python3 on all platforms (similar versions for Python2 using itertools work)

----------
components: Interpreter Core
messages: 153344
nosy: alex, benjamin.peterson
priority: normal
severity: normal
status: open
title: deeply nested filter segfaults
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14010>
_______________________________________

From report at bugs.python.org  Tue Feb 14 17:01:48 2012
From: report at bugs.python.org (Jim Jewett)
Date: Tue, 14 Feb 2012 16:01:48 +0000
Subject: [issue8087] Unupdated source file in traceback
In-Reply-To: <1267990809.73.0.116039880896.issue8087@psf.upfronthosting.co.za>
Message-ID: <1329235308.92.0.860889485349.issue8087@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at gmail.com> added the comment:

Martin v. L?wis (loewis) wrote:

> Displaying a warning whenever the code has changed on disk is
> clearly unacceptable

As clarified, the request is only for when a traceback is being created (or perhaps even only for when one is being printed).  

I agree that we don't want to watch every file every time any code is run, but by the time a traceback is being displayed, any tight loops are ending.

Nick Coghlan (ncoghlan) wrote:

> There are a few different cases: ...
> 2. Source has been changed, but module has not been reloaded ...
> 3. Source has been changed, module has been reloaded, but object ...

Given that a traceback is being displayed, I think it is reasonable to rerun the find-module portion of import, and verify that there is not stale byte-code.  

Frankly, I think it would be worth storing a file timestamp on modules, and verifying that whatever-would-be-imported-if-imported-now matches that timestamp.  This would also catch case (3).

I also think that -- on traceback display -- it might be worth verifying that the code's __globals__ is the __globals__ associated with the module of that name in sys.modules.  This would warn about some intentional manipulations, but would catch case (3) even more accurately.

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8087>
_______________________________________

From report at bugs.python.org  Tue Feb 14 17:03:51 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Feb 2012 16:03:51 +0000
Subject: [issue14011] packaging should use shutil archiving functions
	transparently
Message-ID: <1329235431.19.0.233591312424.issue14011@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

The packaging commands sdist and bdist can create various kinds of archives.  The function used to create them is thankfully just a thin wrapper around shutil.make_archive (extracted from distutils), and sdist also uses shutil.get_archive_formats to validate its --formats option.  bdist however maintains its own registry.

The docstrings, help texts and reST documentation also contain out-of-sync duplicate lists of allowed formats.

I?m working on a patch to fix this duplication.

----------
assignee: eric.araujo
components: Distutils2
messages: 153346
nosy: alexis, eric.araujo
priority: normal
severity: normal
status: open
title: packaging should use shutil archiving functions transparently
type: enhancement
versions: 3rd party, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14011>
_______________________________________

From report at bugs.python.org  Tue Feb 14 17:10:06 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 14 Feb 2012 16:10:06 +0000
Subject: [issue14005] IDLE Crash when running/saving a file
In-Reply-To: <1329173466.12.0.791681771945.issue14005@psf.upfronthosting.co.za>
Message-ID: <1329235806.94.0.964440811074.issue14005@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Try running IDLE from a command prompt and report the error message you see. Start a python shell session and run:

    import idlelib.idle

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14005>
_______________________________________

From report at bugs.python.org  Tue Feb 14 17:10:37 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Feb 2012 16:10:37 +0000
Subject: [issue14012] Misc tarfile fixes
Message-ID: <1329235837.42.0.144867770777.issue14012@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I found a few possible bugs in tarfile:

- ?mode in 'raw'? can give false positives for '' or 'ra'.  Most of the code also checks for ?len(mode) > 1?, but I find clearer and safer to just use ?mode in ('r', 'a', 'w')?.

- To use the shadowed builtin ?open?, tarfile uses both ?import as? and a local alias ?bltin_open = open?.  However, the second idiom would break if tarfile were reloaded.

- Error messages don?t say what the invalid mode was.  (Error messages are not part of the language, but nonetheless maybe it?s best not to commit that to stable branches.)

----------
components: Library (Lib)
files: tarfile-misc-bugs-3.2.diff
keywords: patch
messages: 153348
nosy: eric.araujo, lars.gustaebel
priority: normal
severity: normal
stage: commit review
status: open
title: Misc tarfile fixes
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24520/tarfile-misc-bugs-3.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14012>
_______________________________________

From report at bugs.python.org  Tue Feb 14 17:13:23 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 14 Feb 2012 16:13:23 +0000
Subject: [issue14011] packaging should use shutil archiving functions
	transparently
In-Reply-To: <1329235431.19.0.233591312424.issue14011@psf.upfronthosting.co.za>
Message-ID: <1329236003.49.0.282201952464.issue14011@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
components: +Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14011>
_______________________________________

From report at bugs.python.org  Tue Feb 14 17:18:31 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Feb 2012 16:18:31 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1329236311.6.0.647080501574.issue6715@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

BTW, any plans on a PyPI backport for fun and profit?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue Feb 14 17:20:23 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 14 Feb 2012 16:20:23 +0000
Subject: [issue14010] deeply nested filter segfaults
In-Reply-To: <1329235106.54.0.737183388066.issue14010@psf.upfronthosting.co.za>
Message-ID: <1329236423.29.0.981675389595.issue14010@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14010>
_______________________________________

From report at bugs.python.org  Tue Feb 14 17:27:27 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Feb 2012 16:27:27 +0000
Subject: [issue14013] tarfile should expose supported formats
Message-ID: <1329236847.51.0.270430673151.issue14013@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

shutil contains high-level functions to create a zipfile or a tarball.  When a new format is added to the tarfile module, then shutil needs to be updated manually.  If tarfile exposed the names of the compressors it supports, then shutil could just automatically support everything that tarfile supports instead of having to re-do import dances for optional modules (bz2, lzma, zlib) and also duplicate formats in its doc.

This may also be useful for other code wanting to do some introspection.

Attached patch implements tarfile.formats, a list of strings (I thought about using a frozenset but then followed the precedent set by the 3.3 crypt module).  Tests and docs not updated, I wanted to get Lars? approval on the principle first.

One could argue that this is not needed: compression modules are not added often; updating shutil after updating tarfile is not hard; it is not that useful to have access to the list of supported formats.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 153350
nosy: docs at python, eric.araujo, lars.gustaebel, nadeem.vawda
priority: normal
severity: normal
stage: patch review
status: open
title: tarfile should expose supported formats
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14013>
_______________________________________

From report at bugs.python.org  Tue Feb 14 17:29:16 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Feb 2012 16:29:16 +0000
Subject: [issue14013] tarfile should expose supported formats
In-Reply-To: <1329236847.51.0.270430673151.issue14013@psf.upfronthosting.co.za>
Message-ID: <1329236956.42.0.994332213124.issue14013@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file24521/add-tarfile.formats.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14013>
_______________________________________

From report at bugs.python.org  Tue Feb 14 17:34:23 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Feb 2012 16:34:23 +0000
Subject: [issue5411] add xz compression support to shutil
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1329237263.18.0.74196135542.issue5411@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

a) is #14013; b) is #14011.

If Lars agrees to #14013, I will withdraw this patch in favor of another one that would make shutil automatically support all compressors that tarfile supports (my b) point).

Note that this is not going to be pain-free, as for example bzip2 compression is obtained with the strings ?bz2?, ?bzip2?, ?bzip? or ?bztar? depending on the modules; I think it?s worth it nonetheless, even if I have to add an ugly conversion in shutil for compat.

----------
dependencies: +tarfile should expose supported formats

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5411>
_______________________________________

From report at bugs.python.org  Tue Feb 14 17:55:06 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 14 Feb 2012 16:55:06 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1329238506.46.0.664859728315.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> BTW, any plans on a PyPI backport for fun and profit?

At present, no. I'll look into it later in the year, but at the moment
I don't have the time to work on it - I suspect the parts written in C
will require substantial changes to work under 2.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue Feb 14 18:11:20 2012
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 14 Feb 2012 17:11:20 +0000
Subject: [issue14010] deeply nested filter segfaults
In-Reply-To: <1329235106.54.0.737183388066.issue14010@psf.upfronthosting.co.za>
Message-ID: <1329239480.82.0.493743358347.issue14010@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

The issue is a stack exhaustion.  Examples can be trivially made for any iterator that takes another iterator as argument: itertools.takewhile(), zip() in Python3, etc. etc.

It's just one of many places where CPython does a recursion without checking the recursion depth.  CPython still works, based on the resonable assumption that doing such a recursion here is obscure.

Someone seriously bored could start with some C-based callgraph builder; or alternatively use PyPy, which finds such recursions automatically in its own source, and compare all places where a recursion check is inserted with the corresponding place in CPython.  There are a large number of them (761, not counting the JIT), so be patient :-(

----------
nosy: +arigo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14010>
_______________________________________

From report at bugs.python.org  Tue Feb 14 19:01:53 2012
From: report at bugs.python.org (Jim Jewett)
Date: Tue, 14 Feb 2012 18:01:53 +0000
Subject: [issue14014] codecs.StreamWriter.reset contract not fulfilled
Message-ID: <1329242513.77.0.581823861095.issue14014@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at gmail.com>:

def reset(self):

        """ Flushes and resets the codec buffers used for keeping state.

            Calling this method should ensure that the data on the
            output is put into a clean state, that allows appending
            of new fresh data without having to rescan the whole
            stream to recover state.

        """
        pass

This does not ensure that the stream is flushed, as the docstring promises.  I believe the following would work better.


    def reset(self):
        """ Flushes and resets the codec buffers used for keeping state.

            Calling this method should ensure that the data on the
            output is put into a clean state, that allows appending
            of new fresh data without having to rescan the whole
            stream to recover state.

        """
        if hasattr(self.stream, "flush"): self.stream.flush()

----------
components: Unicode
messages: 153354
nosy: Jim.Jewett, ezio.melotti
priority: normal
severity: normal
status: open
title: codecs.StreamWriter.reset contract not fulfilled
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14014>
_______________________________________

From report at bugs.python.org  Tue Feb 14 19:10:31 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 14 Feb 2012 18:10:31 +0000
Subject: [issue13992] Segfault in PyTrash_destroy_chain
In-Reply-To: <1329192115.13.0.211613762365.issue13992@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2JAEO40YBDK7ikQ43q9vXHwsuuhT3m5Lac4cJ2bN_5uw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I'm running out of ideas to debug this, maybe Antoine or Amaury can help :-)

One last idea (not sure it will work though):
If Channel's finalizer gets called twice, inside Channel.__del__, you
could save a string representation of the current backtrace as an
attribute, and print the previous and current backtrace is there is
already one such attribute (i.e. print the backtrace if __del__ is
called twice).
There may be false positives (for example a finalizer resurecting the
object would end up in __del__ being called twice), but it might yield
useful info.
You might also want to save the thread ID and time.

But this is really strange...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13992>
_______________________________________

From report at bugs.python.org  Tue Feb 14 19:27:43 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 14 Feb 2012 18:27:43 +0000
Subject: [issue14001] CVE-2012-0845 Python v2.7.2 / v3.2.2
	(SimpleXMLRPCServer): DoS (excessive CPU usage) by processing
	malformed XMLRPC / HTTP POST request
In-Reply-To: <1329140734.41.0.0376676358855.issue14001@psf.upfronthosting.co.za>
Message-ID: <1329244063.17.0.576722971681.issue14001@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

With test.
test_xmlrpc has a timeout detection code which is simply broken (and it's actually documented): I just removed it, so if the server loops, the test will block. I think it's acceptable since other tests behave in the same way, and those days we have faulthandler that can be used to pinpoint such deadlocks/loops easily. Also, I've noticed that people are more inclined to fix tests that block than mere failing tests :-)

----------
Added file: http://bugs.python.org/file24522/xmlrpc_loop-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14001>
_______________________________________

From report at bugs.python.org  Tue Feb 14 19:43:06 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 14 Feb 2012 18:43:06 +0000
Subject: [issue13878] test_sched failures on Windows buildbot
In-Reply-To: <1328987911.63.0.319219760247.issue13878@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3gQVBOxeTTphh6fENheefmz-eM4U8+6QuR+70i5f2NKQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Well, it's not really needed, as long as scheduler deals correctly
with expired deadlines.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13878>
_______________________________________

From report at bugs.python.org  Tue Feb 14 19:43:09 2012
From: report at bugs.python.org (Andrew McNabb)
Date: Tue, 14 Feb 2012 18:43:09 +0000
Subject: [issue13881] Stream encoder for zlib_codec doesn't use the
	incremental encoder
In-Reply-To: <1327606849.1.0.885842099772.issue13881@psf.upfronthosting.co.za>
Message-ID: <1329244989.19.0.000352559598685.issue13881@psf.upfronthosting.co.za>


Andrew McNabb <amcnabb at mcnabbs.org> added the comment:

It looks like encodings/zlib_codec.py defines a custom IncrementalEncoder and IncrementalDecoder, but its StreamWriter and StreamReader rely on the standard implementation of codecs.StreamWriter and codecs.StreamReader.

One solution might be to have zlib_codec.StreamWriter inherit from zlib_codec.IncrementalEncoder instead of from zlib_encoder.Codec. I'm not familiar enough with the codecs library to know whether this is the best approach.

Unfortunately, there are 120 codec files in the encodings directory, and it's unclear how many of them would need to be modified. Based on the number of them that implement StreamWriter as "class StreamWriter(Codec,codecs.StreamWriter)", it looks like it might be a lot of them. Was each of these 120 files hand-written?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13881>
_______________________________________

From report at bugs.python.org  Tue Feb 14 19:53:02 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Feb 2012 18:53:02 +0000
Subject: [issue13881] Stream encoder for zlib_codec doesn't use the
	incremental encoder
In-Reply-To: <1327606849.1.0.885842099772.issue13881@psf.upfronthosting.co.za>
Message-ID: <1329245582.36.0.881745986389.issue13881@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13881>
_______________________________________

From report at bugs.python.org  Tue Feb 14 19:56:30 2012
From: report at bugs.python.org (Jim Jewett)
Date: Tue, 14 Feb 2012 18:56:30 +0000
Subject: [issue14015] surrogateescape largely missing from documentation
Message-ID: <1329245790.15.0.430373154575.issue14015@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at gmail.com>:

Recent discussion on the mailing lists and in http://bugs.python.org/issue13997 make it clear that the best way to get python2 results for "ASCII-in-the-parts-I-might-process-or-change" is to replace 

    f = open(fname)
with
    f = open(fname, encoding="ascii", errors="surrogateescape")

Unfortunately, surrogateescape (let alone this recipe) is not easily discoverable.  

http://docs.python.org/dev/library/functions.html#open lists 5 error-handlers -- but not this one.  It says that other error handlers are possible if they are registered with http://docs.python.org/dev/library/codecs.html#codecs.register_error but I haven't found a way to determine which error handlers are already registered.

The codecs.register (as opposed to register_error) documentation does list it as a possible value, but that is the only reference.

The other 5 error handlers are also available as module-level functions within the codecs module, and have their own documenation sections within http://docs.python.org/dev/library/codecs.html

Neither help(open) nor import codecs; help(codecs) provides any hints of the existence of surrogateescape.  Both explicitly suggest that it does not exist, by enumerating other values.

----------
assignee: docs at python
components: Documentation, Unicode
messages: 153359
nosy: Jim.Jewett, docs at python, ezio.melotti
priority: normal
severity: normal
status: open
title: surrogateescape largely missing from documentation
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14015>
_______________________________________

From report at bugs.python.org  Tue Feb 14 19:57:29 2012
From: report at bugs.python.org (Jim Jewett)
Date: Tue, 14 Feb 2012 18:57:29 +0000
Subject: [issue13997] Clearly explain the bare minimum Python 3 users should
	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329245849.37.0.308576097241.issue13997@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at gmail.com> added the comment:

See bugs/python.org/issue14015 for one reason that surrogateescape isn't better known.

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Tue Feb 14 20:12:27 2012
From: report at bugs.python.org (Srikantha Kadur)
Date: Tue, 14 Feb 2012 19:12:27 +0000
Subject: [issue14016] Usage of socket.sendall() in multiple threads
Message-ID: <1329246747.9.0.165584216371.issue14016@psf.upfronthosting.co.za>


New submission from Srikantha Kadur <srikanthkadur at gmail.com>:

Here is my code.

    Func1():
        .
        .
        CliSock, addr = ServSocket.accept()
        print 'DataPortServ:Connected by', addr
	data.DataSendSock = CliSock
        
	for cnt in range(data.ThreadCnt):
            SessionId = startSessionId + SessionIdCnt* cnt      
            thread.start_new_thread(ThreadHandleDataPort,(("Thead"+str(cnt)),data,EventCnt[cnt],EventCnt[cnt+1],UECntPerThread,ip,SessionId))
            time.sleep(0.005)

ThreadHandleDataPort(args):
    #here i use socket.sendall
     while True:
        if ( 3 != data.bRunFlag):     
           if (len(data.AddedEvents) != 0) | (len(data.AddedReasons) != 0):
               #time.sleep(5)
     	       for EventCnt in range(StartEvent,StopEvent):
                   .
                   .
                   .
                   data.DataSendSock.sendall(SendEvent)
                   .
                   .

My application is a server and it accepts connection from the client on a port and start sending some messages to the client. While sending messages i use multiple threads for the same socket based on required traffic. 

I do not modify any global variables but i read only global variables.But at high Loads my messages are being corrupted, here is the snippet of the corruption

actual message should have been 
ABS1,1328577019.57,181138955,

instead im getting
ABS1,1329218634.91,181ABS1

so here is my Q:
Do i need to lock the socket before sending inside the threads or Python modules will take care of it? Please suggest.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 153361
nosy: srikadur
priority: normal
severity: normal
status: open
title: Usage of socket.sendall() in multiple threads
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14016>
_______________________________________

From report at bugs.python.org  Tue Feb 14 20:16:52 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Feb 2012 19:16:52 +0000
Subject: [issue14016] Usage of socket.sendall() in multiple threads
In-Reply-To: <1329246747.9.0.165584216371.issue14016@psf.upfronthosting.co.za>
Message-ID: <1329247012.47.0.0619546599015.issue14016@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This isn't really the place to get help on using python, but no, python doesn't do any implicit locking for you.

----------
nosy: +r.david.murray
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14016>
_______________________________________

From report at bugs.python.org  Tue Feb 14 20:20:23 2012
From: report at bugs.python.org (Paul Moore)
Date: Tue, 14 Feb 2012 19:20:23 +0000
Subject: [issue13198] Remove duplicate definition of write_record_file
In-Reply-To: <1329233862.38.0.370790380444.issue13198@psf.upfronthosting.co.za>
Message-ID: <CACac1F_Rx8z7=w42BirYnh=cJ13FzqZn8AsnmyBPhSVHxVGCMg@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

> Damn, bitten by the use of universal newlines! ?I guess I should split on a literal '\n' instead of calling splitlines. ?Could you make that change in your clone and tell me if it does the trick?

Not for a few days, but I'll check when I'm back home

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13198>
_______________________________________

From report at bugs.python.org  Tue Feb 14 20:20:28 2012
From: report at bugs.python.org (Srikantha Kadur)
Date: Tue, 14 Feb 2012 19:20:28 +0000
Subject: [issue14016] Usage of socket.sendall() in multiple threads
In-Reply-To: <1329246747.9.0.165584216371.issue14016@psf.upfronthosting.co.za>
Message-ID: <1329247228.03.0.361939110606.issue14016@psf.upfronthosting.co.za>


Srikantha Kadur <srikanthkadur at gmail.com> added the comment:

Thanks David,
  as the last available option i used this tool.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14016>
_______________________________________

From report at bugs.python.org  Tue Feb 14 20:31:18 2012
From: report at bugs.python.org (Paul Moore)
Date: Tue, 14 Feb 2012 19:31:18 +0000
Subject: [issue14002] distutils2 fails to install a package from PyPI on
	Python 2.7.2
In-Reply-To: <1329234511.81.0.409084033967.issue14002@psf.upfronthosting.co.za>
Message-ID: <CACac1F9ipMMYN61BG=UhYOFq=dvFbHknjp9D0YKSHo9XtgYBLA@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

On 14 February 2012 15:48, ?ric Araujo <report at bugs.python.org> wrote:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
>> The initial errors look like complaints about existing packages I have installed by other means
> They?re logging messages, not errors. ?They appear because distutils2 scans sys.path for egg-info and egg files/dirs and reports invalid versions
> (per PEP 386). ?Can you report a bug about them? ?We do want a warning or an error when someone puts an invalid version in their setup.cfg,
> but when we?re scanning installed distributions it?s useless to warn.

To what? The individual packages? Maybe, but I'm not sure how useful
that would be. For example, pywin32 has been using 3-digit versions
like this forever, and I don't see them changing just on the basis of
this (but I may be wrong). PyPI seems to handle pywin32's version
fine...

I'd rather say that it's a bug in distutils2 that it complains about
perfectly valid distributions. I'd be OK with a "verify" flag/action
that checked existing installed distributions, but I see no reason for
any message (informational, warning, or whatever) when you're just
asking for a new distribution to be installed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14002>
_______________________________________

From report at bugs.python.org  Tue Feb 14 20:33:56 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 14 Feb 2012 19:33:56 +0000
Subject: [issue13878] test_sched failures on Windows buildbot
In-Reply-To: <1327597038.78.0.0899603043053.issue13878@psf.upfronthosting.co.za>
Message-ID: <1329248036.03.0.741910694701.issue13878@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Ah, I suppose that makes sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13878>
_______________________________________

From report at bugs.python.org  Tue Feb 14 20:37:30 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 14 Feb 2012 19:37:30 +0000
Subject: [issue1326113] Letting "build_ext --libraries" take more than one lib
Message-ID: <1329248250.81.0.653124930413.issue1326113@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Ran into this bug today in 2.7 (building python-sybase with freetds).  The fix in msg121260 took care of it (didn't try the patch).  Thanks, ?ric.  

Is this something that could get patched in the upcoming micro releases?  It's not so important for me at this point, and I'm not sure how often it will come up, but it's also a very simple fix.

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1326113>
_______________________________________

From report at bugs.python.org  Tue Feb 14 20:46:50 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 14 Feb 2012 19:46:50 +0000
Subject: [issue9127] subprocess.Popen.communicate() and SIGCHLD handlers
In-Reply-To: <1277913297.34.0.963310724242.issue9127@psf.upfronthosting.co.za>
Message-ID: <1329248810.54.0.590134226675.issue9127@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fixed via http://hg.python.org/cpython/rev/767420808a62

----------
dependencies: +race condition in subprocess module
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9127>
_______________________________________

From report at bugs.python.org  Tue Feb 14 21:34:56 2012
From: report at bugs.python.org (Jim Jewett)
Date: Tue, 14 Feb 2012 20:34:56 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1329165382.27728.1.camel@surprise>
Message-ID: <CA+OGgf5qbP6srm4zvHOJbQGf2VN4QabjJAJuoLH=5_dnxNi7=A@mail.gmail.com>


Jim Jewett <jimjjewett at gmail.com> added the comment:

On Mon, Feb 13, 2012 at 3:37 PM,  Dave Malcolm
<dmalcolm at redhat.com> added the comment:

> ?* added comments about the specialcasing of length 0:
> ? ?/*
> ? ? ?We make the hash of the empty string be 0, rather than using
> ? ? ?(prefix ^ suffix), since this slightly obfuscates the hash secret
> ? ?*/

Frankly, other short strings may give away even more, because you can
put several into the same dict.

I would prefer that the randomization not kick in until strings are at
least 8 characters, but I think excluding length 1 is a pretty obvious
win.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Tue Feb 14 22:04:16 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Feb 2012 21:04:16 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1329253456.87.0.943093759746.issue10287@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think the patch is fine. Will apply soon (thanks!)
.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10287>
_______________________________________

From report at bugs.python.org  Tue Feb 14 22:32:31 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 14 Feb 2012 21:32:31 +0000
Subject: [issue14004] Distutils filelist selects too many files on Windows
In-Reply-To: <1329166628.27.0.616152401371.issue14004@psf.upfronthosting.co.za>
Message-ID: <1329255151.6.0.029053984933.issue14004@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

I've been able to reproduce this on current builds of 2.7, 3.2 and 3.3.

The problem seems to be that distutils.filelist pathnames using the OS
directory separator, but the regexps used for matching paths are written
to always assume "/"-based paths.

I've been able to get the correct behaviour in this case by making the
module build paths using "/" regardless of the OS directory separator:

    --- a/Lib/distutils/filelist.py
    +++ b/Lib/distutils/filelist.py
    @@ -55,10 +55,10 @@

         def sort(self):
             # Not a strict lexical sort!
    -        sortable_files = sorted(map(os.path.split, self.files))
    +        sortable_files = sorted(f.split("/") for f in self.files)
             self.files = []
             for sort_tuple in sortable_files:
    -            self.files.append(os.path.join(*sort_tuple))
    +            self.files.append("/".join(sort_tuple))


         # -- Other miscellaneous utility methods ---------------------------
    @@ -258,7 +258,7 @@

             for name in names:
                 if dir != os.curdir:        # avoid the dreaded "./" syndrome
    -                fullname = os.path.join(dir, name)
    +                fullname = dir + "/" + name
                 else:
                     fullname = name

I'm not entirely comfortable with this fix, though - it seems like it
would be better to produce paths using the OS directory separator at the
end of the process. Maybe it's possible to add a translation step after
the file list is built and de-duplicated? I don't know much about how
the rest of distutils uses this module.

(Random aside: do we support any platforms that don't support "/" as a
directory separator (even if it isn't the preferred one)? Hmm...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14004>
_______________________________________

From report at bugs.python.org  Tue Feb 14 22:44:55 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Tue, 14 Feb 2012 21:44:55 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2 and
	python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1329255895.97.0.577269541636.issue6784@psf.upfronthosting.co.za>


Changes by Merlijn van Deen <valhallasw at gmail.com>:


----------
nosy: +valhallasw

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Tue Feb 14 22:48:23 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Feb 2012 21:48:23 +0000
Subject: [issue13881] Stream encoder for zlib_codec doesn't use the
	incremental encoder
In-Reply-To: <1327606849.1.0.885842099772.issue13881@psf.upfronthosting.co.za>
Message-ID: <1329256103.28.0.265572522167.issue13881@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

See also issue #7475.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13881>
_______________________________________

From report at bugs.python.org  Tue Feb 14 23:33:49 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 14 Feb 2012 22:33:49 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <E1RxQwV-0007BM-E1@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a7f1ffd741d6 by Antoine Pitrou in branch '3.2':
Issue #10287: nntplib now queries the server's CAPABILITIES first before sending MODE READER, and only sends it if not already in READER mode.
http://hg.python.org/cpython/rev/a7f1ffd741d6

New changeset 03019bb62d83 by Antoine Pitrou in branch 'default':
Issue #10287: nntplib now queries the server's CAPABILITIES first before sending MODE READER, and only sends it if not already in READER mode.
http://hg.python.org/cpython/rev/03019bb62d83

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10287>
_______________________________________

From report at bugs.python.org  Tue Feb 14 23:34:12 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Feb 2012 22:34:12 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1329258852.81.0.518834352176.issue10287@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This issue can now be closed for good.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10287>
_______________________________________

From report at bugs.python.org  Tue Feb 14 23:34:38 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Feb 2012 22:34:38 +0000
Subject: [issue14001] CVE-2012-0845 Python v2.7.2 / v3.2.2
	(SimpleXMLRPCServer): DoS (excessive CPU usage) by processing
	malformed XMLRPC / HTTP POST request
In-Reply-To: <1329140734.41.0.0376676358855.issue14001@psf.upfronthosting.co.za>
Message-ID: <1329258878.86.0.089943709862.issue14001@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch looks ok to me.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14001>
_______________________________________

From report at bugs.python.org  Wed Feb 15 00:27:26 2012
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 14 Feb 2012 23:27:26 +0000
Subject: [issue14015] surrogateescape largely missing from documentation
In-Reply-To: <1329245790.15.0.430373154575.issue14015@psf.upfronthosting.co.za>
Message-ID: <1329262046.29.0.262760978224.issue14015@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14015>
_______________________________________

From report at bugs.python.org  Wed Feb 15 00:49:33 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 14 Feb 2012 23:49:33 +0000
Subject: [issue14017] io.TextIOWrapper should expose a documented
	write_through attribute
Message-ID: <1329263373.63.0.201487376726.issue14017@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

io.TextIOWrapper acquired a new "write_through" argument for 3.3, but that is not exposed as a documented attribute.

This is needed so that a text wrapper can be replaced with an equivalent that only alters selected settings (such as the Unicode error handler).

----------
components: Library (Lib)
messages: 153376
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: io.TextIOWrapper should expose a documented write_through attribute
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14017>
_______________________________________

From report at bugs.python.org  Wed Feb 15 00:59:34 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 14 Feb 2012 23:59:34 +0000
Subject: [issue14017] Make it easy to create a new TextIOWrapper based on an
	existing
In-Reply-To: <1329263373.63.0.201487376726.issue14017@psf.upfronthosting.co.za>
Message-ID: <1329263974.33.0.235260942954.issue14017@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Updating issue title, since I realised this doesn't work in 3.2 either (the "newline" argument also isn't available for introspection - "newlines" is not the same thing)

Possible API signature:

    _missing = object()
    def rewrap(self, encoding=_missing, errors=_missing, newline=_missing, line_buffering=_missing, write_through=_missing):
        pass

That is, accept the same arguments as __init__ (excluding the buffer argument), with any arguments not explicitly supplied replaced with the values from the current instance.

----------
title: io.TextIOWrapper should expose a documented write_through attribute -> Make it easy to create a new TextIOWrapper based on an existing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14017>
_______________________________________

From report at bugs.python.org  Wed Feb 15 01:04:27 2012
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 15 Feb 2012 00:04:27 +0000
Subject: [issue14004] Distutils filelist selects too many files on Windows
In-Reply-To: <1329166628.27.0.616152401371.issue14004@psf.upfronthosting.co.za>
Message-ID: <1329264267.46.0.165464134456.issue14004@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

The bug is indeed fixed in the latest 2.7 tip:

    PS C:\Users\jaraco\projects\public\keyring> C:\Users\jaraco\projects\public\cpython\PCbuild\amd64\python.exe setup.py sdist 2> NULL | findstr .hg
    (produces no output)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14004>
_______________________________________

From report at bugs.python.org  Wed Feb 15 01:06:10 2012
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 15 Feb 2012 00:06:10 +0000
Subject: [issue14004] Distutils filelist selects too many files on Windows
In-Reply-To: <1329166628.27.0.616152401371.issue14004@psf.upfronthosting.co.za>
Message-ID: <1329264370.6.0.369269644298.issue14004@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

If always using a posix path separator, I recommend using posixpath.join instead of hard-coding the path separator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14004>
_______________________________________

From report at bugs.python.org  Wed Feb 15 01:13:19 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Feb 2012 00:13:19 +0000
Subject: [issue14014] codecs.StreamWriter.reset contract not fulfilled
In-Reply-To: <1329242513.77.0.581823861095.issue14014@psf.upfronthosting.co.za>
Message-ID: <1329264799.29.0.495454574532.issue14014@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14014>
_______________________________________

From report at bugs.python.org  Wed Feb 15 01:17:41 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Wed, 15 Feb 2012 00:17:41 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1329265061.63.0.0339432166365.issue13609@psf.upfronthosting.co.za>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

> New try (I fixed my email address and the patch).
>
> The purpose of os.get_terminal_size() is the same as `stty size`, so 
> `stty size` could be a model for behavior of os.get_terminal_size().
I guess that this fallback will make some things easier. As long it is documented, the user should be able to get whatever behaviour they want.

I have four small questions:
- -1 is used as the argument meaning "try stdout and stdin". But -1 is 
  also used the error return value for open(2) and other system 
  functions. I know that Python checks the return value to throw an 
  exception, and -1 shouldn't "leak" and be passed by mistake to 
  os.get_terminal_size(). Can someone confirm that this is
  the case?
- Why stderr is not checked too? It would make os.get_terminal_size()
  return the real terminal value in a the middle of a pipe:
    cat | python -c 'import os; os.get_terminal_size()' | cat.
- some doc change is missing
- in the new version the line with ioctl(fd, TIOCGWINSZ, &w) repeats
  three times. It think it could be reduced to two without loss
  of readability.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Wed Feb 15 02:01:28 2012
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Feb 2012 01:01:28 +0000
Subject: [issue14018] OS X installer does not detect bad symlinks created by
	Xcode 3.2.6
Message-ID: <1329267688.42.0.5159808393.issue14018@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Xcode 3.2.6, the most recent release for OS X 10.6 (Snow Leopard), has a subtle but critical bug that affects Python builds using OS X SDKs (--enable-universalsdk=/Developer/SDKs/MacOSX10.?.sdk).  The Xcode installer creates faulty symlinks to /Library within  /Developer/SDKs.  The net effect is that frameworks installed in /Library, such as ActiveState Tcl and Tk, are not found during a build using the SDK as they should be.

$ cd /Developer/SDKs/MacOSX10.6.sdk/Library
$ ls -l
total 8
lrwxr-xr-x  1 root  wheel  19 Mar 17 18:24 Frameworks@ -> 
/Library/Frameworks
 
it ends up with an extra Frameworks directory so that
 
/Developer/SDKs/MacOSX10.6.sdk/Library/Frameworks/Frameworks/ -> /Library/Frameworks
 
The solution is to manually go in and fix the symlinks in 
/Developer/SDKs/MacOSX10.6.sdk, and remember to do so again if you have 
to reinstall Xcode 3.2.6.  AFAIK, this bug is unique to Xcode 3.2.6, not 
earlier versions of 3.2.x.

The effect on Python builds is that tkinter is linked against the Apple-supplied Tcl and Tk frameworks rather than the ActiveState ones which is not what is desired.

While the problem is created by Apple, the OS X Python installer build script, Mac/BuildScript/build-installer.py, should include a post-build check using otool -L that _tkinter.so is linked as expected.  The script already includes tests pre-build to ensure that the additional frameworks are in place.

----------
assignee: ned.deily
components: Build, Macintosh
messages: 153381
nosy: ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: OS X installer does not detect bad symlinks created by Xcode 3.2.6
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14018>
_______________________________________

From report at bugs.python.org  Wed Feb 15 02:04:46 2012
From: report at bugs.python.org (=?utf-8?q?Denilson_Figueiredo_de_S=C3=A1?=)
Date: Wed, 15 Feb 2012 01:04:46 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1329265061.63.0.0339432166365.issue13609@psf.upfronthosting.co.za>
Message-ID: <CACGt9ym91u-UPwOpC579qJvoiLxm4+vyb4WRTnTC+R5p4MHZQA@mail.gmail.com>


Denilson Figueiredo de S? <denilsonsa at gmail.com> added the comment:

On Tue, Feb 14, 2012 at 22:17, Zbyszek Szmek <report at bugs.python.org> wrote:
>
> I have four small questions:
> - -1 is used as the argument meaning "try stdout and stdin".
> - Why stderr is not checked too?

I propose the following solution: accept either an integer or a
sequence of integers as the fd parameter. In the second case, try each
FD until one of them returns the terminal size.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Wed Feb 15 02:36:38 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Feb 2012 01:36:38 +0000
Subject: [issue13090] posix_read: memory leak
In-Reply-To: <1317546629.79.0.861373881282.issue13090@psf.upfronthosting.co.za>
Message-ID: <1329269798.69.0.942996563378.issue13090@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I have a hard time believing posix_read in the culprit. Perhaps, on the other hand, that object is "lost" by test_multiprocessing without being decref'ed enough?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13090>
_______________________________________

From report at bugs.python.org  Wed Feb 15 02:40:11 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Feb 2012 01:40:11 +0000
Subject: [issue13092] pep-393: memory leaks #2
In-Reply-To: <1317548945.05.0.236513746453.issue13092@psf.upfronthosting.co.za>
Message-ID: <1329270011.87.0.0789980779418.issue13092@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

TextIOWrapper was already fixed, and the offending code in import.c seems to have disappeared.

----------
nosy: +pitrou
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13092>
_______________________________________

From report at bugs.python.org  Wed Feb 15 02:50:04 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Feb 2012 01:50:04 +0000
Subject: [issue13015] _collectionsmodule.c: refleak
In-Reply-To: <1316530406.22.0.00922720094034.issue13015@psf.upfronthosting.co.za>
Message-ID: <E1RxU0Q-0006Qk-8D@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 86adb5c7a9d4 by Antoine Pitrou in branch '3.2':
Issue #13015: Fix a possible reference leak in defaultdict.__repr__.
http://hg.python.org/cpython/rev/86adb5c7a9d4

New changeset 7cfce717ceee by Antoine Pitrou in branch 'default':
Issue #13015: Fix a possible reference leak in defaultdict.__repr__.
http://hg.python.org/cpython/rev/7cfce717ceee

New changeset 7611fb3e19c6 by Antoine Pitrou in branch '2.7':
Issue #13015: Fix a possible reference leak in defaultdict.__repr__.
http://hg.python.org/cpython/rev/7611fb3e19c6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13015>
_______________________________________

From report at bugs.python.org  Wed Feb 15 02:50:24 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Feb 2012 01:50:24 +0000
Subject: [issue13089] parsetok.c: memory leak
In-Reply-To: <1317545416.55.0.717898890924.issue13089@psf.upfronthosting.co.za>
Message-ID: <1329270624.63.0.742327237239.issue13089@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/issue13089>
_______________________________________

From report at bugs.python.org  Wed Feb 15 02:51:47 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Feb 2012 01:51:47 +0000
Subject: [issue13015] _collectionsmodule.c: refleak
In-Reply-To: <1316530406.22.0.00922720094034.issue13015@psf.upfronthosting.co.za>
Message-ID: <1329270707.14.0.836547714034.issue13015@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch now committed, thank you!

----------
nosy: +pitrou
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13015>
_______________________________________

From report at bugs.python.org  Wed Feb 15 03:00:56 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Feb 2012 02:00:56 +0000
Subject: [issue13020] structseq.c: refleak
In-Reply-To: <1316530655.8.0.189777030615.issue13020@psf.upfronthosting.co.za>
Message-ID: <E1RxUAu-0007J8-27@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6454e5de7c34 by Antoine Pitrou in branch '3.2':
Issue #13020: Fix a reference leak when allocating a structsequence object fails.
http://hg.python.org/cpython/rev/6454e5de7c34

New changeset 5e0085d67f65 by Antoine Pitrou in branch 'default':
Issue #13020: Fix a reference leak when allocating a structsequence object fails.
http://hg.python.org/cpython/rev/5e0085d67f65

New changeset 08a85fc85bf2 by Antoine Pitrou in branch '2.7':
Issue #13020: Fix a reference leak when allocating a structsequence object fails.
http://hg.python.org/cpython/rev/08a85fc85bf2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13020>
_______________________________________

From report at bugs.python.org  Wed Feb 15 03:01:30 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Feb 2012 02:01:30 +0000
Subject: [issue13020] structseq.c: refleak
In-Reply-To: <1316530655.8.0.189777030615.issue13020@psf.upfronthosting.co.za>
Message-ID: <1329271290.24.0.95689701042.issue13020@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've now committed the patch. Thanks for contributing!

----------
nosy: +pitrou
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13020>
_______________________________________

From report at bugs.python.org  Wed Feb 15 05:40:25 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 15 Feb 2012 04:40:25 +0000
Subject: [issue13579] string.Formatter doesn't understand the !a conversion
	specifier
In-Reply-To: <1323587450.48.0.625379374057.issue13579@psf.upfronthosting.co.za>
Message-ID: <1329280825.16.0.853034290031.issue13579@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Doc/library/string.rst string.Formatter().format(fmt, 10)needs a couple of changes also.

1. "format(format_string, *args, **kwargs) 
format() is the primary API method. It takes a format template string,"

I think 'template' should be removed as we elsewhere (as in the next section) just call them 'format strings'.

Note: I consider this and the preceding sentences

"The built-in string class provides the ability to do complex variable substitutions and value formatting via the format() method described in PEP 3101. The Formatter class in the string module allows you to create and customize your own string formatting behaviors using the same implementation as the built-in format() method."

to imply that this method should accept any format string that str.format does, and that the patch is a bug fix rather than enhancement. There is no mention of any limitation or subseting.

2. "convert_field(value, conversion) 
Converts the value (returned by get_field()) given a conversion type (as in the tuple returned by the parse() method). The default version understands ?r? (repr) and ?s? (str) conversion types."

Change "?r? (repr) and ?s? (str)" to "?s? (str), ?r? (repr), and ?a? (ascii)". I consider this a bug in the doc.

---
I discovered that string.Formatter.format has another problem:
it does not auto-number fields

>>> '{0}'.format(10) == '{}'.format(10) == '10'
True
>>> from string import Formatter as F
>>> F().format('{0}', 10)
'10'
>>> F().format('{}', 10)
Traceback (most recent call last):
  File "<pyshell#32>", line 1, in <module>
    F().format('{}', 10)
  File "C:\Programs\Python32\lib\string.py", line 180, in format
    return self.vformat(format_string, args, kwargs)
  File "C:\Programs\Python32\lib\string.py", line 184, in vformat
    result = self._vformat(format_string, args, kwargs, used_args, 2)
  File "C:\Programs\Python32\lib\string.py", line 206, in _vformat
    obj, arg_used = self.get_field(field_name, args, kwargs)
  File "C:\Programs\Python32\lib\string.py", line 267, in get_field
    obj = self.get_value(first, args, kwargs)
  File "C:\Programs\Python32\lib\string.py", line 226, in get_value
    return kwargs[key]
KeyError: ''

So it seems that str.format is either calling something other than _string.formatter_parser or else pre or post processing.

The underlying problem is trying to keep separate codes that do the same thing in sync without testing both with the same set of examples. If examples were in a table of (fmt, args, kwargs, output) tuples, it would be easy to call fmt.format(*args, **kwargs) and F().vformat(fmt, args, kwargs) with each and compare to expected. There are also the %format torture tests in test_format.py. Do % and {} formatting use any of the same code?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13579>
_______________________________________

From report at bugs.python.org  Wed Feb 15 05:40:51 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 15 Feb 2012 04:40:51 +0000
Subject: [issue13579] string.Formatter doesn't understand the !a conversion
	specifier
In-Reply-To: <1323587450.48.0.625379374057.issue13579@psf.upfronthosting.co.za>
Message-ID: <1329280851.33.0.30123626839.issue13579@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13579>
_______________________________________

From report at bugs.python.org  Wed Feb 15 07:34:39 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Wed, 15 Feb 2012 06:34:39 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <CACGt9ym91u-UPwOpC579qJvoiLxm4+vyb4WRTnTC+R5p4MHZQA@mail.gmail.com>
Message-ID: <4F3B51F7.7030806@in.waw.pl>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

Wouldn't this be quite unwieldy to use:
   os.get_terminal_size(sys.__stdout__.fileno(),
                        sys.__stdin__().fileno(),
                        sys.__stderr__.fileno())
?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Wed Feb 15 08:24:10 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 15 Feb 2012 07:24:10 +0000
Subject: [issue14004] Distutils filelist selects too many files on Windows
In-Reply-To: <1329166628.27.0.616152401371.issue14004@psf.upfronthosting.co.za>
Message-ID: <1329290650.52.0.0358638764516.issue14004@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> The bug is indeed fixed in the latest 2.7 tip:
>
>     PS C:\Users\jaraco\projects\public\keyring> C:\Users\jaraco\projects\public\cpython\PCbuild\amd64\python.exe setup.py sdist 2> NULL | findstr .hg
>    (produces no output)

I suspect you forgot to set DISTUTILS_DEBUG before running this -
otherwise that command should at least output a line like this:

    exclude_pattern: applying regex r'(^|/|\\)(RCS|CVS|\.svn|\.hg|\.git|\.bzr|_darcs)(/|\\).*'


> If always using a posix path separator, I recommend using posixpath.join instead of hard-coding the path separator.

Interesting. I had thought that posixpath and ntpath were each only
available on their respective platforms, but looking at the source,
I see that I was mistaken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14004>
_______________________________________

From report at bugs.python.org  Wed Feb 15 09:15:04 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 15 Feb 2012 08:15:04 +0000
Subject: [issue14019] Unify tests for str.format and string.Formatter
Message-ID: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

A couple of issues have arisen where features were added to str.format without similarly being added to string.Formatter.

This is only possible because the test cases for the two are currently almost entirely separate.

A common set of tests defined as (fmt, args, kwargs, output) tuples would help ensure that the implementations remained consistent in the future.

----------
components: Tests
messages: 153392
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Unify tests for str.format and string.Formatter
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14019>
_______________________________________

From report at bugs.python.org  Wed Feb 15 09:16:52 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 15 Feb 2012 08:16:52 +0000
Subject: [issue13579] string.Formatter doesn't understand the !a conversion
	specifier
In-Reply-To: <1323587450.48.0.625379374057.issue13579@psf.upfronthosting.co.za>
Message-ID: <1329293812.27.0.857179044391.issue13579@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Agreed that this is a bug in string.Formatter rather than a new feature.

There's already a separate bug for the autonumbering problem: http://bugs.python.org/issue13598

And I created a new issue about unifying some of the tests: http://bugs.python.org/issue14019

%-style string formatting is its own thing - it doesn't share semantics or code with str.format or string.Formatter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13579>
_______________________________________

From report at bugs.python.org  Wed Feb 15 09:20:57 2012
From: report at bugs.python.org (Jan Kratochvil)
Date: Wed, 15 Feb 2012 08:20:57 +0000
Subject: [issue10112] Use -Wl, --dynamic-list=x.list,
	not -Xlinker -export-dynamic
In-Reply-To: <1287137785.61.0.962664170792.issue10112@psf.upfronthosting.co.za>
Message-ID: <1329294057.68.0.404217747135.issue10112@psf.upfronthosting.co.za>


Jan Kratochvil <jan.kratochvil at redhat.com> added the comment:

What more can be done to get it fixed?  I do not mind Python but GDB linking is broken due to it.  And while I can workaround it in GDB I am not used for workarounding one Free package in another Free package.  Free software has the advantage problems can be fixed at the right place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10112>
_______________________________________

From report at bugs.python.org  Wed Feb 15 09:25:02 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 15 Feb 2012 08:25:02 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <CA+OGgf5qbP6srm4zvHOJbQGf2VN4QabjJAJuoLH=5_dnxNi7=A@mail.gmail.com>
Message-ID: <4F3B6BDB.5090004@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Frankly, other short strings may give away even more, because you can
> put several into the same dict.

Please don't make such claims without some reasonable security analysis:
how *exactly* would you derive the hash seed when you have the hash
values of all 256 one-byte strings (or all 2**20 one-char Unicode
strings)?

> I would prefer that the randomization not kick in until strings are at
> least 8 characters, but I think excluding length 1 is a pretty obvious
> win.

-1. It is very easy to create a good number of hash collisions already
with 6-character strings. You are opening the security hole again that
we are attempting to close.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Wed Feb 15 09:29:28 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 15 Feb 2012 08:29:28 +0000
Subject: [issue14001] CVE-2012-0845 Python v2.7.2 / v3.2.2
	(SimpleXMLRPCServer): DoS (excessive CPU usage) by processing
	malformed XMLRPC / HTTP POST request
In-Reply-To: <1329140734.41.0.0376676358855.issue14001@psf.upfronthosting.co.za>
Message-ID: <1329294568.14.0.0530957933586.issue14001@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As a security issue, it applies to 2.6 and 3.1 as well.

----------
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14001>
_______________________________________

From report at bugs.python.org  Wed Feb 15 10:01:50 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 15 Feb 2012 09:01:50 +0000
Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}"
In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za>
Message-ID: <1329296510.11.0.246160124729.issue13598@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

One potential problem with the simple approach to fixing this is that up until now, string.Formatter has been thread safe. Because all the formatting state was held in local variables and passed around as method arguments, there was no state on the instance object to protect.

Now, this only applies if you start using the new feature, but it should be noted in the documentation and What's New that you need to limit yourself to accessing each formatter instance from a single thread.

It's also enough for me to say "no, not in a maintenance release".

Adding two attributes also seems unnecessary, and the pre-increment looks strange. Why not:

In __init__:
    auto_field_count = 0

Then as the auto numbering checking, something like:

    auto_field_count = self.auto_field_count
    if field_name:
        if auto_field_count > 0:
           # Can't switch auto -> manual
        auto_field_count = -1
    elif auto_field_count < 0:
       # Can't switch manual -> auto
    else:
        field_name = str(auto_field_count)
        self.auto_field_count += 1

(Alternatively, I'd ask the question: why do we prevent mixing manual numbering and explicit numbering anyway? It's not like it's ambiguous at all)

----------
nosy: +ncoghlan
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13598>
_______________________________________

From report at bugs.python.org  Wed Feb 15 11:44:35 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Feb 2012 10:44:35 +0000
Subject: [issue13987] Handling of broken markup in HTMLParser on 2.7
In-Reply-To: <1328881558.78.0.634398241399.issue13987@psf.upfronthosting.co.za>
Message-ID: <E1RxcLi-0003P0-2L@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 11a31eb5da93 by Ezio Melotti in branch '2.7':
#13987: HTMLParser is now able to handle EOFs in the middle of a construct.
http://hg.python.org/cpython/rev/11a31eb5da93

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13987>
_______________________________________

From report at bugs.python.org  Wed Feb 15 12:19:31 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Feb 2012 11:19:31 +0000
Subject: [issue13987] Handling of broken markup in HTMLParser on 2.7
In-Reply-To: <1328881558.78.0.634398241399.issue13987@psf.upfronthosting.co.za>
Message-ID: <E1RxctQ-0006Rj-Vt@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3d7904e3f4b9 by Ezio Melotti in branch '2.7':
#13987: HTMLParser is now able to handle malformed start tags.
http://hg.python.org/cpython/rev/3d7904e3f4b9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13987>
_______________________________________

From report at bugs.python.org  Wed Feb 15 12:24:41 2012
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 15 Feb 2012 11:24:41 +0000
Subject: [issue14019] Unify tests for str.format and string.Formatter
In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za>
Message-ID: <1329305081.33.0.774469449535.issue14019@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14019>
_______________________________________

From report at bugs.python.org  Wed Feb 15 12:27:15 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Feb 2012 11:27:15 +0000
Subject: [issue13987] Handling of broken markup in HTMLParser on 2.7
In-Reply-To: <1328881558.78.0.634398241399.issue13987@psf.upfronthosting.co.za>
Message-ID: <1329305235.91.0.487590919481.issue13987@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This should be fixed now.
The first two chunks of the attached patch have been committed in the two changesets linked in the previous messages.  The third chunk about the end tag has been fixed as part of #13933.  The error previously raised by unknown_decl has been removed in 4743a3a1e669.  More fixes have been backported as part of #13960.
2.7 should now behave like 3.2 non-strict.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13987>
_______________________________________

From report at bugs.python.org  Wed Feb 15 14:59:33 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Feb 2012 13:59:33 +0000
Subject: [issue14020] Improve HTMLParser doc
Message-ID: <1329314372.41.0.194033246825.issue14020@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

Attached patch reworks a bit the HTMLParser doc:
 - moved the basic example on the top and showed the output;
 - added a more complete parser with other examples;
 - fixed some factual errors;
 - added additional information for some methods;
 - added a couple of headers to divide the sections;
 - rephrased the text a bit to be more coherent and clear;
 - fixed a few links, typos, and terms;

I think the note about IE condcoms could be removed by the handle_comment doc, since it's already in the examples at the bottom.  A note in handle_data about the behavior with buffered input might be added in addition to the example at the bottom.

----------
assignee: ezio.melotti
components: Documentation
files: issue14020.diff
keywords: patch
messages: 153401
nosy: eli.bendersky, eric.araujo, ezio.melotti, terry.reedy
priority: normal
severity: normal
stage: commit review
status: open
title: Improve HTMLParser doc
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24523/issue14020.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14020>
_______________________________________

From report at bugs.python.org  Wed Feb 15 16:23:05 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Feb 2012 15:23:05 +0000
Subject: [issue14015] surrogateescape largely missing from documentation
In-Reply-To: <1329245790.15.0.430373154575.issue14015@psf.upfronthosting.co.za>
Message-ID: <1329319385.15.0.212334589971.issue14015@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14015>
_______________________________________

From report at bugs.python.org  Wed Feb 15 16:23:59 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Wed, 15 Feb 2012 15:23:59 +0000
Subject: [issue7644] bug in nntplib.body() method with possible fix
In-Reply-To: <1262773754.82.0.67564143033.issue7644@psf.upfronthosting.co.za>
Message-ID: <1329319439.4.0.598850637815.issue7644@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

I have also added a test for NTTP.head(), enjoy.

----------
keywords: +patch
Added file: http://bugs.python.org/file24524/nntp-file-test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7644>
_______________________________________

From report at bugs.python.org  Wed Feb 15 16:35:01 2012
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 15 Feb 2012 15:35:01 +0000
Subject: [issue14004] Distutils filelist selects too many files on Windows
In-Reply-To: <1329290650.52.0.0358638764516.issue14004@psf.upfronthosting.co.za>
Message-ID: <7E79234E600438479EC119BD241B48D601E103F0@BY2PRD0610MB389.namprd06.prod.outlook.com>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

It's not that I forgot to set DISTUTILS_DEBUG, I simply did not set it. If the 
bug were still present, I would have seen a line indicating that 
.hg/last-message.txt was being copied.

For completeness, here's the output with the DEBUG setting:

    PS C:\Users\jaraco\projects\public\keyring> $env:DISTUTILS_DEBUG=1
    PS C:\Users\jaraco\projects\public\keyring> 
..\cpython\PCbuild\amd64\python.exe setup.py sdist 2> NULL | findstr hg
     adding .hg\last-message.txt
    exclude_pattern: applying regex 
r'(^|/|\\)(RCS|CVS|\.svn|\.hg|\.git|\.bzr|_darcs)(/|\\).*'
     removing .hg\last-message.txt

----------
Added file: http://bugs.python.org/file24525/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14004>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6662 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20120215/6149a812/attachment-0001.bin>

From report at bugs.python.org  Wed Feb 15 16:42:50 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Feb 2012 15:42:50 +0000
Subject: [issue14004] Distutils filelist selects too many files on Windows
In-Reply-To: <1329166628.27.0.616152401371.issue14004@psf.upfronthosting.co.za>
Message-ID: <1329320570.13.0.134269098385.issue14004@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

So it looks like that even if the exclusion of .hg removes .hg/last-message.txt, it should not have been added in the first place, as the command was include and not recursive-include.

At first glance, Nadeem?s proposed fix is not right: paths in MANIFEST.in use '/', but then filelist produces paths using os.sep, so that the MANIFEST file and other operations done by the sdist command use native paths.  So even though the currently supported OSes all accept '/', I think the right thing is to use os.sep.

(About posixpath: It is always available and can be used e.g. to manipulate URI paths.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14004>
_______________________________________

From report at bugs.python.org  Wed Feb 15 16:51:06 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Feb 2012 15:51:06 +0000
Subject: [issue12297] Clarifications to atexit.register and unregister doc
In-Reply-To: <1307634551.41.0.658857259056.issue12297@psf.upfronthosting.co.za>
Message-ID: <1329321066.33.0.794850961772.issue12297@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks.  I?ve also realized that the doc does not mention that any callable can be used; I don?t know if we should say it explicitly (I think I did a change like that recently in another file), or if we expect people to just know it from experience, or if we should add an entry for ?function? in the glossary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12297>
_______________________________________

From report at bugs.python.org  Wed Feb 15 16:55:45 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Feb 2012 15:55:45 +0000
Subject: [issue14020] Improve HTMLParser doc
In-Reply-To: <1329314372.41.0.194033246825.issue14020@psf.upfronthosting.co.za>
Message-ID: <1329321345.44.0.142283119455.issue14020@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Didn?t review in detail but the plan LGTM.

In a subsequent commit, you could update the markup to use nested class/method directives.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14020>
_______________________________________

From report at bugs.python.org  Wed Feb 15 17:15:08 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Feb 2012 16:15:08 +0000
Subject: [issue12297] Clarifications to atexit.register and unregister doc
In-Reply-To: <1307634551.41.0.658857259056.issue12297@psf.upfronthosting.co.za>
Message-ID: <E1RxhVa-0004lD-Lb@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 55fc092dad72 by ?ric Araujo in branch '3.2':
Improve doc for atexit.register and unregister (#12297)
http://hg.python.org/cpython/rev/55fc092dad72

New changeset f7163afecb97 by ?ric Araujo in branch 'default':
Merge fixes for #1326113 and #12297 from 3.2
http://hg.python.org/cpython/rev/f7163afecb97

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12297>
_______________________________________

From report at bugs.python.org  Wed Feb 15 17:15:08 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Feb 2012 16:15:08 +0000
Subject: [issue1326113] Letting "build_ext --libraries" take more than one lib
Message-ID: <E1RxhVa-0004lD-Jz@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 53df93a9c002 by ?ric Araujo in branch '3.2':
Fix parsing of build_ext --libraries option (#1326113)
http://hg.python.org/cpython/rev/53df93a9c002

New changeset f7163afecb97 by ?ric Araujo in branch 'default':
Merge fixes for #1326113 and #12297 from 3.2
http://hg.python.org/cpython/rev/f7163afecb97

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1326113>
_______________________________________

From report at bugs.python.org  Wed Feb 15 17:15:56 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Feb 2012 16:15:56 +0000
Subject: [issue1326113] Letting "build_ext --libraries" take more than one lib
Message-ID: <E1RxhWM-0004pX-JQ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 96f5718bf005 by ?ric Araujo in branch '2.7':
Fix parsing of build_ext --libraries option (#1326113)
http://hg.python.org/cpython/rev/96f5718bf005

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1326113>
_______________________________________

From report at bugs.python.org  Wed Feb 15 17:15:56 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Feb 2012 16:15:56 +0000
Subject: [issue12297] Clarifications to atexit.register and unregister doc
In-Reply-To: <1307634551.41.0.658857259056.issue12297@psf.upfronthosting.co.za>
Message-ID: <E1RxhWM-0004pX-Jb@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a99632426af5 by ?ric Araujo in branch '2.7':
Improve doc for atexit.register (#12297)
http://hg.python.org/cpython/rev/a99632426af5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12297>
_______________________________________

From report at bugs.python.org  Wed Feb 15 17:25:35 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Feb 2012 16:25:35 +0000
Subject: [issue1326113] Letting "build_ext --libraries" take more than one lib
Message-ID: <E1Rxhfh-0005ui-GX@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4ba43318e56b by ?ric Araujo in branch 'default':
Fix parsing of packaging?s build_ext --libraries option (#1326113)
http://hg.python.org/cpython/rev/4ba43318e56b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1326113>
_______________________________________

From report at bugs.python.org  Wed Feb 15 17:39:58 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Feb 2012 16:39:58 +0000
Subject: [issue1326113] Letting "build_ext --libraries" take more than one lib
Message-ID: <E1Rxhtd-0007Rv-2F@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 60dd0041c9bc by ?ric Araujo in branch 'default':
Fix parsing of build_ext --libraries option (#1326113)
http://hg.python.org/distutils2/rev/60dd0041c9bc

New changeset 158697fd8fa1 by ?ric Araujo in branch 'python3':
Merge #1326113 fix from default
http://hg.python.org/distutils2/rev/158697fd8fa1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1326113>
_______________________________________

From report at bugs.python.org  Wed Feb 15 17:41:29 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Feb 2012 16:41:29 +0000
Subject: [issue1326113] Letting "build_ext --libraries" take more than one lib
Message-ID: <1329324089.94.0.630421278176.issue1326113@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Here you are!  Thanks for the testing.

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1326113>
_______________________________________

From report at bugs.python.org  Wed Feb 15 17:46:46 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Feb 2012 16:46:46 +0000
Subject: [issue12297] Clarifications to atexit.register and unregister doc
In-Reply-To: <1307634551.41.0.658857259056.issue12297@psf.upfronthosting.co.za>
Message-ID: <1329324406.64.0.384958577114.issue12297@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Closing as fixed, but if you have any feedback on my function vs. callable question, please share.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12297>
_______________________________________

From report at bugs.python.org  Wed Feb 15 17:58:45 2012
From: report at bugs.python.org (=?utf-8?b?5YuH5YiaIOe9lw==?=)
Date: Wed, 15 Feb 2012 16:58:45 +0000
Subject: [issue14021] Write pkg_info with local encoding(GBK) will be a
	problem.
Message-ID: <1329325125.52.0.801195380714.issue14021@psf.upfronthosting.co.za>


New submission from ?? ? <luoyonggang at gmail.com>:

D:\CI\bld\vcs\pygit2>python setup.py install
Find C:\Python32\python.exe
Using C:\Python32\python.exe
running install
running bdist_egg
running egg_info
writing pygit2.egg-info\PKG-INFO
Traceback (most recent call last):
  File "setup.py", line 106, in <module>
    **kwargs)
  File "C:\Python32\lib\distutils\core.py", line 148, in setup
    dist.run_commands()
  File "C:\Python32\lib\distutils\dist.py", line 917, in run_commands
    self.run_command(cmd)
  File "C:\Python32\lib\distutils\dist.py", line 936, in run_command
    cmd_obj.run()
  File "C:\Python32\lib\site-packages\distribute-0.6.24-py3.2.egg\setuptools\command\install.py", line 73, in run
    self.do_egg_install()
  File "C:\Python32\lib\site-packages\distribute-0.6.24-py3.2.egg\setuptools\command\install.py", line 93, in do_egg_install
    self.run_command('bdist_egg')
  File "C:\Python32\lib\distutils\cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "C:\Python32\lib\distutils\dist.py", line 936, in run_command
    cmd_obj.run()
  File "C:\Python32\lib\site-packages\distribute-0.6.24-py3.2.egg\setuptools\command\bdist_egg.py", line 172, in run
    self.run_command("egg_info")
  File "C:\Python32\lib\distutils\cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "C:\Python32\lib\distutils\dist.py", line 936, in run_command
    cmd_obj.run()
  File "C:\Python32\lib\site-packages\distribute-0.6.24-py3.2.egg\setuptools\command\egg_info.py", line 172, in run
    writer(self, ep.name, os.path.join(self.egg_info,ep.name))
  File "C:\Python32\lib\site-packages\distribute-0.6.24-py3.2.egg\setuptools\command\egg_info.py", line 384, in write_pkg_info
    metadata.write_pkg_info(cmd.egg_info)
  File "C:\Python32\lib\distutils\dist.py", line 1015, in write_pkg_info
    self.write_pkg_file(pkg_info)
  File "C:\Python32\lib\distutils\dist.py", line 1031, in write_pkg_file
    file.write('Author: %s\n' % self.get_contact() )
UnicodeEncodeError: 'gbk' codec can't encode character '\xf1' in position 20: illegal multibyte sequence

D:\CI\bld\vcs\pygit2>
It's better to use utf8 instead.

----------
assignee: tarek
components: Distutils
messages: 153415
nosy: eric.araujo, tarek, ??.?
priority: normal
severity: normal
status: open
title: Write pkg_info with local encoding(GBK) will be a problem.
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14021>
_______________________________________

From report at bugs.python.org  Wed Feb 15 18:05:31 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Feb 2012 17:05:31 +0000
Subject: [issue14021] Write pkg_info with local encoding(GBK) will be a
	problem.
In-Reply-To: <1329325125.52.0.801195380714.issue14021@psf.upfronthosting.co.za>
Message-ID: <1329325531.88.0.933282690952.issue14021@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi.  This code was changed to use UTF-8 as you recommend.  The next version of Python 3.2 should have the fix.  You can get this version from hg.python.org (see instructions in the devguide) and see if your problem is gone.  Thanks for the report anyway!

----------
assignee: tarek -> eric.araujo
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> distutils: set encoding to utf-8 for input and output files
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14021>
_______________________________________

From report at bugs.python.org  Wed Feb 15 18:09:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Feb 2012 17:09:07 +0000
Subject: [issue13913] utf-8 or utf8 or utf-8 (codec display name inconsistency)
In-Reply-To: <1328030876.68.0.627537179228.issue13913@psf.upfronthosting.co.za>
Message-ID: <1329325747.28.0.636276631445.issue13913@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

You need to update test_pep3120: http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.2/builds/910/steps/test/logs/stdio/text

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13913>
_______________________________________

From report at bugs.python.org  Wed Feb 15 18:13:13 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Feb 2012 17:13:13 +0000
Subject: [issue1326113] Letting "build_ext --libraries" take more than one lib
Message-ID: <E1RxiPo-0002Mh-4k@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 77ac369fbbf1 by ?ric Araujo in branch '3.2':
Fix test failure for shared builds caused by #1326113 fix
http://hg.python.org/cpython/rev/77ac369fbbf1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1326113>
_______________________________________

From report at bugs.python.org  Wed Feb 15 18:14:57 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Feb 2012 17:14:57 +0000
Subject: [issue1326113] Letting "build_ext --libraries" take more than one lib
Message-ID: <E1RxiRT-0002WV-PM@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 98fb1c0fc7a0 by ?ric Araujo in branch 'default':
Fix for packaging test failure on shared builds (#1326113)
http://hg.python.org/cpython/rev/98fb1c0fc7a0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1326113>
_______________________________________

From report at bugs.python.org  Wed Feb 15 18:15:04 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Feb 2012 17:15:04 +0000
Subject: [issue1326113] Letting "build_ext --libraries" take more than one lib
Message-ID: <E1RxiRa-0002ZK-F8@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset db1c52aa4d2a by ?ric Araujo in branch '2.7':
Fix test failure for shared builds caused by #1326113 fix
http://hg.python.org/cpython/rev/db1c52aa4d2a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1326113>
_______________________________________

From report at bugs.python.org  Wed Feb 15 18:18:30 2012
From: report at bugs.python.org (Don Caldwell)
Date: Wed, 15 Feb 2012 17:18:30 +0000
Subject: [issue14022] bug in pkgutil.py with suggested fix
Message-ID: <1329326310.67.0.0755107537402.issue14022@psf.upfronthosting.co.za>


New submission from Don Caldwell <dfwcnj at gmail.com>:

in iter_modules there is a loop for fn in os.listdir(path): that can
fail on an OSError exception. here is a patch

                try:
                    for fn in os.listdir(path):
                        subname = inspect.getmodulename(fn)
                        if subname=='__init__':
                            ispkg = True
                            break
                    else:
                        continue    # not a package
                except OSError as (errno, strerror):
                    print "%s: %s\n" % (fn, strerror)

----------
components: Library (Lib)
messages: 153421
nosy: dfwc
priority: normal
severity: normal
status: open
title: bug in pkgutil.py with suggested fix
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14022>
_______________________________________

From report at bugs.python.org  Wed Feb 15 18:32:39 2012
From: report at bugs.python.org (=?utf-8?b?0KDQvtC80LDQvSDQlNC+0L3Rh9C10L3QutC+?=)
Date: Wed, 15 Feb 2012 17:32:39 +0000
Subject: [issue14023] bytes implied to be mutable
Message-ID: <1329327159.64.0.799949559846.issue14023@psf.upfronthosting.co.za>


New submission from ????? ???????? <DXDragon at yandex.ru>:

The language reference in section 5.2.2 states:

~
With the exception of bytes literals, these all correspond to immutable data types, <...>
~

But bytes objects are immutable as well.

----------
assignee: docs at python
components: Documentation
messages: 153422
nosy: SpecLad, docs at python
priority: normal
severity: normal
status: open
title: bytes implied to be mutable
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14023>
_______________________________________

From report at bugs.python.org  Wed Feb 15 18:38:12 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Wed, 15 Feb 2012 17:38:12 +0000
Subject: [issue14019] Unify tests for str.format and string.Formatter
In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za>
Message-ID: <1329327492.85.0.386500635328.issue14019@psf.upfronthosting.co.za>


Changes by Francisco Mart?n Brugu? <francismb at email.de>:


----------
nosy: +francismb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14019>
_______________________________________

From report at bugs.python.org  Wed Feb 15 18:57:03 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Feb 2012 17:57:03 +0000
Subject: [issue7644] bug in nntplib.body() method with possible fix
In-Reply-To: <1262773754.82.0.67564143033.issue7644@psf.upfronthosting.co.za>
Message-ID: <E1Rxj6E-00072h-B5@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f1401d20bc6d by Antoine Pitrou in branch '3.2':
Issue #7644: Add tests for the file argument of NNTP.head() and NNTP.body().
http://hg.python.org/cpython/rev/f1401d20bc6d

New changeset 096b31e0f8ea by Antoine Pitrou in branch 'default':
Issue #7644: Add tests for the file argument of NNTP.head() and NNTP.body().
http://hg.python.org/cpython/rev/096b31e0f8ea

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7644>
_______________________________________

From report at bugs.python.org  Wed Feb 15 18:57:38 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Feb 2012 17:57:38 +0000
Subject: [issue7644] bug in nntplib.body() method with possible fix
In-Reply-To: <1262773754.82.0.67564143033.issue7644@psf.upfronthosting.co.za>
Message-ID: <1329328658.74.0.547753756454.issue7644@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you! Closing now.

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7644>
_______________________________________

From report at bugs.python.org  Wed Feb 15 19:08:23 2012
From: report at bugs.python.org (James Lekas)
Date: Wed, 15 Feb 2012 18:08:23 +0000
Subject: [issue14024] logging.Formatter Cache Prevents Exception Format
	Overriding
Message-ID: <1329329303.3.0.810065424227.issue14024@psf.upfronthosting.co.za>


New submission from James Lekas <lekas at sonic.net>:

logging.Formatter.format() creates a cache called exc_text with a copy of the traceback text which it uses for all log handlers (I think).  When this cache is set, format() does not call formatException to format the exception/traceback data.

Unfortunately, this means that one cannot override logging.Formatter.formatException() for a specific log Handler.  For example, to create a stripped-down exception message for emailing to a non-technical audience, one might create the derived class NoStaceTraceFormatter, and attach an instance to the SMTPHandler using setFormatter():

class NoStackTraceFormatter(logging.Formatter):
    def formatException(self, exc_info):  # Don't emit the stack trace
        return '\n'.join(traceback.format_exception_only(exc_info[0], exc_info[1])) # type and value only

At least when other handlers exist for the logger, the new formatException call will probably never be invoked. (This might depend on the order in which the handlers are called when an exception log message arrives: the first handler would define the exception text.)

One partial workaround is to override the logging.Formatter.format() method to defeat the cache, causing the overriding formatException to be called.

    def format(self, record):
        record.exc_text = None # Defeat the common cache so formatException will be called.
        return logging.Formatter.format(self, record)

Unfortunately, this will create a new cached copy of the special-purpose exception text, possibly causing downstream handlers to emit the wrong message.

A possible solution would be to move the caching from logging.Formatter.format() to logging.Formatter.formatException, which would at least allow an individual handler to ignore the cache.  (However, all handlers would share the cache, possibly leading to trouble.)

The cache should probably be eliminated, as the premise on which it is based, "it's constant anyway", isn't strictly true.

----------
components: Library (Lib)
messages: 153425
nosy: jimlekas
priority: normal
severity: normal
status: open
title: logging.Formatter Cache Prevents Exception Format Overriding
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14024>
_______________________________________

From report at bugs.python.org  Wed Feb 15 19:33:27 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Wed, 15 Feb 2012 18:33:27 +0000
Subject: [issue13579] string.Formatter doesn't understand the !a conversion
	specifier
In-Reply-To: <1323587450.48.0.625379374057.issue13579@psf.upfronthosting.co.za>
Message-ID: <1329330807.39.0.669431020057.issue13579@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

I have updated the patch with the documentation changes proposed and also added a news entry (does a new entry has to be added in some order?).

Thank for the review in advance.

----------
Added file: http://bugs.python.org/file24526/issue13579_a99632426af5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13579>
_______________________________________

From report at bugs.python.org  Wed Feb 15 19:56:21 2012
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Feb 2012 18:56:21 +0000
Subject: [issue14022] bug in pkgutil.py with suggested fix
In-Reply-To: <1329326310.67.0.0755107537402.issue14022@psf.upfronthosting.co.za>
Message-ID: <1329332181.63.0.534753933658.issue14022@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This issue was recently fixed by the changes for Issue7367 and will be released in Python 2.7.3 and 3.2.3.  Python 2.6 no longer receives bug fixes, only security fixes.

----------
nosy: +ned.deily
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
superseder:  -> pkgutil.walk_packages fails on write-only directory in sys.path

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14022>
_______________________________________

From report at bugs.python.org  Wed Feb 15 20:26:01 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 15 Feb 2012 19:26:01 +0000
Subject: [issue14004] Distutils filelist selects too many files on Windows
In-Reply-To: <1329166628.27.0.616152401371.issue14004@psf.upfronthosting.co.za>
Message-ID: <1329333961.02.0.332882311841.issue14004@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> At first glance, Nadeem?s proposed fix is not right: paths in MANIFEST.in use '/', but then filelist produces paths using os.sep, so that the MANIFEST file and other operations done by the sdist command use native paths.  So even though the currently supported OSes all accept '/', I think the right thing is to use os.sep.

Yes, that sounds like a better solution. So the solution then is to fix
the regexps to use os.sep instead of "/" (and ensure that FileList uses
native paths throughout).

As an aside, it seems that the failing test from issue 13193 was
actually correct, and that the library itself was broken. I suppose all
of the tests will need to be changed to use native paths when this issue
is fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14004>
_______________________________________

From report at bugs.python.org  Wed Feb 15 20:55:25 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 15 Feb 2012 19:55:25 +0000
Subject: [issue13579] string.Formatter doesn't understand the !a conversion
	specifier
In-Reply-To: <1323587450.48.0.625379374057.issue13579@psf.upfronthosting.co.za>
Message-ID: <1329335725.83.0.0871591469992.issue13579@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I just noticed two more minor errors that were and remain in "It takes a format string, and an arbitrary set of positional and keyword argument." Remove the comma and make 'argument' plural.

As near as I can tell, the two change block beginning with 
+In less formal terms,
+keyword.  If it's a number,
are strictly re-wrapping and no text changes. Correct?

Francisco - News entries are usually entered at the top of the section, just under the heading. But they are a bit tricky for multi-version patches because the context following is often different for different version. I have not decided which is easier -- resolving a merge conflict with a 3-way merge tool or separately editing Misc/NEWS for each version.

Eric, I near as I can tell, and given Nick's last response, this will be ready to commit with the two minor text changes and movement of the NEWS entry. Francisco is already in Misc/ACKS.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13579>
_______________________________________

From report at bugs.python.org  Wed Feb 15 21:03:00 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 15 Feb 2012 20:03:00 +0000
Subject: [issue13579] string.Formatter doesn't understand the !a conversion
	specifier
In-Reply-To: <1323587450.48.0.625379374057.issue13579@psf.upfronthosting.co.za>
Message-ID: <1329336180.61.0.244117731521.issue13579@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

However, I have not actually applied and run test_string.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13579>
_______________________________________

From report at bugs.python.org  Wed Feb 15 21:16:14 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 15 Feb 2012 20:16:14 +0000
Subject: [issue14001] CVE-2012-0845 Python v2.7.2 / v3.2.2
	(SimpleXMLRPCServer): DoS (excessive CPU usage) by processing
	malformed XMLRPC / HTTP POST request
In-Reply-To: <1329294568.14.0.0530957933586.issue14001@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2kZB6F7bgRNKVi23FuphpZvuK7sdPtfVa=B+EZCqguhA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The test fails on 2.6 and 2.7, because of a EPIPE, which is normal in
this case (well, at least expected):
"""
test_partial_post (test.test_xmlrpc.SimpleServerTestCase) ...
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 47844)
Traceback (most recent call last):
  File "/home/cf/python/cpython/Lib/SocketServer.py", line 283, in
_handle_request_noblock
    self.process_request(request, client_address)
  File "/home/cf/python/cpython/Lib/SocketServer.py", line 309, in
process_request
    self.finish_request(request, client_address)
  File "/home/cf/python/cpython/Lib/SocketServer.py", line 322, in
finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/home/cf/python/cpython/Lib/SocketServer.py", line 617, in __init__
    self.handle()
  File "/home/cf/python/cpython/Lib/BaseHTTPServer.py", line 329, in handle
    self.handle_one_request()
  File "/home/cf/python/cpython/Lib/BaseHTTPServer.py", line 323, in
handle_one_request
    method()
  File "/home/cf/python/cpython/Lib/SimpleXMLRPCServer.py", line 490, in do_POST
    self.send_response(200)
  File "/home/cf/python/cpython/Lib/BaseHTTPServer.py", line 384, in
send_response
    self.send_header('Server', self.version_string())
  File "/home/cf/python/cpython/Lib/BaseHTTPServer.py", line 390, in send_header
    self.wfile.write("%s: %s\r\n" % (keyword, value))
  File "/home/cf/python/cpython/Lib/socket.py", line 318, in write
    self.flush()
  File "/home/cf/python/cpython/Lib/socket.py", line 297, in flush
    self._sock.sendall(buffer(data, write_offset, buffer_size))
error: [Errno 32] Broken pipe
"""

What should I do? Remove the test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14001>
_______________________________________

From report at bugs.python.org  Wed Feb 15 21:26:13 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Feb 2012 20:26:13 +0000
Subject: [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>
Message-ID: <E1RxlQZ-0007K5-8C@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9eb77d455be1 by Petri Lehtinen in branch '3.2':
Issue #13491: Fix many errors in sqlite3 documentation
http://hg.python.org/cpython/rev/9eb77d455be1

New changeset ba5b337ecc27 by Petri Lehtinen in branch 'default':
Merge branch '3.2'
http://hg.python.org/cpython/rev/ba5b337ecc27

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13491>
_______________________________________

From report at bugs.python.org  Wed Feb 15 21:28:10 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 15 Feb 2012 20:28:10 +0000
Subject: [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>
Message-ID: <1329337690.98.0.059462272282.issue13491@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

?ric: You can make a patch for 2.7 if you want to, I left the issue open.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13491>
_______________________________________

From report at bugs.python.org  Wed Feb 15 21:46:31 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 15 Feb 2012 20:46:31 +0000
Subject: [issue14019] Unify tests for str.format and string.Formatter
In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za>
Message-ID: <1329338791.29.0.137044526939.issue14019@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/issue14019>
_______________________________________

From report at bugs.python.org  Wed Feb 15 22:00:00 2012
From: report at bugs.python.org (Jaap Karssenberg)
Date: Wed, 15 Feb 2012 21:00:00 +0000
Subject: [issue14025] unittest.TestCase.assertEqual does not show diff when
	comparing str with unicode
Message-ID: <1329339600.71.0.863718430096.issue14025@psf.upfronthosting.co.za>


New submission from Jaap Karssenberg <jaap.karssenberg at gmail.com>:

When you compare two multiline strings with unittest.TestCase.assertEqual it is supposed to dispatch to assertMultiLineEqual and show a diff when the strings differ.

However this only works for two string of the same type (str or unicode). But mixing the two will just give the default message that they differ without the diff. THis is due to the way the dispatch checks types. Probably need to make an exception for comparing str with unicode.

Note that if the contents of both strings are the same, the assert will regard them equal, so it is not a strict check on the type perse.

----------
components: Library (Lib)
messages: 153434
nosy: jaap.karssenberg
priority: normal
severity: normal
status: open
title: unittest.TestCase.assertEqual does not show diff when comparing str with unicode
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14025>
_______________________________________

From report at bugs.python.org  Wed Feb 15 22:04:01 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Feb 2012 21:04:01 +0000
Subject: [issue14025] unittest.TestCase.assertEqual does not show diff when
	comparing str with unicode
In-Reply-To: <1329339600.71.0.863718430096.issue14025@psf.upfronthosting.co.za>
Message-ID: <1329339841.99.0.774847653829.issue14025@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The latter is arguably a bug.  The former is working as designed, as far as I know.  In Python3 bytes and string do not compare equal.

----------
nosy: +michael.foord, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14025>
_______________________________________

From report at bugs.python.org  Wed Feb 15 22:06:41 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Feb 2012 21:06:41 +0000
Subject: [issue14025] unittest.TestCase.assertEqual does not show diff when
	comparing str with unicode
In-Reply-To: <1329339600.71.0.863718430096.issue14025@psf.upfronthosting.co.za>
Message-ID: <1329340001.89.0.927345115197.issue14025@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/issue14025>
_______________________________________

From report at bugs.python.org  Wed Feb 15 22:13:14 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Feb 2012 21:13:14 +0000
Subject: [issue13849] Add tests for NUL checking in certain strs
In-Reply-To: <1327370754.29.0.66468771639.issue13849@psf.upfronthosting.co.za>
Message-ID: <1329340394.0.0.0872705558932.issue13849@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

See also issue #13617.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13849>
_______________________________________

From report at bugs.python.org  Wed Feb 15 22:25:03 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Feb 2012 21:25:03 +0000
Subject: [issue13913] utf-8 or utf8 or utf-8 (codec display name inconsistency)
In-Reply-To: <1328030876.68.0.627537179228.issue13913@psf.upfronthosting.co.za>
Message-ID: <E1RxmLV-0004se-LO@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5b8f146103fa by Victor Stinner in branch '3.2':
Issue #13913: Fix test_pep3120 for the UTF-8 codec name
http://hg.python.org/cpython/rev/5b8f146103fa

New changeset 170a224ce01e by Victor Stinner in branch 'default':
(Merge 3.2) Issue #13913: Fix test_pep3120 for the UTF-8 codec name
http://hg.python.org/cpython/rev/170a224ce01e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13913>
_______________________________________

From report at bugs.python.org  Wed Feb 15 22:34:40 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Feb 2012 21:34:40 +0000
Subject: [issue13014] _ssl.c: refleak
In-Reply-To: <1316530275.76.0.31607583855.issue13014@psf.upfronthosting.co.za>
Message-ID: <E1RxmUp-0005vb-76@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f3a4c2b34973 by Antoine Pitrou in branch '3.2':
Issue #13014: Fix a possible reference leak in SSLSocket.getpeercert().
http://hg.python.org/cpython/rev/f3a4c2b34973

New changeset 9ab501b3e22d by Antoine Pitrou in branch 'default':
Issue #13014: Fix a possible reference leak in SSLSocket.getpeercert().
http://hg.python.org/cpython/rev/9ab501b3e22d

New changeset 111dcae41ff7 by Antoine Pitrou in branch '2.7':
Issue #13014: Fix a possible reference leak in SSLSocket.getpeercert().
http://hg.python.org/cpython/rev/111dcae41ff7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13014>
_______________________________________

From report at bugs.python.org  Wed Feb 15 22:35:18 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Feb 2012 21:35:18 +0000
Subject: [issue13014] _ssl.c: refleak
In-Reply-To: <1316530275.76.0.31607583855.issue13014@psf.upfronthosting.co.za>
Message-ID: <1329341718.97.0.585960891706.issue13014@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've fixed the actual leak. Thanks!

----------
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13014>
_______________________________________

From report at bugs.python.org  Wed Feb 15 22:39:52 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Feb 2012 21:39:52 +0000
Subject: [issue14025] unittest.TestCase.assertEqual does not show diff when
	comparing str with unicode
In-Reply-To: <1329339600.71.0.863718430096.issue14025@psf.upfronthosting.co.za>
Message-ID: <1329341992.48.0.501829738739.issue14025@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In case it isn't clear, by "arguably a bug" I mean in a theoretical sense.  Even if Michael agrees with me we can't change the fact that 2.7 unittest treats str and unicode with the same content as equal.

For the other it might have been a backport-from-3.x oversight, or it might have been intentional.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14025>
_______________________________________

From report at bugs.python.org  Wed Feb 15 22:44:07 2012
From: report at bugs.python.org (Doug Hellmann)
Date: Wed, 15 Feb 2012 21:44:07 +0000
Subject: [issue13817] deadlock in subprocess while running several threads
	using Popen
In-Reply-To: <1326909636.44.0.892345276723.issue13817@psf.upfronthosting.co.za>
Message-ID: <1329342247.26.0.333731917101.issue13817@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/issue13817>
_______________________________________

From report at bugs.python.org  Wed Feb 15 22:56:42 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 15 Feb 2012 21:56:42 +0000
Subject: [issue13090] test_multiprocessing: memory leaks
In-Reply-To: <1317546629.79.0.861373881282.issue13090@psf.upfronthosting.co.za>
Message-ID: <1329343002.8.0.157940011254.issue13090@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Yes, the leak does not seem to be in posix_read() itself. Sadly
enough, the number of leaks in test_multiprocessing has grown to
five in e9d01c5c92ed (the four additional ones were definitely not
present when I reported this).


==3047== 32 bytes in 1 blocks are definitely lost in loss record 340 of 6,704
==3047==    at 0x4C27878: malloc (vg_replace_malloc.c:236)
==3047==    by 0x4D5C35: PyThread_allocate_lock (thread_pthread.h:280)
==3047==    by 0x4A817C: _PyImport_AcquireLock (import.c:292)
==3047==    by 0x4ADE7A: PyImport_ImportModuleLevelObject (import.c:2903)
==3047==    by 0x4ADF64: PyImport_ImportModuleLevel (import.c:2922)
==3047==    by 0x4AF8BB: PyImport_Import (import.c:3510)
==3047==    by 0x4AD8AF: PyImport_ImportModule (import.c:2728)
==3047==    by 0x5567E9: _PyExc_Init (exceptions.c:2345)
==3047==    by 0x4BBA8F: Py_InitializeEx (pythonrun.c:277)
==3047==    by 0x4BBCA8: Py_Initialize (pythonrun.c:341)
==3047==    by 0x4D875C: Py_Main (main.c:595)
==3047==    by 0x41ABFF: main (python.c:63)
==3047== 


==3047== 37 bytes in 1 blocks are definitely lost in loss record 390 of 6,704
==3047==    at 0x4C27878: malloc (vg_replace_malloc.c:236)
==3047==    by 0x53F997: PyBytes_FromStringAndSize (bytesobject.c:98)
==3047==    by 0x4E5AB8: posix_read (posixmodule.c:7010)
==3047==    by 0x57B4AD: PyCFunction_Call (methodobject.c:81)
==3047==    by 0x490397: call_function (ceval.c:4051)
==3047==    by 0x48B826: PyEval_EvalFrameEx (ceval.c:2674)
==3047==    by 0x48E509: PyEval_EvalCodeEx (ceval.c:3426)
==3047==    by 0x4908D7: fast_function (ceval.c:4149)
==3047==    by 0x4904EA: call_function (ceval.c:4072)
==3047==    by 0x48B826: PyEval_EvalFrameEx (ceval.c:2674)
==3047==    by 0x48E509: PyEval_EvalCodeEx (ceval.c:3426)
==3047==    by 0x4908D7: fast_function (ceval.c:4149)
==3047== 


==3047== 72 bytes in 1 blocks are definitely lost in loss record 2,859 of 6,704
==3047==    at 0x4C27878: malloc (vg_replace_malloc.c:236)
==3047==    by 0x4DA93E: _PyObject_GC_Malloc (gcmodule.c:1455)
==3047==    by 0x4DAA5A: _PyObject_GC_NewVar (gcmodule.c:1487)
==3047==    by 0x427A77: PyTuple_New (tupleobject.c:91)
==3047==    by 0x427F3A: PyTuple_Pack (tupleobject.c:195)
==3047==    by 0x494607: compiler_add_o (compile.c:1024)
==3047==    by 0x4947EA: compiler_addop_o (compile.c:1056)
==3047==    by 0x49B1BB: compiler_visit_expr (compile.c:3341)
==3047==    by 0x49AEBB: compiler_visit_expr (compile.c:3293)
==3047==    by 0x498B3A: compiler_visit_stmt (compile.c:2411)
==3047==    by 0x494B32: compiler_body (compile.c:1247)
==3047==    by 0x494C33: compiler_mod (compile.c:1267)


==3047== 120 bytes in 3 blocks are definitely lost in loss record 3,649 of 6,704
==3047==    at 0x4C27878: malloc (vg_replace_malloc.c:236)
==3047==    by 0x4DC686: thread_PyThread_start_new_thread (_threadmodule.c:1052)
==3047==    by 0x57B4AD: PyCFunction_Call (methodobject.c:81)
==3047==    by 0x490397: call_function (ceval.c:4051)
==3047==    by 0x48B826: PyEval_EvalFrameEx (ceval.c:2674)
==3047==    by 0x4907CB: fast_function (ceval.c:4139)
==3047==    by 0x4904EA: call_function (ceval.c:4072)
==3047==    by 0x48B826: PyEval_EvalFrameEx (ceval.c:2674)
==3047==    by 0x48E509: PyEval_EvalCodeEx (ceval.c:3426)
==3047==    by 0x56263C: function_call (funcobject.c:669)
==3047==    by 0x532B87: PyObject_Call (abstract.c:2150)
==3047==    by 0x549EF6: method_call (classobject.c:320)


==3047== 120 bytes in 3 blocks are definitely lost in loss record 3,650 of 6,704
==3047==    at 0x4C27878: malloc (vg_replace_malloc.c:236)
==3047==    by 0x4DC686: thread_PyThread_start_new_thread (_threadmodule.c:1052)
==3047==    by 0x57B4AD: PyCFunction_Call (methodobject.c:81)
==3047==    by 0x490397: call_function (ceval.c:4051)
==3047==    by 0x48B826: PyEval_EvalFrameEx (ceval.c:2674)
==3047==    by 0x4907CB: fast_function (ceval.c:4139)
==3047==    by 0x4904EA: call_function (ceval.c:4072)
==3047==    by 0x48B826: PyEval_EvalFrameEx (ceval.c:2674)
==3047==    by 0x48E509: PyEval_EvalCodeEx (ceval.c:3426)
==3047==    by 0x4908D7: fast_function (ceval.c:4149)
==3047==    by 0x4904EA: call_function (ceval.c:4072)
==3047==    by 0x48B826: PyEval_EvalFrameEx (ceval.c:2674)

----------
title: posix_read: memory leak -> test_multiprocessing: memory leaks

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13090>
_______________________________________

From report at bugs.python.org  Wed Feb 15 22:59:52 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 15 Feb 2012 21:59:52 +0000
Subject: [issue13090] test_multiprocessing: memory leaks
In-Reply-To: <1329343002.8.0.157940011254.issue13090@psf.upfronthosting.co.za>
Message-ID: <20120215215951.GA6078@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Stefan Krah <report at bugs.python.org> wrote:
> enough, the number of leaks in test_multiprocessing has grown to
> five in e9d01c5c92ed (the four additional ones were definitely not

To be sure, e9d01c5c92ed is completely innocent. I just tested
with that revision. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13090>
_______________________________________

From report at bugs.python.org  Wed Feb 15 23:04:57 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Feb 2012 22:04:57 +0000
Subject: [issue13090] test_multiprocessing: memory leaks
In-Reply-To: <1317546629.79.0.861373881282.issue13090@psf.upfronthosting.co.za>
Message-ID: <1329343497.1.0.562177752755.issue13090@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The first one seems to be the import lock. Two others seem to be the internal "bootstate" structure used to run thread objects (daemon threads?).

Perhaps you could try to find whether a single test is responsible.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13090>
_______________________________________

From report at bugs.python.org  Wed Feb 15 23:32:03 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Feb 2012 22:32:03 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <E1RxnOL-0003B3-Hg@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3b127a415643 by Sandro Tosi in branch '2.7':
Issue #11836: document multiprocessing.queues.SimpleQueue
http://hg.python.org/cpython/rev/3b127a415643

New changeset fe5eb6d35025 by Sandro Tosi in branch '3.2':
Issue #11836: document multiprocessing.queues.SimpleQueue
http://hg.python.org/cpython/rev/fe5eb6d35025

New changeset bf536b46d7f2 by Sandro Tosi in branch 'default':
Issue #11836: document and expose multiprocessing.SimpleQueue
http://hg.python.org/cpython/rev/bf536b46d7f2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11836>
_______________________________________

From report at bugs.python.org  Wed Feb 15 23:33:46 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 15 Feb 2012 22:33:46 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <1329345226.93.0.57866452968.issue11836@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Thanks for all you inputs!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11836>
_______________________________________

From report at bugs.python.org  Wed Feb 15 23:44:41 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Feb 2012 22:44:41 +0000
Subject: [issue13913] utf-8 or utf8 or utf-8 (codec display name inconsistency)
In-Reply-To: <1328030876.68.0.627537179228.issue13913@psf.upfronthosting.co.za>
Message-ID: <E1RxnaZ-0004Py-Q8@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 824ddf6a30f2 by Victor Stinner in branch '3.2':
Issue #13913: Another fix test_pep3120 for the UTF-8 codec name
http://hg.python.org/cpython/rev/824ddf6a30f2

New changeset 2cfba214c243 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #13913: Another fix test_pep3120 for the UTF-8 codec name
http://hg.python.org/cpython/rev/2cfba214c243

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13913>
_______________________________________

From report at bugs.python.org  Thu Feb 16 00:14:23 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Feb 2012 23:14:23 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1329347663.77.0.700121499847.issue7652@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I tried my timestamp patch with _decimal: it fails because decimal and _decimal API is not exactly the same.

decimal.Decimal.__truediv__() has an optional context argument, whereas _decimal defines PyNumberMethods.

decimal.Decimal.quantize() second argument is optional and its default value is None, but if I pass None to _decimal.Decimal.quantize(), I get a TypeError because _decimal expects an integer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Thu Feb 16 00:26:11 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 15 Feb 2012 23:26:11 +0000
Subject: [issue14026] test_cmd_line_script should include more sys.argv checks
Message-ID: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Currently, test_cmd_line_script only checks sys.argv[0] is set correctly.

It should pass some extra values after the script name, then include an appropriate check in the output of the launched script.

----------
components: Tests
keywords: easy
messages: 153448
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: test_cmd_line_script should include more sys.argv checks
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14026>
_______________________________________

From report at bugs.python.org  Thu Feb 16 00:29:04 2012
From: report at bugs.python.org (Michael Foord)
Date: Wed, 15 Feb 2012 23:29:04 +0000
Subject: [issue14025] unittest.TestCase.assertEqual does not show diff when
	comparing str with unicode
In-Reply-To: <1329339600.71.0.863718430096.issue14025@psf.upfronthosting.co.za>
Message-ID: <1329348544.52.0.316662412612.issue14025@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

assertEqual uses Python equality semantics - so if a str instance and a unicode instance compare equal then assertEqual passes. This is by design.

The type check in assertEqual, that delegates to the different comparison methods, is strict because we can't know that using the error message algorithms is sane for arbitrary subclasses - all we can know is whether an equality comparison fails or succeeds.

Using a diff algorithm for creating an error message only makes sense for text, which is why it is only done for unicode. For binary strings a diff is more likely to be unintelligible nonsense.  

For comparing unicode to strings you can call asssertMultilineEqual directly.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14025>
_______________________________________

From report at bugs.python.org  Thu Feb 16 00:41:48 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 15 Feb 2012 23:41:48 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1329349308.61.0.970204461155.issue7897@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I just remembered that many of the urllib.urlparse tests are guilty of only reporting the first case that fails, instead of testing everything and reporting all failures:

http://hg.python.org/cpython/file/default/Lib/test/test_urlparse.py

IMO, it would make a good guinea pig for any upgrade to the stdlib support for parameterised unit tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Thu Feb 16 02:24:39 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 16 Feb 2012 01:24:39 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1329355479.14.0.972756626917.issue8604@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm opposed to adding "atomic" files to the standard library. This has nothing to do with the original issue; anybody contributing to the issue is making up user needs that have not been sufficiently demonstrated.

It would be best to release such code on PyPI first, and wait a few years to see whether there really is an end-user demand for the feature.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Thu Feb 16 02:40:56 2012
From: report at bugs.python.org (Michael Foord)
Date: Thu, 16 Feb 2012 01:40:56 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1329356456.03.0.79863524401.issue7897@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

FWIW I think nose2 is going to have "test load time" parameterized tests rather than "run time" parameterized tests, which is what I think we should do for unit test. The API should be as simple as possible for basic cases, but suitable for more complex cases too.

I quite liked Nicks idea of allowing a custom "case builder" but providing a sane default one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Thu Feb 16 03:33:54 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Feb 2012 02:33:54 +0000
Subject: [issue14026] test_cmd_line_script should include more sys.argv checks
In-Reply-To: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za>
Message-ID: <1329359634.47.0.867688444579.issue14026@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
stage:  -> test needed
type:  -> enhancement
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14026>
_______________________________________

From report at bugs.python.org  Thu Feb 16 04:29:07 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 16 Feb 2012 03:29:07 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329362947.08.0.411402560134.issue13988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Emitting a deprecation warning on importing cElementTree has been rejected in the pydev list. The other remaining tasks have new issues on them, so this issue is done now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Thu Feb 16 04:48:45 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 16 Feb 2012 03:48:45 +0000
Subject: [issue14009] Clearer documentation for cElementTree
In-Reply-To: <1329233203.38.0.944311933185.issue14009@psf.upfronthosting.co.za>
Message-ID: <1329364125.78.0.0202965508128.issue14009@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

?ric, indeed it clarifies the usage, but my concern is that it also moves the first mention of the module further down.

There's no real reason for someone using CPython 2.7 or 3.2 *not* to use cET. So, some mention should appear in the opening paragraph. I'm attaching a patch that shows one possibility (based on your patch). It was generated vs. branch 2.7

----------
Added file: http://bugs.python.org/file24527/issue14009.doc_cET.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14009>
_______________________________________

From report at bugs.python.org  Thu Feb 16 04:50:45 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 16 Feb 2012 03:50:45 +0000
Subject: [issue14009] Clearer documentation for cElementTree
In-Reply-To: <1329233203.38.0.944311933185.issue14009@psf.upfronthosting.co.za>
Message-ID: <1329364245.69.0.475170897754.issue14009@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Also, I must add that I absolutely hate the opening paragraph of the documentation in this module. Once 14006 is implemented, parts of it should be backported to 2.7 and 3.2

That would be an orthogonal change to what we're discussion here, though

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14009>
_______________________________________

From report at bugs.python.org  Thu Feb 16 04:54:03 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 16 Feb 2012 03:54:03 +0000
Subject: [issue14023] bytes implied to be mutable
In-Reply-To: <1329327159.64.0.799949559846.issue14023@psf.upfronthosting.co.za>
Message-ID: <1329364443.56.0.720078550171.issue14023@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/issue14023>
_______________________________________

From report at bugs.python.org  Thu Feb 16 04:55:37 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Feb 2012 03:55:37 +0000
Subject: [issue14009] Clearer documentation for cElementTree
In-Reply-To: <1329233203.38.0.944311933185.issue14009@psf.upfronthosting.co.za>
Message-ID: <1329364537.38.0.818056601433.issue14009@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1.  Barring other feedback, I will commit your patch.

> Also, I must add that I absolutely hate the opening paragraph of the
> documentation in this module.

This:

  The :class:`Element` type is a flexible container object, designed to store
  hierarchical data structures in memory.  The type can be described as a cross
  between a list and a dictionary.

?  Yeah, it?s not quite good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14009>
_______________________________________

From report at bugs.python.org  Thu Feb 16 04:59:53 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 16 Feb 2012 03:59:53 +0000
Subject: [issue14009] Clearer documentation for cElementTree
In-Reply-To: <1329233203.38.0.944311933185.issue14009@psf.upfronthosting.co.za>
Message-ID: <1329364793.52.0.461004966296.issue14009@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

If you want to collect additional feedback, you may want to add some other people to the Nosy list :-) Alternatively, since it's a small doc change you can just commit it and it can be fixed later if someone strongly objects.

>>>
This:

  The :class:`Element` type is a flexible container object, designed to store
  hierarchical data structures in memory.  The type can be described as a cross
  between a list and a dictionary.

?  Yeah, it?s not quite good.
>>>

Yes. You read the first section of a module's doc and you have *no idea* what the module is and how to use it. I plant to work on this for 3.3 in the context of issue 14006.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14009>
_______________________________________

From report at bugs.python.org  Thu Feb 16 05:18:59 2012
From: report at bugs.python.org (Meador Inge)
Date: Thu, 16 Feb 2012 04:18:59 +0000
Subject: [issue13089] parsetok.c: memory leak
In-Reply-To: <1317545416.55.0.717898890924.issue13089@psf.upfronthosting.co.za>
Message-ID: <1329365939.45.0.640860413861.issue13089@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Stefan, how did you reproduce this?  I tried:

1. Uncommenting '#define Py_USING_MEMORY_DEBUGGER' in 
   'Objects/obmalloc.c'.
2. Configuring with './configure --without-pymalloc'.
3. Running 'valgrind --tool=memcheck --log-file=leaks.txt
   --leak-check=full --suppressions=Misc/valgrind-python.supp
   ./python -m test test_mailbox'.

When performing the above I only see leaks in import:

==2683== 256 bytes in 1 blocks are definitely lost in loss record 3,234 of 4,881
==2683==    at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==2683==    by 0xD0753A1: PyInit_atexit (atexitmodule.c:294)
==2683==    by 0x49AE0B: _PyImport_LoadDynamicModule (importdl.c:85)
==2683==    by 0x498740: import_submodule (import.c:3338)
==2683==    by 0x4989CA: load_next (import.c:3149)
==2683==    by 0x499005: import_module_level.isra.10 (import.c:2842)
==2683==    by 0x499759: PyImport_ImportModuleLevelObject (import.c:2904)
==2683==    by 0x4729EA: builtin___import__ (bltinmodule.c:195)
==2683==    by 0x5064E9: PyObject_Call (abstract.c:2150)
==2683==    by 0x473E3E: PyEval_CallObjectWithKeywords.constprop.8 (ceval.c:3931)
==2683==    by 0x477D83: PyEval_EvalFrameEx (ceval.c:2332)
==2683==    by 0x4752FB: PyEval_EvalCodeEx (ceval.c:3426)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13089>
_______________________________________

From report at bugs.python.org  Thu Feb 16 05:36:10 2012
From: report at bugs.python.org (Meador Inge)
Date: Thu, 16 Feb 2012 04:36:10 +0000
Subject: [issue10112] Use -Wl, --dynamic-list=x.list,
	not -Xlinker -export-dynamic
In-Reply-To: <1287137785.61.0.962664170792.issue10112@psf.upfronthosting.co.za>
Message-ID: <1329366970.02.0.478139180419.issue10112@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

When I try to build with the attached patch on the 2.7 branch many (if not all) of the modules fail to build:

Failed to build these modules:
_bisect            _bsddb             _codecs_cn      
_codecs_hk         _codecs_iso2022    _codecs_jp      
_codecs_kr         _codecs_tw         _collections    
_csv               _ctypes            _ctypes_test    
_curses            _curses_panel      _elementtree    
_functools         _hashlib           _heapq          
_hotshot           _io                _json           
_locale            _lsprof            _multibytecodec 
_multiprocessing   _random            _socket         
_sqlite3           _ssl               _struct         
_testcapi          _tkinter           array           
audioop            binascii           bz2             
cmath              cPickle            crypt           
cStringIO          datetime           dbm             
fcntl              future_builtins    gdbm            
grp                itertools          linuxaudiodev   
math               mmap               nis             
operator           ossaudiodev        parser          
pyexpat            readline           resource        
select             spwd               strop           
syslog             termios            time            
unicodedata        zlib                               

I see several warnings in the build output:

*** WARNING: renaming "_codecs_iso2022" since importing it failed: build/lib.lin
ux-x86_64-2.7/_codecs_iso2022.so: undefined symbol: PyExc_ValueError
..
*** WARNING: renaming "linuxaudiodev" since importing it failed: build/lib.linux
-x86_64-2.7/linuxaudiodev.so: undefined symbol: Py_Py3kWarningFlag
...
*** WARNING: renaming "_tkinter" since importing it failed: build/lib.linux-x86_64-2.7/_tkinter.so: undefined symbol: _Py_ZeroStruct

----------
components: +Build -Library (Lib)
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10112>
_______________________________________

From report at bugs.python.org  Thu Feb 16 06:01:41 2012
From: report at bugs.python.org (Meador Inge)
Date: Thu, 16 Feb 2012 05:01:41 +0000
Subject: [issue13959] Re-implement parts of imp in pure Python
In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za>
Message-ID: <1329368501.17.0.958016250516.issue13959@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13959>
_______________________________________

From report at bugs.python.org  Thu Feb 16 06:05:48 2012
From: report at bugs.python.org (Meador Inge)
Date: Thu, 16 Feb 2012 05:05:48 +0000
Subject: [issue13977] importlib simplification
In-Reply-To: <1328810035.88.0.967764974247.issue13977@psf.upfronthosting.co.za>
Message-ID: <1329368748.03.0.966691563705.issue13977@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13977>
_______________________________________

From report at bugs.python.org  Thu Feb 16 06:07:14 2012
From: report at bugs.python.org (Meador Inge)
Date: Thu, 16 Feb 2012 05:07:14 +0000
Subject: [issue13970] frameobject should not have f_yieldfrom attribute
In-Reply-To: <1328722917.98.0.121121534686.issue13970@psf.upfronthosting.co.za>
Message-ID: <1329368834.23.0.0147817197187.issue13970@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13970>
_______________________________________

From report at bugs.python.org  Thu Feb 16 06:10:02 2012
From: report at bugs.python.org (Meador Inge)
Date: Thu, 16 Feb 2012 05:10:02 +0000
Subject: [issue13938] 2to3 fails to convert types.StringTypes appropriately
In-Reply-To: <1328333493.54.0.112859472866.issue13938@psf.upfronthosting.co.za>
Message-ID: <1329369002.09.0.228854909797.issue13938@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13938>
_______________________________________

From report at bugs.python.org  Thu Feb 16 07:32:19 2012
From: report at bugs.python.org (=?utf-8?b?5YuH5YiaIOe9lw==?=)
Date: Thu, 16 Feb 2012 06:32:19 +0000
Subject: [issue14027] distutils2 lack of pysetup.bat
Message-ID: <1329373939.69.0.162264279004.issue14027@psf.upfronthosting.co.za>


New submission from ?? ? <luoyonggang at gmail.com>:

Patch attaced.

----------
assignee: tarek
components: Distutils2
files: pysetup.bat
messages: 153460
nosy: alexis, eric.araujo, tarek, ??.?
priority: normal
severity: normal
status: open
title: distutils2 lack of pysetup.bat
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24528/pysetup.bat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14027>
_______________________________________

From report at bugs.python.org  Thu Feb 16 07:58:01 2012
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 16 Feb 2012 06:58:01 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1329375481.16.0.862242737919.issue6210@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

> Remaining problems:
> - default sys.excepthook implementation currently does the wrong thing

Unable to duplicate on my system (Win XP SP3)

> - needs a test for the pythonrun display logic (test_cmd_line_script
>   would be the appropriate place)

Not sure I understand this point, but I added a test in test_raise that starts a subprocess interpreter and checks its output.

> - testCauseSyntax test should probably be in test_raise, not
>   test_exceptions

Moved.

----------
Added file: http://bugs.python.org/file24529/pep409.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Thu Feb 16 08:05:45 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 16 Feb 2012 07:05:45 +0000
Subject: [issue13972] set and frozenset constructors don't accept multiple
	iterables
In-Reply-To: <1328775388.29.0.217148871947.issue13972@psf.upfronthosting.co.za>
Message-ID: <1329375945.13.0.880782990576.issue13972@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Ok, closing because of lack of support for the idea.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13972>
_______________________________________

From report at bugs.python.org  Thu Feb 16 08:27:45 2012
From: report at bugs.python.org (Warren Turkal)
Date: Thu, 16 Feb 2012 07:27:45 +0000
Subject: [issue13922] argparse handling multiple "--" in args improperly
In-Reply-To: <1328132556.72.0.92385645061.issue13922@psf.upfronthosting.co.za>
Message-ID: <1329377265.35.0.706242205223.issue13922@psf.upfronthosting.co.za>


Warren Turkal <wt at penguintechs.org> added the comment:

Using argparse.REMAINDER will not help for my problem in my real program as the first arg needs to be handled by my program and mapped into the real binary name.

If I recall correctly from memory, the following is what happened when I tried using argparse.REMAINDER. If call my program like so:
$ hack run :target --help

The subcommand will be "run" in this case. Because :target is handled by argparse, the "--help" will not be seen as part of the remainder of the arguments, and I will get the help for the "hack run" subcommand instead of the target binary getting the --help argument. I have pushed most of the program to [1] if you want to take a look. Specifically, see cli/commands/run.py:do_run for that bit of code that handles the run subcommand.

[1]https://github.com/wt/repo-digg-dev-hackbuilder

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13922>
_______________________________________

From report at bugs.python.org  Thu Feb 16 08:57:53 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 16 Feb 2012 07:57:53 +0000
Subject: [issue14028] random.choice hits ValueError: cannot convert float NaN
	to integer
Message-ID: <1329379073.39.0.519578524869.issue14028@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

Using a 32-bit Python 2.6.5 on a Linux system at work we observed the following:

  File "/.../lib/python2.6/tempfile.py", line 349, in mktemp
    name = names.next()
  File "/.../lib/python2.6/tempfile.py", line 134, in next
    letters = [choose(c) for dummy in "123456"]
  File "/.../lib/python2.6/random.py", line 261, in choice
    return seq[int(self.random() * len(seq))]  # raises IndexError if seq is empty
ValueError: cannot convert float NaN to integer

This is rare and hard to reproduce.  The hardware appears to be healthy and this was on a server with ECC.


Some searching reveals that other people have hit this in random.choice in Python 2.7 as well:  https://bugs.launchpad.net/ubuntu/+source/desktopcouch/+bug/886159

The ubuntu developer seems to think this is related to time.time() returning NaN at some point (I haven't looked into that myself).

----------
messages: 153464
nosy: gregory.p.smith, tim_one
priority: normal
severity: normal
status: open
title: random.choice hits ValueError: cannot convert float NaN to integer
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/issue14028>
_______________________________________

From report at bugs.python.org  Thu Feb 16 09:06:47 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 16 Feb 2012 08:06:47 +0000
Subject: [issue14028] random.choice hits ValueError: cannot convert float NaN
	to integer
In-Reply-To: <1329379073.39.0.519578524869.issue14028@psf.upfronthosting.co.za>
Message-ID: <1329379607.31.0.436359317655.issue14028@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14028>
_______________________________________

From report at bugs.python.org  Thu Feb 16 09:09:00 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 16 Feb 2012 08:09:00 +0000
Subject: [issue13986] ValueError: cannot convert float NaN to integer
In-Reply-To: <1328874238.47.0.897260032056.issue13986@psf.upfronthosting.co.za>
Message-ID: <1329379740.81.0.521868671739.issue13986@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

FYI - A "similar" NaN appearing in an unexpected place (the random module in this case) bug that I just filed - http://bugs.python.org/issue14028.

I don't actually know if these will be related or not.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13986>
_______________________________________

From report at bugs.python.org  Thu Feb 16 09:10:09 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 16 Feb 2012 08:10:09 +0000
Subject: [issue14028] random.choice hits ValueError: cannot convert float NaN
	to integer
In-Reply-To: <1329379073.39.0.519578524869.issue14028@psf.upfronthosting.co.za>
Message-ID: <1329379809.37.0.479924904748.issue14028@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14028>
_______________________________________

From report at bugs.python.org  Thu Feb 16 09:40:38 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 16 Feb 2012 08:40:38 +0000
Subject: [issue2489] Patch for bugs in pty.py
In-Reply-To: <1206494149.11.0.607365562092.issue2489@psf.upfronthosting.co.za>
Message-ID: <E1RxwtJ-0003wA-3r@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 994659efa292 by Gregory P. Smith in branch '3.2':
Issue #2489: Fix bug in _copy loop that could consume 100% cpu on EOF.
http://hg.python.org/cpython/rev/994659efa292

New changeset c7338f62f956 by Gregory P. Smith in branch 'default':
Issue #2489: Fix bug in _copy loop that could consume 100% cpu on EOF.
http://hg.python.org/cpython/rev/c7338f62f956

New changeset f889458c65cc by Gregory P. Smith in branch '2.7':
Issue #2489: Fix bug in _copy loop that could consume 100% cpu on EOF.
http://hg.python.org/cpython/rev/f889458c65cc

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2489>
_______________________________________

From report at bugs.python.org  Thu Feb 16 09:43:07 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 16 Feb 2012 08:43:07 +0000
Subject: [issue2489] Patch for bugs in pty.py
In-Reply-To: <1206494149.11.0.607365562092.issue2489@psf.upfronthosting.co.za>
Message-ID: <1329381787.84.0.976472134473.issue2489@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I'm keeping this open to address the added behavior for spawn in 3.3.

----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
stage: test needed -> 
versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2489>
_______________________________________

From report at bugs.python.org  Thu Feb 16 10:02:00 2012
From: report at bugs.python.org (Lyudmil Nenov)
Date: Thu, 16 Feb 2012 09:02:00 +0000
Subject: [issue14029] When using setattr identifiers can start with any
	character
Message-ID: <1329382920.47.0.960341753942.issue14029@psf.upfronthosting.co.za>


New submission from Lyudmil Nenov <lnenov at mm-sol.com>:

I am not sure if this is actually a bug. 

Given documentation @ http://docs.python.org/release/2.5.2/ref/identifiers.html, the issue is that setattr does not appear to check identifier for naming convention.

See a short example below. Running on windows

>>> sys.version_info(major=2, minor=7, micro=1, releaselevel='final', serial=0)
>>> sys.version_info
sys.version_info(major=2, minor=7, micro=1, releaselevel='final', serial=0)
>>> class Example():
	pass
>>> example = Example()
>>> example. at foo = 4
SyntaxError: invalid syntax
>>> setattr(example, '@foo', 'bar')
>>> dir(example)
['@foo', '__doc__', '__module__']
>>> example. at foo
SyntaxError: invalid syntax
>>> getattr(example, '@foo')
'bar'

----------
messages: 153468
nosy: lnenov
priority: normal
severity: normal
status: open
title: When using setattr identifiers can start with any character
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14029>
_______________________________________

From report at bugs.python.org  Thu Feb 16 10:15:10 2012
From: report at bugs.python.org (Jaap Karssenberg)
Date: Thu, 16 Feb 2012 09:15:10 +0000
Subject: [issue14025] unittest.TestCase.assertEqual does not show diff when
	comparing str with unicode
In-Reply-To: <1329348544.52.0.316662412612.issue14025@psf.upfronthosting.co.za>
Message-ID: <CA+TmwMHdWt34DX7P54+671UcZS4eF5eSkmCMFzWUUe2X+CAsiw@mail.gmail.com>


Jaap Karssenberg <jaap.karssenberg at gmail.com> added the comment:

On Thu, Feb 16, 2012 at 12:29 AM, Michael Foord <report at bugs.python.org>wrote:

> The type check in assertEqual, that delegates to the different comparison
> methods, is strict because we can't know that using the error message
> algorithms is sane for arbitrary subclasses - all we can know is whether an
> equality comparison fails or succeeds.
>

So would you allow me to register a method for type "basestring" and have
assertEqual dispatch to that method when both arguments are of this type ?

That way at least I could customize the behavior in sub classes.

Thanks,

Jaap

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14025>
_______________________________________

From report at bugs.python.org  Thu Feb 16 10:22:54 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 16 Feb 2012 09:22:54 +0000
Subject: [issue14029] When using setattr identifiers can start with any
	character
In-Reply-To: <1329382920.47.0.960341753942.issue14029@psf.upfronthosting.co.za>
Message-ID: <1329384174.89.0.802238495704.issue14029@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It's not a bug. The specification of identifiers refers only to the places where they appear in the language grammar, i.e. what you can put into source code. What parameters objects accept in __setattr__ is an entirely different question. Some objects may check for well-formedness, some objects may accept only a small number of identifiers (e.g. when they use __slots__), some may accept non-strings as attribute names.

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14029>
_______________________________________

From report at bugs.python.org  Thu Feb 16 10:37:15 2012
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Thu, 16 Feb 2012 09:37:15 +0000
Subject: [issue14030] Be more careful about selecting the compiler in distutils
Message-ID: <1329385035.22.0.0715283153402.issue14030@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

distutils incorrectly handles CFLAGS as 1 argument instead of
space-separated list of arguments. distutils should respect environment
variables, which set compiler, linker etc.

--- Lib/distutils/unixccompiler.py
+++ Lib/distutils/unixccompiler.py
@@ -297,7 +297,7 @@
        # this time, there's no way to determine this information from
        # the configuration data stored in the Python installation, so
        # we use this hack.
-        compiler = os.path.basename(sysconfig.get_config_var("CC"))
+        compiler = os.path.basename(self.compiler[0])
        if sys.platform[:6] == "darwin":
            # MacOSX's linker doesn't understand the -R flag at all
            return "-L" + dir

Patch was created by Arfrever Frehtes Taifersar Arahesis (arfrever.fta at gmail.com). It was originally written for PyPy, but it seems like it should actually apply to the stdlib. This patch is for 2.7, I'm hoping it could be taken as a bug fix.

----------
messages: 153471
nosy: djc
priority: normal
severity: normal
status: open
title: Be more careful about selecting the compiler in distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14030>
_______________________________________

From report at bugs.python.org  Thu Feb 16 10:37:19 2012
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Thu, 16 Feb 2012 09:37:19 +0000
Subject: [issue14030] Be more careful about selecting the compiler in distutils
In-Reply-To: <1329385035.22.0.0715283153402.issue14030@psf.upfronthosting.co.za>
Message-ID: <1329385039.45.0.0967391359973.issue14030@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14030>
_______________________________________

From report at bugs.python.org  Thu Feb 16 11:24:39 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 16 Feb 2012 10:24:39 +0000
Subject: [issue14028] random.choice hits ValueError: cannot convert float NaN
	to integer
In-Reply-To: <1329379073.39.0.519578524869.issue14028@psf.upfronthosting.co.za>
Message-ID: <1329387879.99.0.553328502727.issue14028@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/issue14028>
_______________________________________

From report at bugs.python.org  Thu Feb 16 11:27:08 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 16 Feb 2012 10:27:08 +0000
Subject: [issue13986] ValueError: cannot convert float NaN to integer
In-Reply-To: <1328874238.47.0.897260032056.issue13986@psf.upfronthosting.co.za>
Message-ID: <1329388028.99.0.923551181611.issue13986@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

My guess would be not related.  My best guess for this issue is that it's caused by some mismatch in the struct stat declarations / uses on MIPS / Linux.  A Google search for MIPS and stat suggests that there are problems in this area.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13986>
_______________________________________

From report at bugs.python.org  Thu Feb 16 11:28:08 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Feb 2012 10:28:08 +0000
Subject: [issue14028] random.choice hits ValueError: cannot convert float NaN
	to integer
In-Reply-To: <1329379073.39.0.519578524869.issue14028@psf.upfronthosting.co.za>
Message-ID: <1329388088.5.0.0821520545609.issue14028@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14028>
_______________________________________

From report at bugs.python.org  Thu Feb 16 11:43:27 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 16 Feb 2012 10:43:27 +0000
Subject: [issue14028] random.choice hits ValueError: cannot convert float NaN
	to integer
In-Reply-To: <1329379073.39.0.519578524869.issue14028@psf.upfronthosting.co.za>
Message-ID: <1329389007.29.0.468236949316.issue14028@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm, this is a little odd.  For 2.7 at least, the error message is coming from PyLong_FromDouble in Objects/longobject.c.  I can't immediately see how PyLong_FromDouble could be called by the random seeding process.

So it seems more likely that the error is really coming from the int() call in the traceback.  But now that implies that the random call is returning NaN, which looks unpossible from the code (random_random in Modules/_randommodule.c).


static PyObject *
random_random(RandomObject *self)
{
    unsigned long a=genrand_int32(self)>>5, b=genrand_int32(self)>>6;
    return PyFloat_FromDouble((a*67108864.0+b)*(1.0/9007199254740992.0));
}


So despite your comments about healthy hardware, my bet's on corrupted memory. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14028>
_______________________________________

From report at bugs.python.org  Thu Feb 16 11:57:57 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 16 Feb 2012 10:57:57 +0000
Subject: [issue14028] random.choice hits ValueError: cannot convert float NaN
	to integer
In-Reply-To: <1329379073.39.0.519578524869.issue14028@psf.upfronthosting.co.za>
Message-ID: <1329389877.59.0.568519535448.issue14028@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The bugs.launchpad.net URL shows a call to 'entropy.choice'.  Any idea what 'entropy' is?  Could it be that they're using their own Random subclass, not tied to the Python MT implementation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14028>
_______________________________________

From report at bugs.python.org  Thu Feb 16 12:09:08 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Feb 2012 11:09:08 +0000
Subject: [issue14028] random.choice hits ValueError: cannot convert float NaN
	to integer
In-Reply-To: <1329379073.39.0.519578524869.issue14028@psf.upfronthosting.co.za>
Message-ID: <1329390548.37.0.604561482879.issue14028@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The hypothesis that time.time() is returning NaN doesn't match the provided traceback.  If time.time() had returned NaN, the exception would have happened earlier, on line 113 in random.py:  long(time.time() * 256)

I'm wondering if the NaN arises in the C code for random():

random_random(RandomObject *self)
{
    unsigned long a=genrand_int32(self)>>5, b=genrand_int32(self)>>6;
    return PyFloat_FromDouble((a*67108864.0+b)*(1.0/9007199254740992.0));
}

Upstream from that, only integers are used, so this would be the earliest a NaN could arise when running the code in choice():  ``return seq[int(self.random() * len(seq))]``

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14028>
_______________________________________

From report at bugs.python.org  Thu Feb 16 12:29:10 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 16 Feb 2012 11:29:10 +0000
Subject: [issue14028] random.choice hits ValueError: cannot convert float NaN
	to integer
In-Reply-To: <1329379073.39.0.519578524869.issue14028@psf.upfronthosting.co.za>
Message-ID: <1329391750.6.0.0986634216225.issue14028@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I'm wondering if the NaN arises in the C code for random():

I don't think that's possible.  In the second line:

    return PyFloat_FromDouble((a*67108864.0+b)*(1.0/9007199254740992.0));

a and b are already C unsigned longs, so no matter what their value, the result of the expression is well in range for an IEEE 754 double, and on a normal machine there's just no realistic way that this calculation could produce a NaN.  PyFloat_FromDouble does no manipulation of the C double, but just stores it directly in the PyFloat object.


I think there are two different things going on here.

(1) The Ubuntu error reporter seems to be using something other than the standard Random class, so all bets are off there without knowing more about what's being used.  Chances seem good that whatever random number generator they're using really *is* producing a NaN.

(2) That leaves Greg's report above, where the standard Random class is apparently what's being used.  Here I'm baffled---I can't see any realistic mechanism that might produce that traceback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14028>
_______________________________________

From report at bugs.python.org  Thu Feb 16 12:54:50 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 16 Feb 2012 11:54:50 +0000
Subject: [issue12627] Implement PEP 394: The "python" Command on Unix-Like
	Systems
In-Reply-To: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>
Message-ID: <1329393290.24.0.585454652056.issue12627@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file22738/version33_links.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12627>
_______________________________________

From report at bugs.python.org  Thu Feb 16 13:10:31 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 16 Feb 2012 12:10:31 +0000
Subject: [issue12627] Implement PEP 394: The "python" Command on Unix-Like
	Systems
In-Reply-To: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>
Message-ID: <1329394231.96.0.427297154872.issue12627@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I removed the 3.3 patch, since all the previous version did was change symbolic links to hard links, and the latest round of discussions favoured retaining the symlinks since they're much easier to introspect.

However, it turns out there is still one change needed for 3.3 - updating the current python3 hardlink to make it a symlink instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12627>
_______________________________________

From report at bugs.python.org  Thu Feb 16 13:17:37 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 16 Feb 2012 12:17:37 +0000
Subject: [issue12627] Implement PEP 394: The "python" Command on Unix-Like
	Systems
In-Reply-To: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>
Message-ID: <1329394657.81.0.000271783666104.issue12627@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Actually, the Python 3 Makefile.pre.in is currently broken if $(EXE) is ever non-empty - in a few places it uses "$(PYTHON)$(VERSION)$(EXE)" and "$(PYTHON)3$(EXE)".

Those are wrong, because the definition of $(PYTHON) at the top of the file is "python$(EXE)"

Instead, they need to be written as "python$(VERSION)$(EXE)" and "python3$(EXE)"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12627>
_______________________________________

From report at bugs.python.org  Thu Feb 16 13:29:14 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 16 Feb 2012 12:29:14 +0000
Subject: [issue12627] Implement PEP 394: The "python" Command on Unix-Like
	Systems
In-Reply-To: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>
Message-ID: <1329395354.12.0.00236666621361.issue12627@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

New patch that aims to create the appropriate symlinks in "make bininstall". I don't currently have a sacrificial VM set up to test it in though.

----------
Added file: http://bugs.python.org/file24530/pep394_python27_symlinks.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12627>
_______________________________________

From report at bugs.python.org  Thu Feb 16 13:29:45 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 16 Feb 2012 12:29:45 +0000
Subject: [issue12627] Implement PEP 394: The "python" Command on Unix-Like
	Systems
In-Reply-To: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>
Message-ID: <1329395385.24.0.939074462076.issue12627@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file22737/version27_links.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12627>
_______________________________________

From report at bugs.python.org  Thu Feb 16 14:04:26 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 16 Feb 2012 13:04:26 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329397466.05.0.860510433806.issue13988@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'm still not sure that's the best option.  Without deprecation people will keep using cElementTree and we will have to keep it around forever (or at least until Python4 and then have a 3to4 to fix the import).
This might be fine, but as a developer I would still like Python to tell me "You can just import ElementTree now, there's no need to use cElementTree".  Maybe the deprecation can be added to 3.4?

P.S. I'm fine with keeping it around for several more versions, but if we eventually have to remove it, we would still have to warn the users beforehand.  The more we wait, the more users will be still using cElementTree by the time we will actually remove it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Thu Feb 16 15:21:26 2012
From: report at bugs.python.org (Jason Yeo)
Date: Thu, 16 Feb 2012 14:21:26 +0000
Subject: [issue14026] test_cmd_line_script should include more sys.argv checks
In-Reply-To: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za>
Message-ID: <1329402086.83.0.55772921162.issue14026@psf.upfronthosting.co.za>


Changes by Jason Yeo <jasonyeo88 at gmail.com>:


----------
nosy: +Jason.Yeo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14026>
_______________________________________

From report at bugs.python.org  Thu Feb 16 16:15:42 2012
From: report at bugs.python.org (Jack Jansen)
Date: Thu, 16 Feb 2012 15:15:42 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1329405342.45.0.163762728984.issue13210@psf.upfronthosting.co.za>


Changes by Jack Jansen <jackjansen at users.sourceforge.net>:


----------
nosy: +jackjansen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Thu Feb 16 16:20:49 2012
From: report at bugs.python.org (Guido Kollerie)
Date: Thu, 16 Feb 2012 15:20:49 +0000
Subject: [issue14031] logging module cannot format str.format log messages
Message-ID: <1329405649.45.0.0231002086589.issue14031@psf.upfronthosting.co.za>


New submission from Guido Kollerie <guido at kollerie.com>:

When logging messages with variable data one typically writes:

    username = 'Guido'
    logging.info('User %s logged in', username)

However Python 3 has support str.format (PEP 3101). If one has adopted str.format for formatting strings in Python 3 code one should also be able to write the above as:

    logging.info('User {} logged in', username)

However this currently is not supported. For backwards compatibility,% style logging should remain the default. However when a logger is configured using:

    import logging
    logging.basicConfig(style='{', format='{levelname}:{message}')

all subsequent calls to logging.debug, logging.info, logging.warning, logging.error, logging.critical, logging.exception and logging.log should use str.format for formatting.

----------
messages: 153481
nosy: gkoller
priority: normal
severity: normal
status: open
title: logging module cannot format str.format log messages
type: enhancement
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14031>
_______________________________________

From report at bugs.python.org  Thu Feb 16 16:31:09 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Feb 2012 15:31:09 +0000
Subject: [issue14031] logging module cannot format str.format log messages
In-Reply-To: <1329405649.45.0.0231002086589.issue14031@psf.upfronthosting.co.za>
Message-ID: <1329406269.42.0.52939815573.issue14031@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That can't work.  The logging messages may come from libraries written by someone else, using % formatting.  The style has to be set at the individual logger level.

----------
nosy: +r.david.murray, vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14031>
_______________________________________

From report at bugs.python.org  Thu Feb 16 16:45:41 2012
From: report at bugs.python.org (Jack Jansen)
Date: Thu, 16 Feb 2012 15:45:41 +0000
Subject: [issue13892] distutils handling of windows manifest isn't optimal
In-Reply-To: <1327698565.84.0.667656042788.issue13892@psf.upfronthosting.co.za>
Message-ID: <1329407141.56.0.555108015923.issue13892@psf.upfronthosting.co.za>


Jack Jansen <jackjansen at users.sourceforge.net> added the comment:

Indeed, my situation is different from the cscript.exe situation because in my case Python needs to call back into the hosting application.

Further experiments have shown that this is indeed the problem, and moreover that this is a problem that cannot be solved (at least, I am not smart enough to solve it:-). The Python extension module that does the callbacks would have to live in two different runtime worlds: if it allocates python objects it would have to use the VS2008 runtime, if it allocates Ambulant objects it would  have to use 2010 runtime.

This makes the whole original topic of this bug report of academic interest only. Fell free to close/won't fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13892>
_______________________________________

From report at bugs.python.org  Thu Feb 16 16:59:47 2012
From: report at bugs.python.org (Guido Kollerie)
Date: Thu, 16 Feb 2012 15:59:47 +0000
Subject: [issue14031] logging module cannot format str.format log messages
In-Reply-To: <1329405649.45.0.0231002086589.issue14031@psf.upfronthosting.co.za>
Message-ID: <1329407987.79.0.166149497641.issue14031@psf.upfronthosting.co.za>


Guido Kollerie <guido at kollerie.com> added the comment:

I see, could this be made to work if I explicitly request a logger instead?:

    logger = logging.getLogger('my_logger', style='{')
    logger.info('User {} logged in', username)

Maybe even for the root logger:

    root_logger = logging.getLogger(style='{')
    root_logger.info('User {} logged in', username)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14031>
_______________________________________

From report at bugs.python.org  Thu Feb 16 17:17:51 2012
From: report at bugs.python.org (Jason Yeo)
Date: Thu, 16 Feb 2012 16:17:51 +0000
Subject: [issue14032] test_cmd_line_script prints undefined 'data' variable
Message-ID: <1329409071.29.0.619315923648.issue14032@psf.upfronthosting.co.za>


New submission from Jason Yeo <jasonyeo88 at gmail.com>:

Hi, I'm new around here. I was trying to fix issue 14026 and I found this problem. In test_cmd_line_script, the test_issue8202 tries to print an undefined data variable when verbose is set to > 1. I have a patch attached to print(out) instead of print(data). Please let me know if this is the correct thing to do.

----------
components: Tests
files: mypatch
messages: 153485
nosy: Jason.Yeo
priority: normal
severity: normal
status: open
title: test_cmd_line_script prints undefined 'data' variable
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file24531/mypatch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14032>
_______________________________________

From report at bugs.python.org  Thu Feb 16 17:18:15 2012
From: report at bugs.python.org (Jason Yeo)
Date: Thu, 16 Feb 2012 16:18:15 +0000
Subject: [issue14032] test_cmd_line_script prints undefined 'data' variable
In-Reply-To: <1329409071.29.0.619315923648.issue14032@psf.upfronthosting.co.za>
Message-ID: <1329409095.34.0.439516117877.issue14032@psf.upfronthosting.co.za>


Changes by Jason Yeo <jasonyeo88 at gmail.com>:


Added file: http://bugs.python.org/file24532/mypatch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14032>
_______________________________________

From report at bugs.python.org  Thu Feb 16 17:18:35 2012
From: report at bugs.python.org (Jason Yeo)
Date: Thu, 16 Feb 2012 16:18:35 +0000
Subject: [issue14032] test_cmd_line_script prints undefined 'data' variable
In-Reply-To: <1329409071.29.0.619315923648.issue14032@psf.upfronthosting.co.za>
Message-ID: <1329409115.45.0.200592635767.issue14032@psf.upfronthosting.co.za>


Changes by Jason Yeo <jasonyeo88 at gmail.com>:


Removed file: http://bugs.python.org/file24532/mypatch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14032>
_______________________________________

From report at bugs.python.org  Thu Feb 16 17:44:12 2012
From: report at bugs.python.org (=?utf-8?b?5YuH5YiaIOe9lw==?=)
Date: Thu, 16 Feb 2012 16:44:12 +0000
Subject: [issue14033] distutils problem with setup.py build &setup.py install
	vs direct setup.py install
Message-ID: <1329410652.02.0.479827647227.issue14033@psf.upfronthosting.co.za>


New submission from ?? ? <luoyonggang at gmail.com>:

D:\CI\bld\vcs>build-pygit2.bat

D:\CI\bld\vcs\pygit2>call python setup.py build  & call python setup.py install  & cd /d D:\CI\bld\vcs
running build
running build_py
running build_ext
building 'pygit2' extension
creating build
creating build\temp.win32-3.2
creating build\temp.win32-3.2\Release
c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -ID:\CI\Tools\vcs\libgit2\include -IC:\Python32\
include -IC:\Python32\PC /Tcpygit2.c /Fobuild\temp.win32-3.2\Release\pygit2.obj
pygit2.c
pygit2.c(476) : warning C4101: 'aux' : unreferenced local variable
pygit2.c(498) : warning C4101: 'err' : unreferenced local variable
pygit2.c(1088) : warning C4101: 'err' : unreferenced local variable
pygit2.c(1185) : warning C4244: 'function' : conversion from 'git_time_t' to 'long', possible loss of data
pygit2.c(2794) : warning C4244: 'function' : conversion from 'const git_time_t' to 'long', possible loss of data
creating build\lib.win32-3.2
c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:D:\CI\Tools\vcs\libgit2\lib /LIBPATH:C:\Pytho
n32\libs /LIBPATH:C:\Python32\PCbuild git2.lib /EXPORT:PyInit_pygit2 build\temp.win32-3.2\Release\pygit2.obj /OUT:build\lib.win32-3.2\pygit2.pyd /IMPL
IB:build\temp.win32-3.2\Release\pygit2.lib /MANIFESTFILE:build\temp.win32-3.2\Release\pygit2.pyd.manifest
   Creating library build\temp.win32-3.2\Release\pygit2.lib and object build\temp.win32-3.2\Release\pygit2.exp
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe -nologo -manifest build\temp.win32-3.2\Release\pygit2.pyd.manifest -outputresource:build\lib.
win32-3.2\pygit2.pyd;2
copying D:\CI\Tools\vcs\libgit2\bin\git2.dll -> pygit2
running install
running build
running build_py
copying pygit2\git2.dll -> build\lib.win32-3.2
running build_ext
running install_lib
copying build\lib.win32-3.2\git2.dll -> C:\Python32\Lib\site-packages
copying build\lib.win32-3.2\pygit2.pyd -> C:\Python32\Lib\site-packages
running install_egg_info
Writing C:\Python32\Lib\site-packages\pygit2-0.16.0-py3.2.egg-info

D:\CI\bld\vcs>

Direct install

D:\CI\bld\vcs>build-pygit2.bat

D:\CI\bld\vcs\pygit2>call python setup.py install  & cd /d D:\CI\bld\vcs
running install
running build
running build_py
running build_ext
building 'pygit2' extension
creating build
creating build\temp.win32-3.2
creating build\temp.win32-3.2\Release
c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -ID:\CI\Tools\vcs\libgit2\include -IC:\Python32\
include -IC:\Python32\PC /Tcpygit2.c /Fobuild\temp.win32-3.2\Release\pygit2.obj
pygit2.c
pygit2.c(476) : warning C4101: 'aux' : unreferenced local variable
pygit2.c(498) : warning C4101: 'err' : unreferenced local variable
pygit2.c(1088) : warning C4101: 'err' : unreferenced local variable
pygit2.c(1185) : warning C4244: 'function' : conversion from 'git_time_t' to 'long', possible loss of data
pygit2.c(2794) : warning C4244: 'function' : conversion from 'const git_time_t' to 'long', possible loss of data
creating build\lib.win32-3.2
c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:D:\CI\Tools\vcs\libgit2\lib /LIBPATH:C:\Pytho
n32\libs /LIBPATH:C:\Python32\PCbuild git2.lib /EXPORT:PyInit_pygit2 build\temp.win32-3.2\Release\pygit2.obj /OUT:build\lib.win32-3.2\pygit2.pyd /IMPL
IB:build\temp.win32-3.2\Release\pygit2.lib /MANIFESTFILE:build\temp.win32-3.2\Release\pygit2.pyd.manifest
   Creating library build\temp.win32-3.2\Release\pygit2.lib and object build\temp.win32-3.2\Release\pygit2.exp
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe -nologo -manifest build\temp.win32-3.2\Release\pygit2.pyd.manifest -outputresource:build\lib.
win32-3.2\pygit2.pyd;2
copying D:\CI\Tools\vcs\libgit2\bin\git2.dll -> pygit2
running install_lib
copying build\lib.win32-3.2\pygit2.pyd -> C:\Python32\Lib\site-packages
running install_egg_info
Writing C:\Python32\Lib\site-packages\pygit2-0.16.0-py3.2.egg-info

D:\CI\bld\vcs>

----------
assignee: tarek
components: Distutils
messages: 153486
nosy: eric.araujo, tarek, ??.?
priority: normal
severity: normal
status: open
title: distutils problem with setup.py build &setup.py install vs direct setup.py install
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14033>
_______________________________________

From report at bugs.python.org  Thu Feb 16 18:05:42 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 16 Feb 2012 17:05:42 +0000
Subject: [issue14031] logging module cannot format str.format log messages
In-Reply-To: <1329405649.45.0.0231002086589.issue14031@psf.upfronthosting.co.za>
Message-ID: <1329411942.95.0.959279997935.issue14031@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Use instead the approach described in this post:

http://plumberjack.blogspot.com/2010/10/supporting-alternative-formatting.html

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14031>
_______________________________________

From report at bugs.python.org  Thu Feb 16 18:29:48 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 16 Feb 2012 17:29:48 +0000
Subject: [issue14028] random.choice hits ValueError: cannot convert float NaN
	to integer
In-Reply-To: <1329379073.39.0.519578524869.issue14028@psf.upfronthosting.co.za>
Message-ID: <1329413388.18.0.995271305791.issue14028@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I think my claim the hardware appears healthy was premature.  I misunderstood our initial error report internally on where the code ran and was looking at the wrong host.  doh.  my bad.

Several more of these have been found in the last week and they all suspiciously ran on the same machine.  One of them had a _different_ failure that is an even stronger suggestion of bad hardware:

 File "/.../lib/python2.6/random.py", line 57, in <module>
   NV_MAGICCONST = 4 * _exp(-0.5)/_sqrt(2.0)
ValueError: math domain error

Sorry for the false alarm.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14028>
_______________________________________

From report at bugs.python.org  Thu Feb 16 18:41:50 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 16 Feb 2012 17:41:50 +0000
Subject: [issue14020] Improve HTMLParser doc
In-Reply-To: <1329314372.41.0.194033246825.issue14020@psf.upfronthosting.co.za>
Message-ID: <1329414110.75.0.040785072959.issue14020@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Do you remember how to do it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14020>
_______________________________________

From report at bugs.python.org  Thu Feb 16 19:12:55 2012
From: report at bugs.python.org (Matt Joiner)
Date: Thu, 16 Feb 2012 18:12:55 +0000
Subject: [issue12655] Expose sched.h functions
In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za>
Message-ID: <1329415975.46.0.62821954173.issue12655@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

Please also expose sched_getcpu().

----------
nosy: +anacrolix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12655>
_______________________________________

From report at bugs.python.org  Thu Feb 16 19:34:22 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 16 Feb 2012 18:34:22 +0000
Subject: [issue14034] the example in argparse doc is too complex
Message-ID: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

The argparse example (http://docs.python.org/dev/library/argparse.html#example) introduces way too many concepts too early. It's written as if targeted to existing users of optparse, instead of newcomers to Python's CLI handling.

Perhaps the example could be more gentle, or if there is insistence on showing off, maybe the page could be kept as-is, but with a link to some tutorial (as is done with logging: http://docs.python.org/dev/library/logging.html).

----------
assignee: docs at python
components: Documentation
messages: 153491
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: the example in argparse doc is too complex
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14034>
_______________________________________

From report at bugs.python.org  Thu Feb 16 19:55:18 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 16 Feb 2012 18:55:18 +0000
Subject: [issue13878] test_sched failures on Windows buildbot
In-Reply-To: <1327597038.78.0.0899603043053.issue13878@psf.upfronthosting.co.za>
Message-ID: <E1Ry6U9-00063A-2D@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 662c60d26183 by Charles-Fran?ois Natali in branch '3.2':
Issue #13878: Fix random test_sched failures.
http://hg.python.org/cpython/rev/662c60d26183

New changeset e35091b95813 by Charles-Fran?ois Natali in branch 'default':
Issue #13878: Fix random test_sched failures.
http://hg.python.org/cpython/rev/e35091b95813

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13878>
_______________________________________

From report at bugs.python.org  Thu Feb 16 19:58:41 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 16 Feb 2012 18:58:41 +0000
Subject: [issue13961] Have importlib use os.replace()
In-Reply-To: <1328624796.15.0.577971130856.issue13961@psf.upfronthosting.co.za>
Message-ID: <1329418721.21.0.604540240626.issue13961@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13961>
_______________________________________

From report at bugs.python.org  Thu Feb 16 20:13:55 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 16 Feb 2012 19:13:55 +0000
Subject: [issue14024] logging.Formatter Cache Prevents Exception Format
	Overriding
In-Reply-To: <1329329303.3.0.810065424227.issue14024@psf.upfronthosting.co.za>
Message-ID: <1329419635.45.0.216607108209.issue14024@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

A number of points:

1. exc_text is not just an implementation detail - it's in the docs. Thus, removing the cache altogether would be backwards-incompatible.

2. The exc_text value is the only simple way of propagating the exception information across the wire, which is a common use case (e.g SocketHandler).

3. This is not a "behavior" issue, as the behaviour is by design and documented.

4. What's wrong with the following approach?

class NoStackTraceFormatter(logging.Formatter):
    def formatException(self, exc_info):  # Don't emit the stack trace
        return '\n'.join(traceback.format_exception_only(exc_info[0], exc_info[1])) # type and value only

    def format(self, record):
        saved_exc_text = record.exc_text # optional
        record.exc_text = None
        result = super(NoStackTraceFormatter, self).format(record)
        record.exc_text = saved_exc_text # or None, if you want
        return result

You can either save and restore the previous exc_text value, or set it to None after the parent class operation - this will cause it to be always recomputed by the next handler. This way, a handler which needs abbreviated information always gets it, but other handlers append the full stack trace.

I'm closing this as I believe my suggestion shows a way of subclassing and overriding which works. You can re-open if you think I've missed something.

----------
nosy: +vinay.sajip
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14024>
_______________________________________

From report at bugs.python.org  Thu Feb 16 20:15:00 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Feb 2012 19:15:00 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1329419700.01.0.929744797075.issue13609@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think there's much point in the proposed complications.
If you're willing to know the terminal size, you're probably interested in displaying something in it (using stdout), so why would you care about stderr or stdin?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Thu Feb 16 20:25:37 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Thu, 16 Feb 2012 19:25:37 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1329419700.01.0.929744797075.issue13609@psf.upfronthosting.co.za>
Message-ID: <4F3D582A.5050300@in.waw.pl>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

Stdout can be connected to a pipe, e.g to less, which in turn might
be connected to a terminal. The program can then display output properly 
scaled for the terminal, assuming that because stdin is
connnected to a terminal, output will eventually reach the same 
terminal. Sometimes this is true, sometimes not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Thu Feb 16 20:44:59 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 16 Feb 2012 19:44:59 +0000
Subject: [issue13878] test_sched failures on Windows buildbot
In-Reply-To: <1327597038.78.0.0899603043053.issue13878@psf.upfronthosting.co.za>
Message-ID: <1329421499.87.0.477176136989.issue13878@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Should be fixed now, thanks.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13878>
_______________________________________

From report at bugs.python.org  Thu Feb 16 20:47:35 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 16 Feb 2012 19:47:35 +0000
Subject: [issue13995] sqlite3 Cursor.rowcount documentation for old sqlite bug
In-Reply-To: <1328991377.3.0.315009784222.issue13995@psf.upfronthosting.co.za>
Message-ID: <E1Ry7Ih-0002oV-2o@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 74b2da95c6be by Petri Lehtinen in branch '3.2':
sqlite3: Fix documentation errors concerning Cursor.rowcount
http://hg.python.org/cpython/rev/74b2da95c6be

New changeset a1f17e108a1b by Petri Lehtinen in branch '2.7':
Fix errors in sqlite3's Cursor.rowcount documentation
http://hg.python.org/cpython/rev/a1f17e108a1b

New changeset 08699214f79b by Petri Lehtinen in branch 'default':
Merge branch '3.2'
http://hg.python.org/cpython/rev/08699214f79b

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13995>
_______________________________________

From report at bugs.python.org  Thu Feb 16 20:48:05 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 16 Feb 2012 19:48:05 +0000
Subject: [issue13995] sqlite3 Cursor.rowcount documentation for old sqlite bug
In-Reply-To: <1328991377.3.0.315009784222.issue13995@psf.upfronthosting.co.za>
Message-ID: <1329421685.93.0.688454241519.issue13995@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Fixed, thanks!

----------
nosy: +petri.lehtinen
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13995>
_______________________________________

From report at bugs.python.org  Thu Feb 16 21:45:58 2012
From: report at bugs.python.org (Catalin Iacob)
Date: Thu, 16 Feb 2012 20:45:58 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <1324386392.48.0.968435833624.issue13641@psf.upfronthosting.co.za>
Message-ID: <1329425158.38.0.875619740597.issue13641@psf.upfronthosting.co.za>


Catalin Iacob <iacobcatalin at gmail.com> added the comment:

Attached alternative patch with a different approach: on input, strings are encoded as bytes and the rest of the code proceeds as before.

All existing tests for bytes now test for strings as well and there is a new test for strings with non ASCII characters.

Berker's patch was more intrusive and forgot to allow strings in _translate, leading to failures if altchars or map01 were used.

----------
nosy: +catalin.iacob
Added file: http://bugs.python.org/file24533/issue13641-alternative-v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From owenljn at gmail.com  Wed Feb 15 07:40:42 2012
From: owenljn at gmail.com (OwenLJN)
Date: Tue, 14 Feb 2012 22:40:42 -0800 (PST)
Subject: RuntimeError: maximum recursion depth exceeded in cmp
Message-ID: <1329288042027-4471100.post@n6.nabble.com>

Hi
I wrote a python function self_contained(x) that finds all lists in x that
contain themselves.
Here's the body of the function:

def self_contained(x):
    L = []
    if not isinstance(x, list):
        return []
    for i in x:
        if isinstance(i, list):
            if i in i:
                L += [i]
    return L

L5 =[]
L6 = []
L5.append(L6)
L6.append(L5)

then I compare L5 and L6 in shell:
L5 == L6
and it gives me this error:
RuntimeError: maximum recursion depth exceeded in cmp
I think probably I need to add another parameter to self_contained or to a
helper function to make my function work when I call L5 or L6. So How can I
fix this error??
I put this code: sys.setrecursionlimit(2500) in the begining doens't fix the
error.
And I don't know how to change self_contained to a recursive function can
any1 help me with this?Thanks!


--
View this message in context: http://python.6.n6.nabble.com/RuntimeError-maximum-recursion-depth-exceeded-in-cmp-tp4471100p4471100.html
Sent from the Python - python-bugs-list mailing list archive at Nabble.com.

From owenljn at gmail.com  Thu Feb 16 05:08:09 2012
From: owenljn at gmail.com (OwenLJN)
Date: Wed, 15 Feb 2012 20:08:09 -0800 (PST)
Subject: RuntimeError: maximum recursion depth exceeded in cmp
In-Reply-To: <1329288042027-4471100.post@n6.nabble.com>
References: <1329288042027-4471100.post@n6.nabble.com>
Message-ID: <1329365289172-4474728.post@n6.nabble.com>

Let me restate my question:I want to make self_contained(L5) and
self_contained(L6) work, but I get RuntimeError how can I fix this by adding
one more parameter to check if a list inside a list was seen before, and
then stop the loop to prevent the error message from showing again? And I
found that the id of L5 is different with L6 and
"L5 in L6" and "L6 in L5" returns True

--
View this message in context: http://python.6.n6.nabble.com/RuntimeError-maximum-recursion-depth-exceeded-in-cmp-tp4471100p4474728.html
Sent from the Python - python-bugs-list mailing list archive at Nabble.com.

From report at bugs.python.org  Thu Feb 16 22:14:33 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Feb 2012 21:14:33 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <1324386392.48.0.968435833624.issue13641@psf.upfronthosting.co.za>
Message-ID: <1329426873.44.0.0478894679015.issue13641@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Um.  I'm inclined to think that #13637 was a mistake.

Functions that accept bytes and return bytes and also accept string and return string seem uncontroversial.  However, accepting bytes or string and returning bytes is not an obviously good idea, and IMO at least merits some discussion.  In fact, I thought it *had* been discussed, specifically in the context of the b2a/a2b functions, and been rejected.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Thu Feb 16 22:17:50 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Feb 2012 21:17:50 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <1324386392.48.0.968435833624.issue13641@psf.upfronthosting.co.za>
Message-ID: <1329427070.49.0.303909511366.issue13641@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> However, accepting bytes or string and returning bytes is not an
> obviously good idea, and IMO at least merits some discussion.

Why? "a" in "a2b" means ASCII, and unicode is as valid a container for ASCII text as bytes is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Thu Feb 16 22:27:14 2012
From: report at bugs.python.org (miro ilias)
Date: Thu, 16 Feb 2012 21:27:14 +0000
Subject: [issue9631] Python 2.7 installation issue for Linux gcc-4.1.0-3
	(Fedora Core 5?)
In-Reply-To: <1282108953.92.0.943632360126.issue9631@psf.upfronthosting.co.za>
Message-ID: <1329427634.01.0.212539728458.issue9631@psf.upfronthosting.co.za>


miro ilias <Miroslav.Ilias at umb.sk> added the comment:

Hi, 

with the fresh downloadable version of Python 2.7.2 I got the same error.


/usr/bin/install -c -m 644 ./Lib/curses/wrapper.py /home/ilias/bin/python_static/lib/python2.7/curses
/usr/bin/install -c -m 644 ./Lib/pydoc_data/__init__.py /home/ilias/bin/python_static/lib/python2.7/pydoc_data
/usr/bin/install -c -m 644 ./Lib/pydoc_data/topics.py /home/ilias/bin/python_static/lib/python2.7/pydoc_data
/usr/bin/install -c -m 644 ./Lib/plat-linux3/IN.py /home/ilias/bin/python_static/lib/python2.7/plat-linux3
/usr/bin/install -c ./Lib/plat-linux3/regen /home/ilias/bin/python_static/lib/python2.7/plat-linux3
/usr/bin/install -c -m 644 ./LICENSE /home/ilias/bin/python_static/lib/python2.7/LICENSE.txt
PYTHONPATH=/home/ilias/bin/python_static/lib/python2.7   \
		./python -Wi -tt /home/ilias/bin/python_static/lib/python2.7/compileall.py \
		-d /home/ilias/bin/python_static/lib/python2.7 -f \
		-x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \
		/home/ilias/bin/python_static/lib/python2.7
Traceback (most recent call last):
  File "/home/ilias/bin/python_static/lib/python2.7/compileall.py", line 16, in <module>
    import struct
  File "/home/ilias/bin/python_static/lib/python2.7/struct.py", line 1, in <module>
    from _struct import *
ImportError: No module named _struct
make: *** [libinstall] Chyba 1

----------
nosy: +miro_ilias

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9631>
_______________________________________

From report at bugs.python.org  Thu Feb 16 22:36:07 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 16 Feb 2012 21:36:07 +0000
Subject: [issue14035] behavior of test.support.import_fresh_module
Message-ID: <1329428167.53.0.868098431264.issue14035@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

While writing tests xml.etree, I hit a strange behaviour of import_fresh_module.

How to reproduce:

- dummy/__init__.py
- dummy/foo.py
- dummy/bar.py
- test_fresh_import.py


# 'dummy/foo.py'
from dummy.bar import func

# 'dummy/bar.py'
fortytwo = 42
def func():
    assert fortytwo == 42

# 'test_fresh_import.py'
(see attachment)


# Output:
~ $ ./python.exe test_fresh_import.py 
OK dummy.foo
OK dummy.bar
OK dummy.bar
OK dummy.foo
Traceback (most recent call last):
  File "test_fresh_import.py", line 24, in <module>
    test_fresh(m)
  File "test_fresh_import.py", line 5, in test_fresh
    rv = module.func()
  File "./dummy/bar.py", line 6, in func
    assert fortytwo == 42
AssertionError

----------
components: Tests
files: test_fresh_import.py
messages: 153503
nosy: eli.bendersky, flox, ncoghlan
priority: normal
severity: normal
status: open
title: behavior of test.support.import_fresh_module
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24534/test_fresh_import.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14035>
_______________________________________

From report at bugs.python.org  Thu Feb 16 22:40:54 2012
From: report at bugs.python.org (poq)
Date: Thu, 16 Feb 2012 21:40:54 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <1324386392.48.0.968435833624.issue13641@psf.upfronthosting.co.za>
Message-ID: <1329428454.34.0.986504898611.issue13641@psf.upfronthosting.co.za>


poq <poq at gmx.com> added the comment:

FWIW, I was surprised by the return type of b64encode when I first used it in Python 3. It seems to me that b64encode turns binary data into text and thus intuitively should take bytes and return str.

Similarly it seems intuitive to me for b64decode to take str as input and return bytes, as it turns text back into binary data.

----------
nosy: +poq

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Thu Feb 16 22:45:00 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 16 Feb 2012 21:45:00 +0000
Subject: [issue14035] behavior of test.support.import_fresh_module
In-Reply-To: <1329428167.53.0.868098431264.issue14035@psf.upfronthosting.co.za>
Message-ID: <1329428700.75.0.698359366573.issue14035@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14035>
_______________________________________

From report at bugs.python.org  Thu Feb 16 23:14:11 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Feb 2012 22:14:11 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <1324386392.48.0.968435833624.issue13641@psf.upfronthosting.co.za>
Message-ID: <1329430451.12.0.371854552636.issue13641@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, I skimmed the thread I was remembering, and while it was discussing str->str and bytes->bytes primarily, the only pronouncement I could find was that functions should not accept a *mix* of bytes and string.  So I guess I withdraw my objection, although it still makes me a bit uncomfortable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Thu Feb 16 23:25:53 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 16 Feb 2012 22:25:53 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1329347663.77.0.700121499847.issue7652@psf.upfronthosting.co.za>
Message-ID: <20120216222552.GA14823@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

STINNER Victor <report at bugs.python.org> wrote:
> decimal.Decimal.__truediv__() has an optional context argument, whereas _decimal defines PyNumberMethods.

Regarding the special methods: decimal.py uses the optional context arguments
for convenience so that these methods can be re-used in other places.

I wouldn't consider this context argument as part of the API.

> decimal.Decimal.quantize() second argument is optional and its default value
> is None, but if I pass None to _decimal.Decimal.quantize(), I get a TypeError
> because _decimal expects an integer.

About this I'm not sure. I think type errors are a courtesy to the user.
Look what is possible now in decimal.py:

Decimal('9')

But here the argument might well be made for accepting None (and only
None apart from rounding modes). - I hope Mark and Raymond will give
their opinions, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Thu Feb 16 23:28:11 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 16 Feb 2012 22:28:11 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1329431291.51.0.161861445436.issue7652@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I walked into the Roundup trap again:

>>> Decimal(9).quantize(1, "?!?!?")
Decimal('9')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Thu Feb 16 23:35:04 2012
From: report at bugs.python.org (Anders Blomdell)
Date: Thu, 16 Feb 2012 22:35:04 +0000
Subject: [issue10513] sqlite3.InterfaceError after commit
In-Reply-To: <1290515734.43.0.643837241692.issue10513@psf.upfronthosting.co.za>
Message-ID: <1329431704.33.0.563802828617.issue10513@psf.upfronthosting.co.za>


Anders Blomdell <anders.blomdell at control.lth.se> added the comment:

> So my suggestion is to remove in "pysql_connection_commit" the call to :
> pysqlite_do_all_statements(self, ACTION_RESET, 0);
> to bring back the correct old behavior.
That's what I have been running for years, now...

> And also eventually to remove in "pysqlite_connection_rollback" the 
> call to :
> pysqlite_do_all_statements(self, ACTION_RESET, 1);
Have no opinion on this

Would be really nice to not have to fix this in ech new release :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10513>
_______________________________________

From report at bugs.python.org  Thu Feb 16 23:55:10 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 16 Feb 2012 22:55:10 +0000
Subject: [issue13089] parsetok.c: memory leak
In-Reply-To: <1317545416.55.0.717898890924.issue13089@psf.upfronthosting.co.za>
Message-ID: <1329432910.67.0.0892479959445.issue13089@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Yes, that's basically what I did, but using the latest revision I cannot
reproduce the parsetok leak either.

The atexit leak is an old friend (#11826), so I think we can close
this one for now.

----------
resolution:  -> out of date
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13089>
_______________________________________

From report at bugs.python.org  Fri Feb 17 00:16:18 2012
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 16 Feb 2012 23:16:18 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1329434178.77.0.166704486443.issue2377@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Just a quick update. I have refactored importlib in the cpython repo to allow for implementing bits of importlib.__import__() and importlib._gcd_import() in C. This means that the built-in __import__() is now calling importlib underneath the covers. Eventually what is in importlib.__import__() and _gcd_import() directly will be translated into the equivalent C code. This will speed up accessing sys.modules. After that whatever is deemed on the critical path and worth rewriting in C can be done function by function. That, though, should wait for Python-level profiling and optimization before wasting one's time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Fri Feb 17 00:17:43 2012
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 16 Feb 2012 23:17:43 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1329434263.77.0.11985676075.issue2377@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Add Nick since the refactoring of importlib.__import__() into functions was his idea.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Fri Feb 17 00:40:41 2012
From: report at bugs.python.org (zulla)
Date: Thu, 16 Feb 2012 23:40:41 +0000
Subject: [issue14036] urlparse insufficient port property validation
Message-ID: <1329435639.39.0.341536822512.issue14036@psf.upfronthosting.co.za>


New submission from zulla <dan at defendassist.com>:

The "port" component of a URL is not properly be sanitized or validated. This may lead to the evasion of netloc/hostname based filters or exceptions.

----------
components: Library (Lib)
files: testurllib.py
messages: 153512
nosy: zulla
priority: normal
severity: normal
status: open
title: urlparse insufficient port property validation
type: security
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file24535/testurllib.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14036>
_______________________________________

From report at bugs.python.org  Fri Feb 17 00:44:51 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 16 Feb 2012 23:44:51 +0000
Subject: [issue14035] behavior of test.support.import_fresh_module
In-Reply-To: <1329428167.53.0.868098431264.issue14035@psf.upfronthosting.co.za>
Message-ID: <1329435891.55.0.582894957334.issue14035@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Trigger the same behavior without import_fresh_module. (test_fresh_import2.py)

If you uncomment line #A or #B, it succeed.
On the other side, if you comment line #C or #D, it succeed too.

The import machinery is a bit complex, indeed ...

----------
nosy: +brett.cannon
Added file: http://bugs.python.org/file24536/test_fresh_import2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14035>
_______________________________________

From report at bugs.python.org  Fri Feb 17 00:46:45 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 16 Feb 2012 23:46:45 +0000
Subject: [issue14037] Allow grouping of argparse subparser commands in help
	output
Message-ID: <1329436005.81.0.273577688528.issue14037@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

I've just started using the argparse subparser feature, and it's very nice. However, I'd love to be able to group the different subparser commands into different sections the way I can group ordinary arguments with add_argument_group().

Initially I thought just calling "parser.add_subparsers()" multiple times with different "title" values would work, but argparse doesn't currently like that - it errors out with "cannot have multiple subparser arguments".

I propose that instead of treating this case as an error, argparse should treat it as a way for defining subparser groups - there would still only be a single subparser argument accepted, but the individual commands would appear grouped appropriately in the help output.

----------
components: Library (Lib)
messages: 153514
nosy: bethard, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Allow grouping of argparse subparser commands in help output
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14037>
_______________________________________

From report at bugs.python.org  Fri Feb 17 00:48:55 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 16 Feb 2012 23:48:55 +0000
Subject: [issue14038] Packaging test support code raises exception
Message-ID: <1329436135.78.0.959753149495.issue14038@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

test_packaging has started failing in the pythonv branch:

======================================================================
ERROR: test_old_record_extensions (packaging.tests.test_command_install_dist.InstallTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python3.3/packaging/tests/test_command_install_dist.py", line 214, in test_old_record_extensions
    support.copy_xxmodule_c(project_dir)
  File "/usr/local/lib/python3.3/packaging/tests/support.py", line 334, in copy_xxmodule_c
    filename = _get_xxmodule_path()
  File "/usr/local/lib/python3.3/packaging/tests/support.py", line 346, in _get_xxmodule_path
    if os.path.exists(path):
UnboundLocalError: local variable 'path' referenced before assignment

======================================================================
ERROR: test_build_ext (packaging.tests.test_command_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python3.3/packaging/tests/test_command_build_ext.py", line 30, in test_build_ext
    support.copy_xxmodule_c(self.tmp_dir)
  File "/usr/local/lib/python3.3/packaging/tests/support.py", line 334, in copy_xxmodule_c
    filename = _get_xxmodule_path()
  File "/usr/local/lib/python3.3/packaging/tests/support.py", line 346, in _get_xxmodule_path
    if os.path.exists(path):
UnboundLocalError: local variable 'path' referenced before assignment

Upon investigation, the code for _get_xxmodule_path is this:

def _get_xxmodule_path():
    if sysconfig.is_python_build():
        srcdir = sysconfig.get_config_var('projectbase')
        path = os.path.join(os.getcwd(), srcdir, 'Modules', 'xxmodule.c')
    else:
        os.path.join(os.path.dirname(__file__), 'xxmodule.c')
    if os.path.exists(path):
        return path

It looks as if the else: path should have a "path = " ... with that change, the test_packaging failures go away.

----------
assignee: tarek
components: Distutils2, Library (Lib)
messages: 153515
nosy: alexis, eric.araujo, tarek, vinay.sajip
priority: normal
severity: normal
status: open
title: Packaging test support code raises exception
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14038>
_______________________________________

From report at bugs.python.org  Fri Feb 17 00:51:44 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 16 Feb 2012 23:51:44 +0000
Subject: [issue14039] Add "metavar" argument to add_subparsers() in argparse
Message-ID: <1329436304.54.0.709137632289.issue14039@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Currently, using add_subparsers() means that the entire list of subcommands is added to the main usage message. This gets rather unwieldy when there are a lot of subcommands.

It would be nice if the add_subparsers() method accepted a "metavar" argument that would be substituted into the usage string instead of using the subparser list directly.

----------
components: Library (Lib)
messages: 153516
nosy: bethard, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add "metavar" argument to add_subparsers() in argparse
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14039>
_______________________________________

From report at bugs.python.org  Fri Feb 17 00:54:58 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 16 Feb 2012 23:54:58 +0000
Subject: [issue14037] Allow grouping of argparse subparser commands in help
	output
In-Reply-To: <1329436005.81.0.273577688528.issue14037@psf.upfronthosting.co.za>
Message-ID: <1329436498.01.0.722690926384.issue14037@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I realised that my initial idea doesn't play nicely with my other suggestion of allowing a "metavar" argument to add_subparsers() (see #14039).

A better model may be to mimic the add_argument_group() directly by offering an add_parser_group() method on the subparser management object.

This would allow ungrouped commands to be presented first, with grouped commands following under their own headings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14037>
_______________________________________

From report at bugs.python.org  Fri Feb 17 01:23:34 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 17 Feb 2012 00:23:34 +0000
Subject: [issue14025] unittest.TestCase.assertEqual does not show diff when
	comparing str with unicode
In-Reply-To: <1329339600.71.0.863718430096.issue14025@psf.upfronthosting.co.za>
Message-ID: <1329438214.0.0.844924574792.issue14025@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If you really want the diff you could use assertMultiLineEqual, but even on Python 2 you shouldn't mix str and unicode.  I would rather fix the code to return unicode than using assertMultilineEqual to get a diff between str and unicode.  Moreover assertMultiLineEqual only works if the str happens to be ASCII-only:

>>> class MyTest(TestCase):
...   def test_foo(self):
...     self.assertMultiLineEqual('b?r', u'b?z')
... 
>>> unittest.main(exit=False)
E
======================================================================
ERROR: test_foo (__main__.MyTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<stdin>", line 3, in test_foo
  File "/home/wolf/dev/py/2.7/Lib/unittest/case.py", line 920, in assertMultiLineEqual
    diff = '\n' + ''.join(difflib.ndiff(firstlines, secondlines))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3: ordinal not in range(128)

----------------------------------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14025>
_______________________________________

From report at bugs.python.org  Fri Feb 17 01:33:19 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 17 Feb 2012 00:33:19 +0000
Subject: [issue14035] behavior of test.support.import_fresh_module
In-Reply-To: <1329428167.53.0.868098431264.issue14035@psf.upfronthosting.co.za>
Message-ID: <1329438799.47.0.164668379123.issue14035@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Keeping reference of fresh modules solves the issue.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file24537/issue14035_fresh_modules.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14035>
_______________________________________

From report at bugs.python.org  Fri Feb 17 02:17:27 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Feb 2012 01:17:27 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1329441447.59.0.272235802397.issue13882@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Patch version 18:
 - Fix a loss of precision in _PyTime_SetDenominator()
 - Add more tests on integer overflow

I also updated the patch adding datetime.datetime support because some people are interested by the type, even I don't think that it is interesting to add it. datetime.datetime is only usable with time.time(), os.*stat() and time.clock_gettime(), whereas it is incompatible with all other functions.

----------
Added file: http://bugs.python.org/file24538/time_decimal-18.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Fri Feb 17 02:18:22 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Feb 2012 01:18:22 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1329441502.67.0.123864032086.issue13882@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file24539/timestamp_datetime-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Fri Feb 17 02:18:35 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Feb 2012 01:18:35 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1329441516.0.0.481665916356.issue13882@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file24505/time_decimal-17.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Fri Feb 17 02:18:37 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Feb 2012 01:18:37 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>
Message-ID: <1329441517.43.0.495264305572.issue13882@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file24414/timestamp_datetime.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Fri Feb 17 02:23:21 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Feb 2012 01:23:21 +0000
Subject: [issue14028] random.choice hits ValueError: cannot convert float NaN
	to integer
In-Reply-To: <1329379073.39.0.519578524869.issue14028@psf.upfronthosting.co.za>
Message-ID: <1329441801.45.0.183826449535.issue14028@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Well, at least it was an interesting bug report ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14028>
_______________________________________

From report at bugs.python.org  Fri Feb 17 02:27:50 2012
From: report at bugs.python.org (zulla)
Date: Fri, 17 Feb 2012 01:27:50 +0000
Subject: [issue14036] urlparse insufficient port property validation
In-Reply-To: <1329435639.39.0.341536822512.issue14036@psf.upfronthosting.co.za>
Message-ID: <1329442070.12.0.305096828675.issue14036@psf.upfronthosting.co.za>


zulla <dan at defendassist.com> added the comment:

The "port" and "netloc" component of a ParsedResult-object is not properly sanitized or validated. This may lead to bypass-able hostname-based filters. Remote Crash vulnerabilities be be also possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14036>
_______________________________________

From report at bugs.python.org  Fri Feb 17 02:45:08 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Feb 2012 01:45:08 +0000
Subject: [issue14036] urlparse insufficient port property validation
In-Reply-To: <1329435639.39.0.341536822512.issue14036@psf.upfronthosting.co.za>
Message-ID: <1329443108.82.0.509324908991.issue14036@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Did you upload urlparse.py to the issue by accident?

Can you please provide some examples of where you think the current code is producing incorrect results?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14036>
_______________________________________

From report at bugs.python.org  Fri Feb 17 02:47:03 2012
From: report at bugs.python.org (zulla)
Date: Fri, 17 Feb 2012 01:47:03 +0000
Subject: [issue14036] urlparse insufficient port property validation
In-Reply-To: <1329435639.39.0.341536822512.issue14036@psf.upfronthosting.co.za>
Message-ID: <1329443223.62.0.551945864627.issue14036@psf.upfronthosting.co.za>


zulla <dan at defendassist.com> added the comment:

Hi. No, it's a patched version. It won't crash under circumstances like that [1] and won't succeed with invalid input:


>>> import urlparse
>>> urlparse.urlparse("http://www.google.com:foo")
ParseResult(scheme='http', netloc='www.google.com:foo', path='', params='', query='', fragment='')
>>> urlparse.urlparse("http://www.google.com:foo").port
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urlparse.py", line 105, in port
    port = int(netloc.split(':')[1], 10)
ValueError: invalid literal for int() with base 10: 'foo'
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14036>
_______________________________________

From report at bugs.python.org  Fri Feb 17 02:54:10 2012
From: report at bugs.python.org (zulla)
Date: Fri, 17 Feb 2012 01:54:10 +0000
Subject: [issue14036] urlparse insufficient port property validation
In-Reply-To: <1329435639.39.0.341536822512.issue14036@psf.upfronthosting.co.za>
Message-ID: <1329443650.69.0.237576405403.issue14036@psf.upfronthosting.co.za>


zulla <dan at defendassist.com> added the comment:

Whops. I forgot an int() :-)

Here's the right patch.

----------
Added file: http://bugs.python.org/file24540/testurllib.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14036>
_______________________________________

From report at bugs.python.org  Fri Feb 17 02:54:33 2012
From: report at bugs.python.org (zulla)
Date: Fri, 17 Feb 2012 01:54:33 +0000
Subject: [issue14036] urlparse insufficient port property validation
In-Reply-To: <1329435639.39.0.341536822512.issue14036@psf.upfronthosting.co.za>
Message-ID: <1329443673.65.0.180723011351.issue14036@psf.upfronthosting.co.za>


Changes by zulla <dan at defendassist.com>:


Removed file: http://bugs.python.org/file24535/urlparse.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14036>
_______________________________________

From report at bugs.python.org  Fri Feb 17 03:05:11 2012
From: report at bugs.python.org (Jason Yeo)
Date: Fri, 17 Feb 2012 02:05:11 +0000
Subject: [issue14026] test_cmd_line_script should include more sys.argv checks
In-Reply-To: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za>
Message-ID: <1329444311.33.0.427205044685.issue14026@psf.upfronthosting.co.za>


Jason Yeo <jasonyeo88 at gmail.com> added the comment:

I would like to work on this but I am not sure how to go about it. It seems that the method signature for _check_script has to be changed in include another parameter for expected_argv1, expected_argv2, etc. The _check_output also has to be changed to include assertIn(printed_argv1, data) for the additional parameters. This also means that test_source has to include some lines to print the sys.argv[1], sys.argv[2], etc. 

Am I on the right track? Or is there a easier way?

(By the way, when I set verbose to a value > 1, errors are found. I realized that a print() statement was printing an undefined variable. I have filed an issue and attached a patch to it. The link for the issue is http://bugs.python.org/issue14032)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14026>
_______________________________________

From report at bugs.python.org  Fri Feb 17 03:05:53 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Feb 2012 02:05:53 +0000
Subject: [issue14036] urlparse insufficient port property validation
In-Reply-To: <1329435639.39.0.341536822512.issue14036@psf.upfronthosting.co.za>
Message-ID: <1329444353.41.0.604190883527.issue14036@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It's not a patch if it is the whole file.  A diff would be much more useful, since then we could see the changes easily.

This kind of change would require a bit of discussion.  I'm doubtful that it would be applied as a bug fix, and we might even want the validation to be optional and not the default.  Part of the issue is that urlparse was originally based on the older standards, as you can see from the docstring.

You may find others to agree with you, but personally it doesn't look to me like this rises to the level of a security issue.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14036>
_______________________________________

From report at bugs.python.org  Fri Feb 17 03:18:55 2012
From: report at bugs.python.org (zulla)
Date: Fri, 17 Feb 2012 02:18:55 +0000
Subject: [issue14036] urlparse insufficient port property validation
In-Reply-To: <1329435639.39.0.341536822512.issue14036@psf.upfronthosting.co.za>
Message-ID: <1329445135.32.0.140118467683.issue14036@psf.upfronthosting.co.za>


zulla <dan at defendassist.com> added the comment:

I understand your point of view, but I disagree.

Various libraries and projects rely on urlparse.urlparse and urllib.parse.urlparse.

This bug just blew up in my face. I'm working with Cython and PyQt4.

When a developer relies on ParseResult().netloc being a valid netloc, and .port being None [bool(False)] or a integer between 1-65535 really bad things can happen in a environment that has 0-tolerance for security issues (like C/C++ mixed in python).

I agree that the 

if self.scheme == "http":
    return 80
elif self.scheme == "https":
    [...]

part of my patch is debetable, but we should _at least_ ensure that IF there is a ParseResult().port, the developer can be sure that it is a valid port between 1-65545.

i apologize for upload the whole file; i attached the diff now.

regards,
dan

----------
keywords: +patch
Added file: http://bugs.python.org/file24541/urlparse.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14036>
_______________________________________

From report at bugs.python.org  Fri Feb 17 04:45:24 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 17 Feb 2012 03:45:24 +0000
Subject: [issue14035] behavior of test.support.import_fresh_module
In-Reply-To: <1329428167.53.0.868098431264.issue14035@psf.upfronthosting.co.za>
Message-ID: <1329450324.01.0.775157062672.issue14035@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Keeping module references implicitly in import_fresh_module will leak references like crazy in the test suite. The onus is on the code referencing module contents to ensure that the module globals remain valid.

If we get rid of the explicit clearing of module globals to break reference cycles, this problem will also go away, so closing as a dupe of #812369.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> module shutdown procedure based on GC

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14035>
_______________________________________

From report at bugs.python.org  Fri Feb 17 04:48:00 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 17 Feb 2012 03:48:00 +0000
Subject: [issue812369] module shutdown procedure based on GC
Message-ID: <1329450480.88.0.996692833632.issue812369@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

In #14035, Florent pointed out the current behaviour potentially causes problems for some uses of import_fresh_modules() in the test suite (with globals sometimes being set to None if there's no indepenent reference to the module).

GC based module cleanup would avoid that problem automatically.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue812369>
_______________________________________

From report at bugs.python.org  Fri Feb 17 05:02:37 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 17 Feb 2012 04:02:37 +0000
Subject: [issue14035] behavior of test.support.import_fresh_module
In-Reply-To: <1329428167.53.0.868098431264.issue14035@psf.upfronthosting.co.za>
Message-ID: <1329451357.33.0.942613065782.issue14035@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Florent, I can reproduce the problem by leaving just the last import_fresh_module in test_fresh_import.py

And your patch fixes it, although as Nick says it's problematic in terms of ref leaks.

What I'm not sure about is why the extra reference is needed. The modules *are* kept in sys.modules, after all.

IIUC, this is probably causing the strange failure I was having with test_xml_etree_c not being able to use the cET_alias global in some tests.

----------
resolution: duplicate -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14035>
_______________________________________

From report at bugs.python.org  Fri Feb 17 05:07:15 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 17 Feb 2012 04:07:15 +0000
Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}"
In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za>
Message-ID: <1329451635.45.0.102000419891.issue13598@psf.upfronthosting.co.za>


Ramchandra Apte <maniandram01 at gmail.com> added the comment:

@Nick I don't understand why should my patch make Formatter thread-unsafe - the auto_field_count and manual variables are local variables just like the variables in the other functions in Formatter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13598>
_______________________________________

From report at bugs.python.org  Fri Feb 17 05:31:20 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 17 Feb 2012 04:31:20 +0000
Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}"
In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za>
Message-ID: <1329453080.31.0.151030892543.issue13598@psf.upfronthosting.co.za>


Ramchandra Apte <maniandram01 at gmail.com> added the comment:

I have submitted a new patch, I have moved the increment to the end of if loop.

----------
Added file: http://bugs.python.org/file24542/issue13598.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13598>
_______________________________________

From report at bugs.python.org  Fri Feb 17 08:45:29 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 17 Feb 2012 07:45:29 +0000
Subject: [issue812369] module shutdown procedure based on GC
Message-ID: <1329464729.67.0.731981466334.issue812369@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue812369>
_______________________________________

From report at bugs.python.org  Fri Feb 17 09:11:37 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 17 Feb 2012 08:11:37 +0000
Subject: [issue14035] behavior of test.support.import_fresh_module
In-Reply-To: <1329428167.53.0.868098431264.issue14035@psf.upfronthosting.co.za>
Message-ID: <1329466297.78.0.0438293027814.issue14035@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file24537/issue14035_fresh_modules.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14035>
_______________________________________

From report at bugs.python.org  Fri Feb 17 09:15:20 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 17 Feb 2012 08:15:20 +0000
Subject: [issue14035] behavior of test.support.import_fresh_module
In-Reply-To: <1329428167.53.0.868098431264.issue14035@psf.upfronthosting.co.za>
Message-ID: <1329466520.37.0.117006134615.issue14035@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I have updated the patch to a simpler form where I copy() sys.modules.
Strangely, I do not detect any refleak running the tests.

I plan to commit this fix, if we don't have leaks in the test suite.

----------
resolution:  -> duplicate
Added file: http://bugs.python.org/file24543/issue14035_fresh_modules.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14035>
_______________________________________

From report at bugs.python.org  Fri Feb 17 09:37:18 2012
From: report at bugs.python.org (Jaap Karssenberg)
Date: Fri, 17 Feb 2012 08:37:18 +0000
Subject: [issue14025] unittest.TestCase.assertEqual does not show diff when
	comparing str with unicode
In-Reply-To: <1329438214.0.0.844924574792.issue14025@psf.upfronthosting.co.za>
Message-ID: <CA+TmwMHoNjQcdQeeQDyeUpVq81bE6vTb0t4F7Mp2n_qsay5TLA@mail.gmail.com>


Jaap Karssenberg <jaap.karssenberg at gmail.com> added the comment:

On Fri, Feb 17, 2012 at 1:23 AM, Ezio Melotti <report at bugs.python.org>wrote:

>
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
>
> If you really want the diff you could use assertMultiLineEqual, but even
> on Python 2 you shouldn't mix str and unicode.  I would rather fix the code
> to return unicode than using assertMultilineEqual to get a diff between str
> and unicode.  Moreover assertMultiLineEqual only works if the str happens
> to be ASCII-only:
>

Yes I'm aware of that. However to my mind there is an inconsistency between
having assertEqual dispatch per type and having to use explicitly
assertMultiLineEqual. If assertMultiLineEqual accepts basestring, I should
be able to register it as such.

More practically I have a large suite of code using assertEqual comparing
mixed str and unicode. This code was written before the diff function was
available (in fact I had a custom diff function in the subclass). As long
as tests are OK this works fine, so I rather not touch them, but if they
fail I don't get the output I need.

Anyway, since I feel there is no consensus on this, I went ahead and
patched assertEqual in my custom subclass and move ahead. I can submit a
formal patch if there is a chance of it being accepted.

Regards,

Jaap

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14025>
_______________________________________

From report at bugs.python.org  Fri Feb 17 11:52:32 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 17 Feb 2012 10:52:32 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1329475952.82.0.82697951808.issue13627@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I'm getting a failure building on Mac OS X Leopard (10.5.8) relating to ECDH:

/Users/vinay/projects/pythonv/Modules/_ssl.c: In function ""PyInit__ssl":
/Users/vinay/projects/pythonv/Modules/_ssl.c:2545: error: "SSL_OP_SINGLE_ECDH_USE" undeclared (first use in this function)

The relevant line

    PyModule_AddIntConstant(m, "OP_SINGLE_ECDH_USE", SSL_OP_SINGLE_ECDH_USE);

isn't bracketed with #ifndef OPENSSL_NO_ECDH/#endif - shouldn't it be?

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Fri Feb 17 11:55:56 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 17 Feb 2012 10:55:56 +0000
Subject: [issue11689] sqlite: Incorrect unit test fails to detect failure
In-Reply-To: <1301178520.82.0.473046584416.issue11689@psf.upfronthosting.co.za>
Message-ID: <1329476156.62.0.0937853438073.issue11689@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

In python 3, declaring the action nonlocal inside the progress function would be more clever :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11689>
_______________________________________

From report at bugs.python.org  Fri Feb 17 11:57:13 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 10:57:13 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1329476233.67.0.71912462544.issue13627@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm getting a failure building on Mac OS X Leopard (10.5.8) relating to ECDH:

Thanks for reporting. It should be fixed in c1a07c8092f7. Can you try?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Fri Feb 17 12:19:57 2012
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 17 Feb 2012 11:19:57 +0000
Subject: [issue12655] Expose sched.h functions
In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za>
Message-ID: <1329477597.96.0.350292942254.issue12655@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/issue12655>
_______________________________________

From report at bugs.python.org  Fri Feb 17 13:13:50 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Feb 2012 12:13:50 +0000
Subject: [issue13882] PEP 410: Use decimal.Decimal type for timestamps
In-Reply-To: <1329441517.47.0.430214523288.issue13882@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwa3ORcjKUR7PRQmYxBG4XarvecFfP+8gSR_RkinAJFPqQ@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

TODO:
 - the conversion from Decimal to _PyTime_t does still use a cast to
float and so lose precision
 - the PEP must be accepted :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Fri Feb 17 13:20:41 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 17 Feb 2012 12:20:41 +0000
Subject: [issue14035] behavior of test.support.import_fresh_module
In-Reply-To: <1329428167.53.0.868098431264.issue14035@psf.upfronthosting.co.za>
Message-ID: <1329481241.11.0.995240423017.issue14035@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

In the case of *dependencies* that get refreshed, no they're *not* kept in sys.modules - they get overwritten by the originals when the sys.modules state gets restored.

The problem almost certainly arises because something, somewhere is doing "from x import y", where y is a function that depends on module globals in 'x'.

If 'x' ever drops out of sys.modules (e.g. because it is a fresh copy only there temporarily during an import), the x.__dict__ will have every attribute set to None and calls to 'y' will fail. (In Florent's original example, it was his "dummy/foo.py" that set of alarm bells and prompted me to look up the reference for the module GC problem).


That's why I'm opposed to touching import_fresh_modules to sweep this problem under the rug - as long as module globals finalisation isn't GC based, keeping a reference to a function in a module without ensuring you also hold a reference to the module itself is always going to be somewhat dubious.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14035>
_______________________________________

From report at bugs.python.org  Fri Feb 17 13:48:16 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 17 Feb 2012 12:48:16 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1329482896.83.0.807607560043.issue13627@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Can you try?

That error goes away, but there are others. Sorry, I missed them in amongst the warnings, or I would have posted all of them. Here's the complete console output for the _ssl extension:

building '_ssl' extension
gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -IInclude -I. -I./Include -I/Users/vinay/projects/pythonv -c /Users/vinay/projects/pythonv/Modules/_ssl.c -o build/temp.macosx-10.5-i386-3.3/Users/vinay/projects/pythonv/Modules/_ssl.o
/Users/vinay/projects/pythonv/Modules/_ssl.c: In function ?_get_peer_alt_names?:
/Users/vinay/projects/pythonv/Modules/_ssl.c:634: warning: passing argument 2 of ?ASN1_item_d2i? from incompatible pointer type
/Users/vinay/projects/pythonv/Modules/_ssl.c:639: warning: passing argument 2 of ?method->d2i? from incompatible pointer type
/Users/vinay/projects/pythonv/Modules/_ssl.c: In function ?PySSL_compression?:
/Users/vinay/projects/pythonv/Modules/_ssl.c:1011: warning: implicit declaration of function ?SSL_get_current_compression?
/Users/vinay/projects/pythonv/Modules/_ssl.c:1011: warning: assignment makes pointer from integer without a cast
/Users/vinay/projects/pythonv/Modules/_ssl.c: In function ?set_ecdh_curve?:
/Users/vinay/projects/pythonv/Modules/_ssl.c:2048: error: ?EC_KEY? undeclared (first use in this function)
/Users/vinay/projects/pythonv/Modules/_ssl.c:2048: error: (Each undeclared identifier is reported only once
/Users/vinay/projects/pythonv/Modules/_ssl.c:2048: error: for each function it appears in.)
/Users/vinay/projects/pythonv/Modules/_ssl.c:2048: error: ?key? undeclared (first use in this function)
/Users/vinay/projects/pythonv/Modules/_ssl.c:2060: warning: implicit declaration of function ?EC_KEY_new_by_curve_name?
/Users/vinay/projects/pythonv/Modules/_ssl.c:2065: warning: implicit declaration of function ?SSL_CTX_set_tmp_ecdh?
/Users/vinay/projects/pythonv/Modules/_ssl.c:2066: warning: implicit declaration of function ?EC_KEY_free?

Failed to build these modules:
_ssl

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Fri Feb 17 13:56:04 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 12:56:04 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1329482896.83.0.807607560043.issue13627@psf.upfronthosting.co.za>
Message-ID: <1329483170.3678.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> That error goes away, but there are others. Sorry, I missed them in
> amongst the warnings, or I would have posted all of them. Here's the
> complete console output for the _ssl extension:

Uh, what is the OpenSSL version there?
Can you try to find out if OPENSSL_NO_ECDH is defined?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Fri Feb 17 14:20:27 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 17 Feb 2012 13:20:27 +0000
Subject: [issue12627] Implement PEP 394: The "python" Command on Unix-Like
	Systems
In-Reply-To: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>
Message-ID: <1329484827.14.0.324002965928.issue12627@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

No automatic link, since I neglected to mention the issue number in the checkin messages:

2.7: http://hg.python.org/cpython/rev/a65a71aa9436
3.3: http://hg.python.org/cpython/rev/dc721f28f168

I deliberately *didn't* make the change in 3.2. As the choice of symlink vs hardlink is really more cosmetic than consequential, it didn't feel like an appropriate change to make in a maintenance release without a compelling reason (introducing a *new* link meant we had such a reason for 2.7, but that's not applicable to 3.2).

Handing the issue over to Ned to confirm the OS X framework builds align with the PEP.

----------
assignee:  -> ned.deily
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12627>
_______________________________________

From report at bugs.python.org  Fri Feb 17 14:36:36 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 13:36:36 +0000
Subject: [issue14040] Deprecate some of the module file formats
Message-ID: <1329485796.8.0.890516593146.issue14040@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Stating module files of the form "xxxmodule.so" consumes all 1/3 of stat calls at startup. Looking at the site-packages folders on my machine, both for 2.7 and 3.2, reveals no C extension that follows such naming.

This patch deprecates such module namings, so that they can be removed in a later version.

----------
components: Interpreter Core, Library (Lib)
files: impsuffix.patch
keywords: patch
messages: 153544
nosy: barry, brett.cannon, dmalcolm, loewis, neologix, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Deprecate some of the module file formats
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file24544/impsuffix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14040>
_______________________________________

From report at bugs.python.org  Fri Feb 17 14:41:43 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 17 Feb 2012 13:41:43 +0000
Subject: [issue14040] Deprecate some of the module file formats
In-Reply-To: <1329485796.8.0.890516593146.issue14040@psf.upfronthosting.co.za>
Message-ID: <1329486103.2.0.108841522222.issue14040@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14040>
_______________________________________

From report at bugs.python.org  Fri Feb 17 14:58:32 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 17 Feb 2012 13:58:32 +0000
Subject: [issue14036] urlparse insufficient port property validation
In-Reply-To: <1329435639.39.0.341536822512.issue14036@psf.upfronthosting.co.za>
Message-ID: <1329487112.86.0.482323675357.issue14036@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Could you provide some failing examples?

The suggestion also seems to run slightly at odds with itself - in one part, silently replacing an invalid port specification with a different value, in another adding additional validation checks.

Also, rather than hardcoding default port numbers for selected protocols, it would make more sense to just look them up via socket.getservbyname(scheme) (and still return None if the scheme isn't recognised). However, I'll need to think about that one for a while - urlparse is designed to be almost purely a string *parsing* library. Looking up default port numbers if one isn't specified really isn't its job. (For one thing, you'd break the ability to exactly recreate the original URL text from the parsed version).

There should definitely by a try/except around that conversion to int(), though - it's just that I'm not yet sure what an appropriate return value is at that point. The raw port string? None? Should there be a separate "raw_port" descriptor that always returns some kind of string, with the port descriptor promising to always return a valid 16-bit port number or None?

----------
nosy: +ncoghlan
versions:  -Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14036>
_______________________________________

From report at bugs.python.org  Fri Feb 17 15:08:06 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Feb 2012 14:08:06 +0000
Subject: [issue14040] Deprecate some of the module file formats
In-Reply-To: <1329485796.8.0.890516593146.issue14040@psf.upfronthosting.co.za>
Message-ID: <1329487686.25.0.265572754334.issue14040@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Patch looks fine, although there aren't any tests. At least for importlib you can simply use a finder test for extension modules to verify the warning is triggered. That way you can create an empty module with the expected naming rather than worry about compiling an extension module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14040>
_______________________________________

From report at bugs.python.org  Fri Feb 17 15:20:53 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Feb 2012 14:20:53 +0000
Subject: [issue13977] importlib simplification
In-Reply-To: <1328810035.88.0.967764974247.issue13977@psf.upfronthosting.co.za>
Message-ID: <1329488453.1.0.18214441798.issue13977@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So I simply swapped out the code and the tests fail. Then I realized why: while the assumption is right, that does not mean that that name passed to __import__() isn't relative and thus shifts what need to be returned (the else clause case). That's why it's a slice off of __name__ based on name itself; name is some funky tail section of __name__ for relative imports.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13977>
_______________________________________

From report at bugs.python.org  Fri Feb 17 15:27:21 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 17 Feb 2012 14:27:21 +0000
Subject: [issue13961] Have importlib use os.replace()
In-Reply-To: <1328624796.15.0.577971130856.issue13961@psf.upfronthosting.co.za>
Message-ID: <E1RyOmN-0005D8-QA@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset de6703671386 by Brett Cannon in branch 'default':
Have importlib use os.replace() for atomic renaming.
http://hg.python.org/cpython/rev/de6703671386

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13961>
_______________________________________

From report at bugs.python.org  Fri Feb 17 15:29:42 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Feb 2012 14:29:42 +0000
Subject: [issue13961] Have importlib use os.replace()
In-Reply-To: <1328624796.15.0.577971130856.issue13961@psf.upfronthosting.co.za>
Message-ID: <1329488982.52.0.751569137364.issue13961@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Thanks for the patch, Charles-Fran?ois!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13961>
_______________________________________

From report at bugs.python.org  Fri Feb 17 15:56:34 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 17 Feb 2012 14:56:34 +0000
Subject: [issue14040] Deprecate some of the module file formats
In-Reply-To: <1329485796.8.0.890516593146.issue14040@psf.upfronthosting.co.za>
Message-ID: <20120217095628.07607ff2@resist.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Feb 17, 2012, at 01:36 PM, Antoine Pitrou wrote:

>Stating module files of the form "xxxmodule.so" consumes all 1/3 of stat
>calls at startup. Looking at the site-packages folders on my machine, both
>for 2.7 and 3.2, reveals no C extension that follows such naming.
>
>This patch deprecates such module namings, so that they can be removed in a
>later version.

+1

In Debian/Ubuntu I have seen some third party extensions (not built with
distutils) that still use this naming convention in their Python 3 extension
module, but it's usually pretty easy to rename them to PEP 3149 style names in
the platform build scripts.  I think it's a great idea to eventually get rid
of the untagged names altogether, and saving some stat calls is added benefit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14040>
_______________________________________

From report at bugs.python.org  Fri Feb 17 15:59:23 2012
From: report at bugs.python.org (Ralf Schmitt)
Date: Fri, 17 Feb 2012 14:59:23 +0000
Subject: [issue14040] Deprecate some of the module file formats
In-Reply-To: <1329485796.8.0.890516593146.issue14040@psf.upfronthosting.co.za>
Message-ID: <1329490763.18.0.877986516489.issue14040@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <python-bugs at systemexit.de>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14040>
_______________________________________

From report at bugs.python.org  Fri Feb 17 16:31:24 2012
From: report at bugs.python.org (totycro)
Date: Fri, 17 Feb 2012 15:31:24 +0000
Subject: [issue14041] bsddb DB_RUNRECOVERY crash on write access
Message-ID: <1329492684.4.0.589795973037.issue14041@psf.upfronthosting.co.za>


New submission from totycro <malli at gmx.at>:

The attached file data.db should be a valid bsddb file, still i get this crash on write:

 File "/usr/lib64/python2.7/bsddb/__init__.py", line 280, in wrapF
    self.db[key] = value
 DBRunRecoveryError: (-30974, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: Invalid argument')

Full traceback: http://pastebin.com/A1VSPV9Q

I can reproduce the crash with python 2.7.2 with just these lines (it doesn't crash on empty db files):


import shelve
a = shelve.open("data.db")

b="crashin.."*20000

a['content/scenarios/tutorial_da.yaml'] = b
a['content/scenarios/tutorial_cs.yaml'] = b

----------
files: data.db
messages: 153551
nosy: totycro
priority: normal
severity: normal
status: open
title: bsddb DB_RUNRECOVERY crash on write access
versions: Python 2.7
Added file: http://bugs.python.org/file24545/data.db

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14041>
_______________________________________

From report at bugs.python.org  Fri Feb 17 16:46:53 2012
From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgQXR0aWxhIFTDs3Ro?=)
Date: Fri, 17 Feb 2012 15:46:53 +0000
Subject: [issue13966] Add disable_interspersed_args() to
	argparse.ArgumentParser
In-Reply-To: <1328687368.18.0.265955669963.issue13966@psf.upfronthosting.co.za>
Message-ID: <1329493613.92.0.687215906171.issue13966@psf.upfronthosting.co.za>


L?szl? Attila T?th <laszlo.attila.toth at gmail.com> added the comment:

I added unit test, which revealed some bugs. These are fixe now.
The attached file contains both the unit tests and the updated patch.

----------
Added file: http://bugs.python.org/file24546/argparse-disable_interspersed.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13966>
_______________________________________

From report at bugs.python.org  Fri Feb 17 16:48:16 2012
From: report at bugs.python.org (=?utf-8?b?5YuH5YiaIOe9lw==?=)
Date: Fri, 17 Feb 2012 15:48:16 +0000
Subject: [issue14033] distutils problem with setup.py build &setup.py install
	vs direct setup.py install
In-Reply-To: <1329410652.02.0.479827647227.issue14033@psf.upfronthosting.co.za>
Message-ID: <1329493696.23.0.534944855224.issue14033@psf.upfronthosting.co.za>


?? ? <luoyonggang at gmail.com> added the comment:

It's my fault, I need to fetch those dlls into source code directory first. Sorry.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14033>
_______________________________________

From report at bugs.python.org  Fri Feb 17 16:51:52 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Feb 2012 15:51:52 +0000
Subject: [issue13991] namespace packages depending on order
In-Reply-To: <1328907203.29.0.677752935093.issue13991@psf.upfronthosting.co.za>
Message-ID: <1329493912.94.0.239926837758.issue13991@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

It's not working because when you import a.b you calculate __path__ at import time, so when you modify sys.path it won't make a difference since import will look at a.__path__ after your a.b import and simply ignore sys.path. But when you put everything on sys.path upfront and use pkgutil to extend __path__ it sees the other 'a' directory and adds it to __path__.

----------
nosy: +brett.cannon
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13991>
_______________________________________

From report at bugs.python.org  Fri Feb 17 16:52:18 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 17 Feb 2012 15:52:18 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1329493938.96.0.0277719098025.issue13627@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

It looks like it's OpenSSL 0.9.7. It's an old machine which I can't change things on - it's got MacPorts OpenSSL which is 1.0.0g, and I thought it was using that. On closer investigation, the version in /usr/include (0.9.7l) is actually being included.

Presumably, even if only an old version of OpenSSL is available, Python should still build cleanly, even if it's without Elliptic Curve cipher support? If you'd like me to try anything else, just ask.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Fri Feb 17 16:53:55 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 17 Feb 2012 15:53:55 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1329494035.69.0.813157260896.issue13627@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Oh - and, ECDH is not matched by any file in that OpenSSL include directory/hierarchy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Fri Feb 17 17:06:32 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Feb 2012 16:06:32 +0000
Subject: [issue14009] Clearer documentation for cElementTree
In-Reply-To: <1329233203.38.0.944311933185.issue14009@psf.upfronthosting.co.za>
Message-ID: <1329494792.81.0.249946872868.issue14009@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> If you want to collect additional feedback, you may want to add some other
> people to the Nosy list :-)
I did not want more feedback, I wanted to leave time for interested parties to find this bug for themselves and eventually comment :)

One question: when I merge the new doc from 3.2 to 3.3, do I remove the new section, as the cET module is now deprecated?  If I do that we?d lose the indexing (i.e. without a module directive there will be no entry in the module index not the alphabetical index).  I could leave the cET section so that we get the indexing but change the text to ?Deprecated alias of ET.?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14009>
_______________________________________

From report at bugs.python.org  Fri Feb 17 17:07:50 2012
From: report at bugs.python.org (Tom Christie)
Date: Fri, 17 Feb 2012 16:07:50 +0000
Subject: [issue14042] json.dumps() documentation is slightly incorrect.
Message-ID: <1329494870.59.0.571991231564.issue14042@psf.upfronthosting.co.za>


New submission from Tom Christie <tom at tomchristie.com>:

json.dumps() documentation is slightly incorrect.

http://docs.python.org/library/json.html#json.dumps

Reads:

  "If ensure_ascii is False, then the return value will be a unicode instance."

Should read:

  "If ensure_ascii is False, then the return value MAY BE be a unicode instance."

(Without the caps of course)

bash: python
Python 2.7.1 (r271:86832, Jun 16 2011, 16:59:05) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import json
>>> type(json.dumps({'a': 1}, ensure_ascii=False))
<type 'str'>

Tested against 2.6 and 2.7.

----------
components: Library (Lib)
messages: 153558
nosy: tomchristie
priority: normal
severity: normal
status: open
title: json.dumps() documentation is slightly incorrect.
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14042>
_______________________________________

From report at bugs.python.org  Fri Feb 17 17:09:44 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 17 Feb 2012 16:09:44 +0000
Subject: [issue14041] bsddb DB_RUNRECOVERY crash on write access
In-Reply-To: <1329492684.4.0.589795973037.issue14041@psf.upfronthosting.co.za>
Message-ID: <1329494984.96.0.660180951941.issue14041@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

The file is corrupted:

"""
jcea at ubuntu:/tmp/z$ /usr/local/BerkeleyDB.5.3/bin/db_verify data.db 
db_verify: BDB0551 Page 0: nonsensical free list pgno 55
db_verify: BDB1107 Page 2: offpage item 19 has bad pgno 70
db_verify: BDB1107 Page 20: offpage item 5 has bad pgno 59
db_verify: BDB1107 Page 36: offpage item 9 has bad pgno 94
db_verify: BDB1107 Page 37: offpage item 9 has bad pgno 57
db_verify: data.db: BDB0090 DB_VERIFY_BAD: Database verification failed
BDB5105 Verification of data.db failed.
"""

For "real world" usage, you must use Berkeley DB transactional storage mode. If you use a concurrent datastore or anything like that (anything more "simple" that the transactional mode), you can corrupt your database if the application or the computer crash in a bad moment. Or if you try to backup the database while writes are in progress, for instance. Briefly: use the transactional mode and read the Oracle documentation carefully!.

Closing the report as invalid, since the database is actually corrupt.

----------
nosy: +jcea
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14041>
_______________________________________

From report at bugs.python.org  Fri Feb 17 17:19:56 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Feb 2012 16:19:56 +0000
Subject: [issue14026] test_cmd_line_script should include more sys.argv checks
In-Reply-To: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za>
Message-ID: <1329495596.36.0.350500367586.issue14026@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> It seems that the method signature for _check_script has to be changed
> in include another parameter for expected_argv1, expected_argv2,
It would seem simpler to me to make that expected_argv.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14026>
_______________________________________

From report at bugs.python.org  Fri Feb 17 17:21:02 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Feb 2012 16:21:02 +0000
Subject: [issue14033] distutils problem with setup.py build &setup.py install
	vs direct setup.py install
In-Reply-To: <1329410652.02.0.479827647227.issue14033@psf.upfronthosting.co.za>
Message-ID: <1329495662.49.0.381126642067.issue14033@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

No problem :)  In the future, please follow two guidelines for reporting distutils bugs:
- test your code with distutils, without setuptools
- state clearly in the message what is the problem

Thanks!

----------
assignee: tarek -> eric.araujo
resolution:  -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14033>
_______________________________________

From report at bugs.python.org  Fri Feb 17 17:22:12 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Feb 2012 16:22:12 +0000
Subject: [issue14026] test_cmd_line_script should include more sys.argv checks
In-Reply-To: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za>
Message-ID: <1329495732.64.0.284631400573.issue14026@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> It seems that the method signature for _check_script has to be changed
> in include another parameter for expected_argv1, expected_argv2,
It would seem simpler to me to make that expected_argv :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14026>
_______________________________________

From report at bugs.python.org  Fri Feb 17 17:23:34 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Feb 2012 16:23:34 +0000
Subject: [issue14032] test_cmd_line_script prints undefined 'data' variable
In-Reply-To: <1329409071.29.0.619315923648.issue14032@psf.upfronthosting.co.za>
Message-ID: <1329495814.26.0.205167217286.issue14032@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14032>
_______________________________________

From report at bugs.python.org  Fri Feb 17 17:29:18 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Feb 2012 16:29:18 +0000
Subject: [issue14020] Improve HTMLParser doc
In-Reply-To: <1329314372.41.0.194033246825.issue14020@psf.upfronthosting.co.za>
Message-ID: <1329496158.58.0.387345882205.issue14020@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It?s all in the Documenting Python doc.

.. class:: HTMLParser()

   Blah blah.

   .. method:: feed(data)

      Do X and Y.

   The following attributes are supported:

   .. attribute:: pos

      etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14020>
_______________________________________

From report at bugs.python.org  Fri Feb 17 17:30:18 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Feb 2012 16:30:18 +0000
Subject: [issue14026] test_cmd_line_script should include more sys.argv checks
In-Reply-To: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za>
Message-ID: <1329496218.83.0.567081892092.issue14026@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg153560

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14026>
_______________________________________

From report at bugs.python.org  Fri Feb 17 17:31:13 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Feb 2012 16:31:13 +0000
Subject: [issue13988] Expose the C implementation of ElementTree by default
	when importing ElementTree
In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>
Message-ID: <1329496273.73.0.244219636862.issue13988@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t see benefits in removing cET.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13988>
_______________________________________

From report at bugs.python.org  Fri Feb 17 17:34:17 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Feb 2012 16:34:17 +0000
Subject: [issue13995] sqlite3 Cursor.rowcount documentation for old sqlite bug
In-Reply-To: <1328991377.3.0.315009784222.issue13995@psf.upfronthosting.co.za>
Message-ID: <1329496457.84.0.58728484163.issue13995@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> With SQLite versions before 3.6.5, :attr:`rowcount` is set to 0 if
> you make a ``DELETE FROM table`` without any condition.

Is there a fixed version of SQLite used by each Python version?  If yes, then I think it could be more useful to talk about the Python version in that paragraph.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13995>
_______________________________________

From report at bugs.python.org  Fri Feb 17 17:38:28 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 16:38:28 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
Message-ID: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch makes importlib's _FileFinder more than 10x faster by keeping a cache of directory entries. It's actually faster than imp.find_module()!

-> imp.find_module:

$ ./python -m timeit -s "import imp" "imp.find_module('logging', None)"
10000 loops, best of 3: 69.9 usec per loop
$ ./python -m timeit -s "import imp" "imp.find_module('bisect', None)"
10000 loops, best of 3: 108 usec per loop

-> unpatched importlib:

$ ./python -m timeit -s "from importlib._bootstrap import _DefaultPathFinder as Finder" "Finder.find_module('logging', None)"
1000 loops, best of 3: 431 usec per loop
$ ./python -m timeit -s "from importlib._bootstrap import _DefaultPathFinder as Finder" "Finder.find_module('bisect', None)"
1000 loops, best of 3: 468 usec per loop

-> patched importlib:

$ ./python -m timeit -s "from importlib._bootstrap import _DefaultPathFinder as Finder" "Finder.find_module('logging', None)"
10000 loops, best of 3: 37.5 usec per loop
$ ./python -m timeit -s "from importlib._bootstrap import _DefaultPathFinder as Finder" "Finder.find_module('bisect', None)"
10000 loops, best of 3: 36.9 usec per loop

----------
components: Interpreter Core, Library (Lib)
files: find_module_cache.patch
keywords: patch
messages: 153566
nosy: brett.cannon, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Speed-up importlib's _FileFinder
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file24547/find_module_cache.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 17:41:26 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Feb 2012 16:41:26 +0000
Subject: [issue9631] Python 2.7 installation issue for Linux gcc-4.1.0-3
	(Fedora Core 5?)
In-Reply-To: <1282108953.92.0.943632360126.issue9631@psf.upfronthosting.co.za>
Message-ID: <1329496886.34.0.129432205192.issue9631@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This was changed by Florent for #8205 (?Remove the "Modules" directory from sys.path when Python is running from the build directory (POSIX only)?).

----------
nosy: +eric.araujo, flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9631>
_______________________________________

From report at bugs.python.org  Fri Feb 17 17:44:57 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 17 Feb 2012 16:44:57 +0000
Subject: [issue14020] Improve HTMLParser doc
In-Reply-To: <1329314372.41.0.194033246825.issue14020@psf.upfronthosting.co.za>
Message-ID: <1329497097.83.0.4761351135.issue14020@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Yes, but there's a section with the example in the middle now, so that doesn't work.  I was thinking about a way to tell sphinx "these are methods of the Foo class", without having them directly indented under the 'class' directive.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14020>
_______________________________________

From report at bugs.python.org  Fri Feb 17 17:52:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Feb 2012 16:52:07 +0000
Subject: [issue14030] Be more careful about selecting the compiler in distutils
In-Reply-To: <1329385035.22.0.0715283153402.issue14030@psf.upfronthosting.co.za>
Message-ID: <1329497527.13.0.453450426758.issue14030@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Could you explain more about what the bug is?

----------
assignee:  -> eric.araujo
components: +Distutils
nosy: +Arfrever, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14030>
_______________________________________

From report at bugs.python.org  Fri Feb 17 17:54:37 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 16:54:37 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329497677.02.0.113376409495.issue14043@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file24547/find_module_cache.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 17:54:44 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 16:54:44 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329497684.67.0.170093050858.issue14043@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file24548/find_module_cache.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 18:03:56 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Feb 2012 17:03:56 +0000
Subject: [issue14034] the example in argparse doc is too complex
In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za>
Message-ID: <1329498236.92.0.161779539641.issue14034@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I really don?t think there was any willingness to ?show off?, and wouldn?t be surprised if the doc was written optparse users.  It?s just an accident of history, and we can try to make it better instead of calling people names :)

Do you have a wording idea for a gentler introduction?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14034>
_______________________________________

From report at bugs.python.org  Fri Feb 17 18:05:59 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 17 Feb 2012 17:05:59 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1329498359.23.0.19226605337.issue13627@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Also, if it's OK for the Elliptic Curve code to be optional in builds, the failure to import OP_SINGLE_ECDH_USE into ssl.py from _ssl should not cause "import ssl" to fail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Fri Feb 17 18:13:53 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 17:13:53 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329498833.99.0.0302723118435.issue14043@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Note that the cost of filling the cache itself isn't trivial:

$ ./python -m timeit -s "import sys; from importlib import _bootstrap" "_bootstrap._file_path_hook('Lib')._fill_cache()"
1000 loops, best of 3: 1.88 msec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 18:14:45 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 17 Feb 2012 17:14:45 +0000
Subject: [issue13974] packaging: test for set_platform()
In-Reply-To: <1328775875.69.0.230962367845.issue13974@psf.upfronthosting.co.za>
Message-ID: <E1RyRON-0007Sx-V1@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b380d715651d by ?ric Araujo in branch 'default':
Add test for packaging.util.set_platform (#13974).
http://hg.python.org/cpython/rev/b380d715651d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13974>
_______________________________________

From report at bugs.python.org  Fri Feb 17 18:14:54 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 17 Feb 2012 17:14:54 +0000
Subject: [issue14038] Packaging test support code raises exception
In-Reply-To: <1329436135.78.0.959753149495.issue14038@psf.upfronthosting.co.za>
Message-ID: <E1RyRON-0007Sx-Uu@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 697e934ade19 by ?ric Araujo in branch 'default':
Fix code I unwittingly broke in b0e2d6592a1f (#14038)
http://hg.python.org/cpython/rev/697e934ade19

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14038>
_______________________________________

From report at bugs.python.org  Fri Feb 17 18:17:05 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 17:17:05 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329499025.95.0.79672643136.issue14043@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated patch with faster cache filling.

----------
Added file: http://bugs.python.org/file24549/find_module_cache2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 18:19:15 2012
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 17 Feb 2012 17:19:15 +0000
Subject: [issue812369] module shutdown procedure based on GC
Message-ID: <1329499155.03.0.0606955045376.issue812369@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

Fwiw, the behavior in PyPy is: don't do anything particular at shut-down, just shut down and quit the process.  No hacking at module globals to replace them with None, but also no guaranteeing that any __del__ method is ever called.  We didn't get a particular bug report about this so far, so it seems to work.

(This is just a report about PyPy's situation; I understand that the situation in CPython is a bit more delicate if CPython is embedded in a larger process.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue812369>
_______________________________________

From report at bugs.python.org  Fri Feb 17 18:19:53 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Feb 2012 17:19:53 +0000
Subject: [issue14020] Improve HTMLParser doc
In-Reply-To: <1329314372.41.0.194033246825.issue14020@psf.upfronthosting.co.za>
Message-ID: <1329499193.38.0.143697397622.issue14020@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Just indent the example, or move it below!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14020>
_______________________________________

From report at bugs.python.org  Fri Feb 17 18:21:06 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Feb 2012 17:21:06 +0000
Subject: [issue13974] packaging: test for set_platform()
In-Reply-To: <1328775875.69.0.230962367845.issue13974@psf.upfronthosting.co.za>
Message-ID: <1329499266.44.0.608540471301.issue13974@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Also committed to d2, will push later.  Thanks!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13974>
_______________________________________

From report at bugs.python.org  Fri Feb 17 18:21:34 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Feb 2012 17:21:34 +0000
Subject: [issue14038] Packaging test support code raises exception
In-Reply-To: <1329436135.78.0.959753149495.issue14038@psf.upfronthosting.co.za>
Message-ID: <1329499294.53.0.884909407095.issue14038@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for catching it.

----------
assignee: tarek -> eric.araujo
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14038>
_______________________________________

From report at bugs.python.org  Fri Feb 17 18:36:17 2012
From: report at bugs.python.org (Alex Quinn)
Date: Fri, 17 Feb 2012 17:36:17 +0000
Subject: [issue14044] IncompleteRead error with urllib2 or urllib.request --
	fine with urllib, wget, or curl
Message-ID: <1329500177.48.0.42118882394.issue14044@psf.upfronthosting.co.za>


New submission from Alex Quinn <aq2009 at alexquinn.org>:

When accessing this URL, both urllib2 (Py2) and urlib.client (Py3) raise an IncompleteRead error.
http://info.kingcounty.gov/health/ehs/foodsafety/inspections/XmlRest.aspx?Zip_Code=98199

Previous discussions about similar errors suggest that this may be due to a problem with the server and chunked data transfer.  (See links below.)  I can't understand what that means.  However, this works fine with urllib (Py2), curl, wget, and all regular web browsers I've tried it with.  Thus, I would have expected urllib2 (Py2) and urllib.request (Py3) to cope with it similarly.

Versions I've tested with:
- Fails with urllib2 + Python 2.5.4, 2.6.1, 2.7.2  (Error messages vary.)
- Fails with urllib.request + Python 3.1.2, 3.2.2
- Succeeds with urllib + Python 2.5.4, 2.6.1, 2.7.2
- Succeeds with wget 1.11.1
- Succeeds with curl 7.15.5

___________________________________________________________
TEST CASES

# FAILS - Python 2.7, 2.6, 2.5
import urllib2
url = "http://info.kingcounty.gov/health/ehs/foodsafety/inspections/XmlRest.aspx?Zip_Code=98199"
xml_str = urllib2.urlopen(url).read() # Raises httplib.IncompleteRead

# FAILS - Python 3.2, 3.1
import urllib.request
url = "http://info.kingcounty.gov/health/ehs/foodsafety/inspections/XmlRest.aspx?Zip_Code=98199"
xml_str = urllib.request.urlopen(url).read() # Raises http.client.IncompleteRead

# SUCCEEDS - Python 2.7, 2.6, 2.5
import urllib
url = "http://info.kingcounty.gov/health/ehs/foodsafety/inspections/XmlRest.aspx?Zip_Code=98199"
xml_str = urllib.urlopen(url).read()
dom = xml.dom.minidom.parseString(xml_str) # Verify XML is complete
print("urllib:  %d bytes received and parsed successfully"%len(xml_str))

# SUCCEEDS - wget
wget -O- "http://info.kingcounty.gov/health/ehs/foodsafety/inspections/XmlRest.aspx?Zip_Code=98199" | wc

# SUCCEEDS - curl - prints an error, but returns the full data anyway
curl "http://info.kingcounty.gov/health/ehs/foodsafety/inspections/XmlRest.aspx?Zip_Code=98199" | wc

___________________________________________________________
RELATED DISCUSSIONS

http://www.gossamer-threads.com/lists/python/python/847985
http://bugs.python.org/issue11463  (closed)
http://bugs.python.org/issue6785   (closed)
http://bugs.python.org/issue6312   (closed)

----------
components: Library (Lib)
messages: 153581
nosy: Alex Quinn
priority: normal
severity: normal
status: open
title: IncompleteRead error with urllib2 or urllib.request -- fine with urllib, wget, or curl
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14044>
_______________________________________

From report at bugs.python.org  Fri Feb 17 18:37:46 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Feb 2012 17:37:46 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329500266.93.0.153239282202.issue14043@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I have not had a chance to deep-dive in the patch, but I just wanted to double-check that this (a) implemented the idea PJE and I discussed on python-dev, and (b) you re-generate the patch as I pushed some changes to importlib today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 18:41:31 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 17:41:31 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329500266.93.0.153239282202.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329500296.3678.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I have not had a chance to deep-dive in the patch, but I just wanted
> to double-check that this (a) implemented the idea PJE and I discussed
> on python-dev

I haven't followed this discussion.

> , and (b) you re-generate the patch as I pushed some changes to
> importlib today.

Will do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 18:36:05 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 17 Feb 2012 17:36:05 +0000
Subject: [issue14034] the example in argparse doc is too complex
In-Reply-To: <1329498236.92.0.161779539641.issue14034@psf.upfronthosting.co.za>
Message-ID: <CAA77j2CzxqMPTff+LqT5FcaHfyZ6kYb2TRyMcRgJKxk4QMLw7Q@mail.gmail.com>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

On Fri, Feb 17, 2012 at 19:03, ?ric Araujo <report at bugs.python.org> wrote:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> I really don?t think there was any willingness to ?show off?, and wouldn?t be surprised if the doc was written optparse users. ?It?s just an accident of history, and we can try to make it better instead of calling people names :)

I did not mean to sound rude. Forgive me.

> Do you have a wording idea for a gentler introduction?

I will work on something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14034>
_______________________________________

From report at bugs.python.org  Fri Feb 17 18:45:38 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 17:45:38 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329500738.63.0.414124698066.issue14043@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Regenerated patch.

----------
Added file: http://bugs.python.org/file24550/find_module_cache3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 18:47:06 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 17 Feb 2012 17:47:06 +0000
Subject: [issue14030] Be more careful about selecting the compiler in distutils
In-Reply-To: <1329385035.22.0.0715283153402.issue14030@psf.upfronthosting.co.za>
Message-ID: <1329500826.61.0.914162446635.issue14030@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

The bug is specific to PyPy. PyPy has no Makefile, so sysconfig.get_config_var("CC") returns None in PyPy. The first paragraph in message #153471 is about a different patch, not this patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14030>
_______________________________________

From report at bugs.python.org  Fri Feb 17 18:51:48 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 17:51:48 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1329501108.72.0.877613746081.issue13627@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, can you try again? 06ed9b3f02af

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Fri Feb 17 18:59:17 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Feb 2012 17:59:17 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329501557.29.0.720554874085.issue14043@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Just to fill you in, the discussion centred on the idea of doing a listdir() of the directory the FileFinder was in charge of watching and caching that. Then, when it had to look up a file all it had to do was stat the directory to look for a change before it simply looked at a frozenset of directory contents. That does away with having to stat for every file type (directory, module, extension, etc.) and replaces it with one upfront listdir() and then a single directory stat per lookup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 19:02:38 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 18:02:38 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329501557.29.0.720554874085.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329501560.3678.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Just to fill you in, the discussion centred on the idea of doing a
> listdir() of the directory the FileFinder was in charge of watching
> and caching that. Then, when it had to look up a file all it had to do
> was stat the directory to look for a change before it simply looked at
> a frozenset of directory contents. That does away with having to stat
> for every file type (directory, module, extension, etc.) and replaces
> it with one upfront listdir() and then a single directory stat per
> lookup.

Ah, then it's basically what my patch does (except that it also computes
all potential module names instead of dumping the os.listdir() result in
a frozenset).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 19:37:30 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 17 Feb 2012 18:37:30 +0000
Subject: [issue14009] Clearer documentation for cElementTree
In-Reply-To: <1329494792.81.0.249946872868.issue14009@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda-ihyxXVtSf0v5MPtYOPNLYwVOFBqANcED8cjeGYnyYPA@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

> > If you want to collect additional feedback, you may want to add some
> other
> > people to the Nosy list :-)
> I did not want more feedback, I wanted to leave time for interested
> parties to find this bug for themselves and eventually comment :)
>
> One question: when I merge the new doc from 3.2 to 3.3, do I remove the
> new section, as the cET module is now deprecated?  If I do that we?d lose
> the indexing (i.e. without a module directive there will be no entry in the
> module index not the alphabetical index).  I could leave the cET section so
> that we get the indexing but change the text to ?Deprecated alias of ET.?
>

I don't see a need for cElementTree to be indexed in the doc of 3.3
Assuming a new Python user who starts with 3.3, he should not even know
about the existence of cElementTree (bar a small notice that says it's
deprecated, which will be of no interest to him). The cElementTree module
stays in its place in 3.3, but that's only for backwards compatibility.
Officially, it doesn't exist :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14009>
_______________________________________

From report at bugs.python.org  Fri Feb 17 19:57:23 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Feb 2012 18:57:23 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329505043.59.0.00908460651778.issue14043@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, I have gone ahead and done a review over on rietveld for the code as-is. But I do have a design question.

Why pre-calculate everything? In the most common case any single module will be imported once, if at all. And once it is imported it will get cached in sys.modules, alleviating the need to hit the finder again. So from a performance standpoint wouldn't it be better not to do all of the pre-calculation and instead do that as needed assuming that sys.modules will shield the finder from having to do repetitive things like figuring out what loader is needed? You will have to do the calculation regardless for the first import, but you might not need to import every module in a directory. Plus if the finder gets its cache invalidated frequently it  will simply be wasting its time.

I'm not going to argue from the perspective that most modules won't get imported as that's purely a stdlib thing; I am willing to bet most projects import nearly all of their modules in each execution.

Otherwise it's good to know three of us now have independently come up with fundamentally the same idea for speeding up imports. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 20:12:31 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 17 Feb 2012 19:12:31 +0000
Subject: [issue13995] sqlite3 Cursor.rowcount documentation for old sqlite bug
In-Reply-To: <1329496457.84.0.58728484163.issue13995@psf.upfronthosting.co.za>
Message-ID: <20120217191227.GA2029@ihaa>


Petri Lehtinen <petri at digip.org> added the comment:

?ric Araujo wrote:
> Is there a fixed version of SQLite used by each Python version? If
> yes, then I think it could be more useful to talk about the Python
> version in that paragraph.

No. In each Python version, setup.py only checks that SQLite is 3.0.8
or newer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13995>
_______________________________________

From report at bugs.python.org  Fri Feb 17 20:31:56 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 19:31:56 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329505043.59.0.00908460651778.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329506921.3678.22.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Why pre-calculate everything? In the most common case any single
> module will be imported once, if at all. And once it is imported it
> will get cached in sys.modules, alleviating the need to hit the finder
> again. So from a performance standpoint wouldn't it be better not to
> do all of the pre-calculation and instead do that as needed assuming
> that sys.modules will shield the finder from having to do repetitive
> things like figuring out what loader is needed?

I figured it would avoid repetitive tests for all 10 suffixes.
That said, I have now tried the alternative: find_module() is around 50%
slower, but building the cache is 10x faster. Perhaps this is a winner.
It would depend on the situation (short or long sys.path, few or many
imports, etc.). Perhaps you can try both patches on your bootstrap repo?

>  Plus if the finder gets its cache invalidated frequently it  will
> simply be wasting its time.

Well, in real-world situations I don't think the cache will ever get
invalidated: because imports are mostly done at startup, and because
invalidating the cache means you are installing new libraries or
updating existing ones while a running program is about to import
something.

> Otherwise it's good to know three of us now have independently come up
> with fundamentally the same idea for speeding up imports. =)

Yup :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 20:32:18 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 19:32:18 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329507138.0.0.825140154148.issue14043@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch with light-weight alternative.

----------
Added file: http://bugs.python.org/file24551/listdir_cache.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 20:47:55 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 17 Feb 2012 19:47:55 +0000
Subject: [issue11689] sqlite: Incorrect unit test fails to detect failure
In-Reply-To: <1301178520.82.0.473046584416.issue11689@psf.upfronthosting.co.za>
Message-ID: <E1RyTmc-0006tT-4a@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset bf7226719aec by Petri Lehtinen in branch '3.2':
Fix a variable scoping error in an sqlite3 test
http://hg.python.org/cpython/rev/bf7226719aec

New changeset ce023c95db9f by Petri Lehtinen in branch '2.7':
Fix a variable scoping error in an sqlite3 test
http://hg.python.org/cpython/rev/ce023c95db9f

New changeset 6b834e3c0882 by Petri Lehtinen in branch 'default':
Merge branch '3.2'
http://hg.python.org/cpython/rev/6b834e3c0882

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11689>
_______________________________________

From report at bugs.python.org  Fri Feb 17 20:50:49 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 17 Feb 2012 19:50:49 +0000
Subject: [issue11689] sqlite: Incorrect unit test fails to detect failure
In-Reply-To: <1301178520.82.0.473046584416.issue11689@psf.upfronthosting.co.za>
Message-ID: <1329508249.62.0.558941914841.issue11689@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Fixed, thanks for the patches!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11689>
_______________________________________

From report at bugs.python.org  Fri Feb 17 21:24:22 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Feb 2012 20:24:22 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329506921.3678.22.camel@localhost.localdomain>
Message-ID: <CAP1=2W5Soph9v775fW+YHRQiD7wETJ8TPCoJMv=1hgt7-Dr0Hg@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Fri, Feb 17, 2012 at 14:31, Antoine Pitrou <report at bugs.python.org>wrote:

>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> > Why pre-calculate everything? In the most common case any single
> > module will be imported once, if at all. And once it is imported it
> > will get cached in sys.modules, alleviating the need to hit the finder
> > again. So from a performance standpoint wouldn't it be better not to
> > do all of the pre-calculation and instead do that as needed assuming
> > that sys.modules will shield the finder from having to do repetitive
> > things like figuring out what loader is needed?
>
> I figured it would avoid repetitive tests for all 10 suffixes.
> That said, I have now tried the alternative: find_module() is around 50%
> slower, but building the cache is 10x faster. Perhaps this is a winner.
>

What is the time increase for find_module() vs. the speed-up of building
the cache? I.e. how many imports are needed before doing the full
calculation is a benefit? And would it make sense to have a hybrid of
caching the contents for fast start-up but then caching full details after
a successful find? That would mean no work is ever simply tossed out and
forgotten.

> It would depend on the situation (short or long sys.path, few or many
> imports, etc.). Perhaps you can try both patches on your bootstrap repo?
>

Yep, that's not hard (and it will only get faster as I replace the bodies
of __import__() and _gcd_import() with C code so that sys.modules is C-fast
again). Question is what to benchmark against? I should probably get the
standard benchmarks up and running and see how those are affected
(especially the start-up ones).

>
> >  Plus if the finder gets its cache invalidated frequently it  will
> > simply be wasting its time.
>
> Well, in real-world situations I don't think the cache will ever get
> invalidated: because imports are mostly done at startup, and because
> invalidating the cache means you are installing new libraries or
> updating existing ones while a running program is about to import
> something.
>

I agree, but it was just something to consider.

>
> > Otherwise it's good to know three of us now have independently come up
> > with fundamentally the same idea for speeding up imports. =)
>
> Yup :)
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue14043>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 21:28:58 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Feb 2012 20:28:58 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329510538.35.0.801977909386.issue14043@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

And while I'm thinking about it, the hybrid caching approach of caching just the directory contents to start and then caching full details on successful searches (and failures) would also let you cache the full file path as the strings will be interned and used again by the loaders for setting __file__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 21:50:32 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 17 Feb 2012 20:50:32 +0000
Subject: [issue14009] Clearer documentation for cElementTree
In-Reply-To: <1329233203.38.0.944311933185.issue14009@psf.upfronthosting.co.za>
Message-ID: <1329511832.34.0.982630162122.issue14009@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Officially, it doesn't exist :)

Keep in mind that many users will find about it from the Internet, and it's better to clearly say what it is and that it shouldn't be used anymore than pretending it doesn't exist.  (AFAIU this is the current situation, since there is a warning, but leaving it indexed wouldn't hurt IMHO.)

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14009>
_______________________________________

From report at bugs.python.org  Fri Feb 17 22:02:34 2012
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 17 Feb 2012 21:02:34 +0000
Subject: [issue14009] Clearer documentation for cElementTree
In-Reply-To: <1329511832.34.0.982630162122.issue14009@psf.upfronthosting.co.za>
Message-ID: <CAFT4OTE1eQQKEbqqR1UmaU_CMML-dXjfeWjb2tQXZTb9uisG5g@mail.gmail.com>


Fred L. Drake, Jr. <fred at fdrake.net> added the comment:

Developers with existing code can reasonably be expected to look it up
based on what they're currently importing, so an entry that points to
the new recommended practice is good.

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14009>
_______________________________________

From report at bugs.python.org  Fri Feb 17 22:41:20 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 21:41:20 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329510538.35.0.801977909386.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329514685.3678.23.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> And while I'm thinking about it, the hybrid caching approach of
> caching just the directory contents to start and then caching full
> details on successful searches (and failures) would also let you cache
> the full file path as the strings will be interned and used again by
> the loaders for setting __file__.

Well, you shouldn't call find_module() on the same module twice (except
for benchmarks), so I'm not sure what caching the results would bring.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 22:48:44 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 21:48:44 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329515324.34.0.580729121126.issue14043@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated light-weight caching patch (now checks PYTHONCASEOK dynamically).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 22:48:51 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 21:48:51 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329515331.8.0.992400429809.issue14043@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file24552/listdir_cache2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 22:49:50 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 17 Feb 2012 21:49:50 +0000
Subject: [issue14026] test_cmd_line_script should include more sys.argv checks
In-Reply-To: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za>
Message-ID: <1329515390.88.0.458139601717.issue14026@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

For the purposes of this test (i.e. running the same script several different ways and making sure it always behaves as expected), I wouldn't even worry about making it configurable.

Just define a list of example args as a module global, append them to the run_args in _check_script, and check them against sys.argv[1:] with assertEqual() in the test script.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14026>
_______________________________________

From report at bugs.python.org  Fri Feb 17 22:52:35 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 17 Feb 2012 21:52:35 +0000
Subject: [issue812369] module shutdown procedure based on GC
Message-ID: <1329515555.96.0.0242439459055.issue812369@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Also, since this issue was last updated, Antoine devised a scheme to test some of the embedding functionality (mainly to test subinterpreters, IIRC). Perhaps that could be harnessed to check GC-based shutdown is working correctly (it might even do it already, without any changes to the test suite).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue812369>
_______________________________________

From report at bugs.python.org  Fri Feb 17 22:52:48 2012
From: report at bugs.python.org (Catalin Iacob)
Date: Fri, 17 Feb 2012 21:52:48 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <1324386392.48.0.968435833624.issue13641@psf.upfronthosting.co.za>
Message-ID: <1329515568.63.0.631090435714.issue13641@psf.upfronthosting.co.za>


Catalin Iacob <iacobcatalin at gmail.com> added the comment:

My current patch allows mixing of bytes and str for the data to be decoded and the altchars or map01 parameter. Given David's observation in msg153505 I'll update the patch to require that both the data and altchars/map01 have the same type.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Fri Feb 17 23:01:41 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Feb 2012 22:01:41 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329516101.92.0.0407315749969.issue14043@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The lastest patch (listdir_cache2) LGTM. Have you by any chance patched it in and run ./python -m importlib.test.regrtest (runs the entire test suite with builtins.__import__() substituted with importlib.__import__())? If not I can do it on my ride home tonight to make sure semantics didn't surprisingly change (I don't see how). And then I can benchmark against the standard benchmark suite to see if it speeds things up in my bootstrap branch.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 23:25:27 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Feb 2012 22:25:27 +0000
Subject: [issue13997] Clearly explain the bare minimum Python 3 users should
	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329517527.26.0.827944331099.issue13997@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree with no new builtin and appreciate that being taken off the table.

I think the place is the Unicode How-to. I think that document should be renamed Encodings and Unicode How-to. The reasons are 1) one has to first understand the concept of encoding characters and text as numbers, and 2) this issue (and the python-ideas discussion) is not about Unicode, but about using pre- (and non-)Unicode encodings with Python3's bytes and string types, and how that differs in Python3 versus using Python2's unicode and string types. If only Unicode encodings were used, with utf-8 dominant on the Internet (and it is now most common for web pages), the problems of concern here would not exist.

Learning about Unicode would mean learning about code units versus codepoints, normal versus surrogate chars, BMP versus extended chars (all of which are non-issues in wide builds and Py 3.3), 256-char planes, BOMs, surrogates, normalization forms, and character properties. While sometimes useful, these subjects are not the issue here.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Fri Feb 17 23:36:32 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 22:36:32 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329516101.92.0.0407315749969.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329517996.3678.26.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The lastest patch (listdir_cache2) LGTM. Have you by any chance
> patched it in and run ./python -m importlib.test.regrtest (runs the
> entire test suite with builtins.__import__() substituted with
> importlib.__import__())?

There are a couple of test failures (in test_import, test_runpy,
test_reprlib). Apparently this is due to false positives when comparing
directory modification times. If I sleep() enough between tests, the
failures disappear...
I wonder if this could be a problem in real-life (say, someone compiling
some DSL to Python code on-the-fly and expecting import to pick up
without any timestamp problems).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 23:46:00 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Feb 2012 22:46:00 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329518760.58.0.93177598256.issue14043@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Well, it's the reason you added file size to .pyc files. =) I assume if you store the system clock as well to see if no time has changed it would kill the performance gain. We could also have two versions of _FileFinder such that people could choose which they preferred.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Fri Feb 17 23:50:36 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 22:50:36 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329518760.58.0.93177598256.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329518841.3678.28.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Well, it's the reason you added file size to .pyc files. =)

pyc files only store the integer timestamp. Here I store the original
floating-point timestamp, and I assumed it would be sufficient :)

>  I assume if you store the system clock as well to see if no time has
> changed it would kill the performance gain.

I don't know. I might give it a try but it might still be fragile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Sat Feb 18 00:02:55 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Feb 2012 23:02:55 +0000
Subject: [issue14003] __self__ on built-in functions is not as documented
In-Reply-To: <1329159935.3.0.264942191971.issue14003@psf.upfronthosting.co.za>
Message-ID: <1329519775.91.0.999301311537.issue14003@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Python-coded functions do not have .__self__.
>>> def f(): pass

>>> f.__self__
...
AttributeError: 'function' object has no attribute '__self__'

Unbound builtin methods, which are simply builtins functions attached to a class, do not have .__self__
>>> list.__len__.__self__
...
AttributeError: 'wrapper_descriptor' object has no attribute '__self__'

So it makes no sense to me that builtin non-method functions should have this attribute.

"Built-in methods 
This is really a different disguise of a built-in function, this time containing an object passed to the C function as an implicit extra argument. An example of a built-in method is alist.append(), assuming alist is a list object. In this case, the special read-only attribute __self__ is set to the object denoted by alist."

should have 'method' replaced with 'instance method' as it is only talking about instance methods, as the term is used in the rest of the section. Or this section should be deleted as it duplicates the previous Instance Method section. Or it should be revised to actually discuss unbound builtin methods.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14003>
_______________________________________

From report at bugs.python.org  Sat Feb 18 01:03:51 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 18 Feb 2012 00:03:51 +0000
Subject: [issue14020] Improve HTMLParser doc
In-Reply-To: <1329314372.41.0.194033246825.issue14020@psf.upfronthosting.co.za>
Message-ID: <E1RyXmI-0006pz-EY@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7052eb923fb8 by Ezio Melotti in branch '2.7':
#14020: improve HTMLParser documentation.
http://hg.python.org/cpython/rev/7052eb923fb8

New changeset 569566cbfd13 by Ezio Melotti in branch '3.2':
#14020: improve HTMLParser documentation.
http://hg.python.org/cpython/rev/569566cbfd13

New changeset 1850f45f6169 by Ezio Melotti in branch 'default':
#14020: merge with 3.2.
http://hg.python.org/cpython/rev/1850f45f6169

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14020>
_______________________________________

From report at bugs.python.org  Sat Feb 18 01:04:13 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Feb 2012 00:04:13 +0000
Subject: [issue14020] Improve HTMLParser doc
In-Reply-To: <1329314372.41.0.194033246825.issue14020@psf.upfronthosting.co.za>
Message-ID: <1329523453.69.0.639758860074.issue14020@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14020>
_______________________________________

From report at bugs.python.org  Sat Feb 18 01:19:12 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Feb 2012 00:19:12 +0000
Subject: [issue13997] Clearly explain the bare minimum Python 3 users should
	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329524352.54.0.762904442945.issue13997@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

FWIW I recently made a talk at PyCon Finland called "Understanding Encodings" that goes through the things you mentioned in the last message.

I could turn that in a patch for the Unicode Howto.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sat Feb 18 01:23:56 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Feb 2012 00:23:56 +0000
Subject: [issue14005] IDLE Crash when running/saving a file
In-Reply-To: <1329173466.12.0.791681771945.issue14005@psf.upfronthosting.co.za>
Message-ID: <1329524636.63.0.893406380516.issue14005@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

With Win7 now, XP previously, I routinely run programs from the IDLE editor window. So do other people, So there is something different on your machine.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14005>
_______________________________________

From report at bugs.python.org  Sat Feb 18 01:45:29 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 18 Feb 2012 00:45:29 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1329525929.53.0.489354380759.issue13627@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Almost there. The file now compiles, but a failure occurs in a later step due to compression functionality being unavailable:

building '_ssl' extension
gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -IInclude -I. -I./Include -I/Users/vinay/projects/pythonv -c /Users/vinay/projects/pythonv/Modules/_ssl.c -o build/temp.macosx-10.5-i386-3.3/Users/vinay/projects/pythonv/Modules/_ssl.o
/Users/vinay/projects/pythonv/Modules/_ssl.c: In function ?_get_peer_alt_names?:
/Users/vinay/projects/pythonv/Modules/_ssl.c:645: warning: passing argument 2 of ?ASN1_item_d2i? from incompatible pointer type
/Users/vinay/projects/pythonv/Modules/_ssl.c:650: warning: passing argument 2 of ?method->d2i? from incompatible pointer type
/Users/vinay/projects/pythonv/Modules/_ssl.c: In function ?PySSL_compression?:
/Users/vinay/projects/pythonv/Modules/_ssl.c:1022: warning: implicit declaration of function ?SSL_get_current_compression?
/Users/vinay/projects/pythonv/Modules/_ssl.c:1022: warning: assignment makes pointer from integer without a cast
gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.5-i386-3.3/Users/vinay/projects/pythonv/Modules/_ssl.o -L/usr/local/lib -lssl -lcrypto -o build/lib.macosx-10.5-i386-3.3/_ssl.so
*** WARNING: renaming "_ssl" since importing it failed: dlopen(build/lib.macosx-10.5-i386-3.3/_ssl.so, 2): Symbol not found: _SSL_get_current_compression
  Referenced from: /Users/vinay/projects/pythonv/build/lib.macosx-10.5-i386-3.3/_ssl.so
  Expected in: dynamic lookup

Failed to build these modules:
_ssl                                                  

It looks as if OPENSSL_NO_COMP needs to be defined in _ssl.c if the OpenSSL version is too old and not already defined. With this change:

#if OPENSSL_VERSION_NUMBER < 0x0090800fL && !defined(OPENSSL_NO_COMP)
# define OPENSSL_NO_COMP
#endif

the ssl library builds without errors. However, test_ssl fails because it still expects OP_SINGLE_ECDH_USE to be defined. With this change in test_constants:

        if ssl.HAS_ECDH:
            ssl.OP_SINGLE_ECDH_USE

all tests pass.

I notice that the test there for OP_NO_COMPRESSION is version-based rather than capability-based, and it might be a good idea to change this too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Sat Feb 18 01:59:15 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 18 Feb 2012 00:59:15 +0000
Subject: [issue14023] bytes implied to be mutable
In-Reply-To: <1329327159.64.0.799949559846.issue14023@psf.upfronthosting.co.za>
Message-ID: <E1RyYdu-0002gM-9o@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 88522997b021 by Terry Jan Reedy in branch '3.2':
Issue 14023 Revert edit to 2.7 version. (I suspect edit is from when we thought
http://hg.python.org/cpython/rev/88522997b021

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14023>
_______________________________________

From report at bugs.python.org  Sat Feb 18 02:00:58 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Feb 2012 01:00:58 +0000
Subject: [issue14023] bytes implied to be mutable
In-Reply-To: <1329327159.64.0.799949559846.issue14023@psf.upfronthosting.co.za>
Message-ID: <1329526858.43.0.245840232111.issue14023@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

applied to 3.3 also

----------
assignee: docs at python -> terry.reedy
nosy: +terry.reedy
resolution:  -> fixed
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14023>
_______________________________________

From report at bugs.python.org  Sat Feb 18 02:07:32 2012
From: report at bugs.python.org (Matt Joiner)
Date: Sat, 18 Feb 2012 01:07:32 +0000
Subject: [issue14003] __self__ on built-in functions is not as documented
In-Reply-To: <1329159935.3.0.264942191971.issue14003@psf.upfronthosting.co.za>
Message-ID: <1329527252.72.0.101588351889.issue14003@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/issue14003>
_______________________________________

From report at bugs.python.org  Sat Feb 18 02:11:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Feb 2012 01:11:07 +0000
Subject: [issue13999] Queue references in multiprocessing doc points to Queue
	module and not to self
In-Reply-To: <1329072364.23.0.444581618774.issue13999@psf.upfronthosting.co.za>
Message-ID: <1329527467.35.0.990784621304.issue13999@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

:class:`~multiprocessing.Queue` should probably be used.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13999>
_______________________________________

From report at bugs.python.org  Sat Feb 18 02:14:44 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Feb 2012 01:14:44 +0000
Subject: [issue13948] rm needless use of set function
In-Reply-To: <1328516888.02.0.726524948471.issue13948@psf.upfronthosting.co.za>
Message-ID: <1329527684.2.0.820938528408.issue13948@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Using a set is actually needed: list membership testing does not use hashes (but probably equality), whereas set and dict membership tests does uses hashes.

(I wrote a class with an __hash__ method that prints something when called, and ?test() in []? does not print anything, whereas ?test() in set()? does.  So test_hash now uses a set again, and I added a comment to clarify why.)

----------
resolution: duplicate -> invalid
superseder: Get rid of doctests in packaging.tests.test_version -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13948>
_______________________________________

From report at bugs.python.org  Sat Feb 18 02:18:36 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Feb 2012 01:18:36 +0000
Subject: [issue7694] DeprecationWarnings in distutils are pointless
In-Reply-To: <1263401319.23.0.932890994142.issue7694@psf.upfronthosting.co.za>
Message-ID: <1329527916.77.0.0581272130269.issue7694@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Due to the feature freeze of distutils and official upgrade path to distutils2, I think the DeprecationWarnings in distutils should just be removed, as they serve no useful purpose.

----------
keywords:  -easy, patch
title: DeprecationWarning from build_ext needs stacklevel -> DeprecationWarnings in distutils are pointless
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7694>
_______________________________________

From report at bugs.python.org  Sat Feb 18 02:22:22 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Feb 2012 01:22:22 +0000
Subject: [issue14003] __self__ on built-in functions is not as documented
In-Reply-To: <1329159935.3.0.264942191971.issue14003@psf.upfronthosting.co.za>
Message-ID: <1329528142.01.0.300393335617.issue14003@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think that functions in C modules are implemented as methods of module objects, which would explain why len.__self__ is builtins.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14003>
_______________________________________

From report at bugs.python.org  Sat Feb 18 02:27:56 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Feb 2012 01:27:56 +0000
Subject: [issue14044] IncompleteRead error with urllib2 or urllib.request --
	fine with urllib, wget, or curl
In-Reply-To: <1329500177.48.0.42118882394.issue14044@psf.upfronthosting.co.za>
Message-ID: <1329528476.44.0.459482765236.issue14044@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14044>
_______________________________________

From report at bugs.python.org  Sat Feb 18 02:33:14 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Feb 2012 01:33:14 +0000
Subject: [issue14042] json.dumps() documentation is slightly incorrect.
In-Reply-To: <1329494870.59.0.571991231564.issue14042@psf.upfronthosting.co.za>
Message-ID: <1329528794.54.0.924203513739.issue14042@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Entry for dump says
"If ensure_ascii is False (default: True), then some chunks written to fp may be unicode instances,"
Entry for dumps says
"If ensure_ascii is False, then the return value will be a unicode instance."
Entry for JSONEncoder says
"If ensure_ascii is True (the default), the output is guaranteed to be str objects with all incoming unicode characters escaped. If ensure_ascii is False, the output will be a unicode object."

I suspect the latter two meant to say something like
"If ensure_ascii is False and any chunk would be unicode, then the whole output is unicode."

And should 'all incoming unicode characters' either be or include 'all non-ascii chars (as in 3.x)?

---
In 3.x, ensure_ascii apparently has a different meaning.
"If ensure_ascii is True (the default), the output is guaranteed to have all incoming non-ASCII characters escaped. If ensure_ascii is False, these characters will be output as-is."

Unlike other params used in multiple json functions, ensure_ascii is only defined once, under json.JSONEncoder and not under dump and dumps. Should the JSONEncoder entry to copied to dump and dumps?

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, ezio.melotti, rhettinger, terry.reedy
stage:  -> needs patch
versions: +Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14042>
_______________________________________

From report at bugs.python.org  Sat Feb 18 02:45:22 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Feb 2012 01:45:22 +0000
Subject: [issue13193] packaging.tests.test_manifest and
	distutils.tests.test_filelist failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1329529522.27.0.847201707675.issue13193@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FYI, the last commit was actually incorrect.  I must confess that I wanted to fix the buildbots as quick as possible, especially in light of the upcoming-though-undated 2.7 release, and did not read the code as carefully as I should have, but now I have done it and am much more confident about what is the correct behavior.  Interested parties can follow #6884.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Sat Feb 18 02:46:26 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Feb 2012 01:46:26 +0000
Subject: [issue11751] Increase distutils.filelist / packaging.manifest test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1329529586.74.0.042155701465.issue11751@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It was actually already known: #6884 (and then found again: #14004).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11751>
_______________________________________

From report at bugs.python.org  Sat Feb 18 02:49:16 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Feb 2012 01:49:16 +0000
Subject: [issue14004] Distutils filelist selects too many files on Windows
In-Reply-To: <1329166628.27.0.616152401371.issue14004@psf.upfronthosting.co.za>
Message-ID: <1329529756.95.0.988638556387.issue14004@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This regex bug was actually already known.  Please follow up on the other report.

> As an aside, it seems that the failing test from issue 13193 was
> actually correct, and that the library itself was broken.
Yes.  filelist operates in this way: it builds a list of all files in a tree (creating allfiles, which thus uses native path separators), then edits this list according to the MANIFEST.in commands (where the patterns must be transformed to a regex that uses native separators).  So the test was right in using os.path.join, and the regex was not right to always use '/'.

----------
resolution:  -> duplicate
stage: test needed -> committed/rejected
status: open -> closed
superseder:  -> Impossible to include file in sdist that starts with 'build' on Win32

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14004>
_______________________________________

From report at bugs.python.org  Sat Feb 18 03:01:53 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 18 Feb 2012 02:01:53 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1329530513.1.0.457749327576.issue6884@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sat Feb 18 03:03:06 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Feb 2012 02:03:06 +0000
Subject: [issue14030] Be more careful about selecting the compiler in distutils
In-Reply-To: <1329385035.22.0.0715283153402.issue14030@psf.upfronthosting.co.za>
Message-ID: <1329530586.67.0.157393833314.issue14030@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> PyPy has no Makefile, so sysconfig.get_config_var("CC") returns None in PyPy.
Do you think the stdlib sysconfig could be changed to make this call return something meaningful, or should the code use another method to find the compiler to use?

(Getting config vars for 'SO' is one of the (surprisingly few) issues I?ve found when trying to run distutils2 tests with PyPy, I?d love to fix it.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14030>
_______________________________________

From report at bugs.python.org  Sat Feb 18 03:04:22 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Feb 2012 02:04:22 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1329530662.78.0.745722753254.issue6884@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can someone test this patch on Windows?

----------
nosy: +jason.coombs
Added file: http://bugs.python.org/file24553/filelist-regex-bug.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sat Feb 18 03:25:45 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 18 Feb 2012 02:25:45 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1329531945.12.0.861905929884.issue6884@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

With the patch applied, the problem from issue 14004 still occurs. There
is also a failure in test_distutils, but I'm not sure whether that's just
the test itself needing to be updated.

Anyway, it's late for me now; I'll give it a more detailed look tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sat Feb 18 03:39:06 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Feb 2012 02:39:06 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1329532746.58.0.266849429149.issue6884@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Could you post the test output (and the output of DISTUTILS_DEBUG=1 ./python.exe setup.py sdist if you have it)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sat Feb 18 04:13:38 2012
From: report at bugs.python.org (py.user)
Date: Sat, 18 Feb 2012 03:13:38 +0000
Subject: [issue14045] In regex pattern long unicode character isn't recognized
	by repetition characters +, * and {}
Message-ID: <1329534818.23.0.573239991753.issue14045@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

>>> import re
>>> '\U00000061'
'a'
>>> '\U00100061'
'\U00100061'
>>> re.search('\U00100061', '\U00100061' * 10).group()
'\U00100061'
>>> re.search('\U00100061+', '\U00100061' * 10).group()
'\U00100061'
>>> re.search('(\U00100061)+', '\U00100061' * 10).group()
'\U00100061\U00100061\U00100061\U00100061\U00100061\U00100061\U00100061\U00100061\U00100061\U00100061'
>>> 
>>>
>>> re.search('\U00100061{3}', '\U00100061' * 10)
>>> re.search('(\U00100061){3}', '\U00100061' * 10).group()
'\U00100061\U00100061\U00100061'
>>>

----------
components: Library (Lib), Regular Expressions
messages: 153629
nosy: ezio.melotti, py.user
priority: normal
severity: normal
status: open
title: In regex pattern long unicode character isn't recognized by repetition characters +, * and {}
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14045>
_______________________________________

From report at bugs.python.org  Sat Feb 18 04:26:19 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 18 Feb 2012 03:26:19 +0000
Subject: [issue14045] In regex pattern long unicode character isn't recognized
	by repetition characters +, * and {}
In-Reply-To: <1329534818.23.0.573239991753.issue14045@psf.upfronthosting.co.za>
Message-ID: <1329535579.95.0.647903758346.issue14045@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

The re module doesn't support non-BMP characters in Python 3.2 compiled in narrow mode (sys.maxunicode==65535). This issue is already fixed in Python 3.3 which doesn't have narrow or wide mode anymore thanks to the PEP 393!

----------
nosy: +haypo, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14045>
_______________________________________

From report at bugs.python.org  Sat Feb 18 04:47:28 2012
From: report at bugs.python.org (Eric Snow)
Date: Sat, 18 Feb 2012 03:47:28 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329536848.33.0.501387666052.issue14043@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Sat Feb 18 04:53:35 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 18 Feb 2012 03:53:35 +0000
Subject: [issue14045] In regex pattern long unicode character isn't recognized
	by repetition characters +, * and {}
In-Reply-To: <1329534818.23.0.573239991753.issue14045@psf.upfronthosting.co.za>
Message-ID: <1329537215.96.0.613220367512.issue14045@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As Victor says, this issue is fixed in Python 3.3.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14045>
_______________________________________

From report at bugs.python.org  Sat Feb 18 06:21:49 2012
From: report at bugs.python.org (Mansour)
Date: Sat, 18 Feb 2012 05:21:49 +0000
Subject: [issue14046] argparse: assertion failure if optional argument has
	square/round brackets in metavar
Message-ID: <1329542509.5.0.84021889574.issue14046@psf.upfronthosting.co.za>


New submission from Mansour <mansour at oxplot.com>:

I have a web server written in python which takes an optional argument telling it what IP and port to bind to. Here's the definition:

parser.add_argument(
  '-b', '--bind',
  metavar="[ip]:port",
  type=unicode,
  help="IP and port to bind to."
)

There are several other arguments as well. When the usage is printed (due to parse failures or -h), if the command line is longer than terminal width, it is wrapped. Here is the (relevant) code in argparse.py:311 which deals with this scenario:

# wrap the usage parts if it's too long
text_width = self._width - self._current_indent 
if len(prefix) + len(usage) > text_width: 
 
  # break usage into wrappable parts 
  part_regexp = r'\(.*?\)+|\[.*?\]+|\S+' 
  opt_usage = format(optionals, groups) 
  pos_usage = format(positionals, groups) 
  opt_parts = _re.findall(part_regexp, opt_usage) 
  pos_parts = _re.findall(part_regexp, pos_usage) 
  assert ' '.join(opt_parts) == opt_usage
  assert ' '.join(pos_parts) == pos_usage

Note how part_regexp extracts words, and text surrounded with round/square brackets. Now the argument I defined above, when displayed in usage text, looks like this: [-b [ip]:port]

part_regexp however, will cut it into "[-b [ip]" and ":port]" and concatenated later with " ", it will have an extra space which causes the first assertion to fail.

I fiddled with part_regexp but that proved unreliable at best. I think the opt_parts should be obtained, not from the final formatted text, but from actual argument objects.

For a demonstration, see the attachment.

----------
components: Library (Lib)
files: argparse_wrap_test.py
messages: 153632
nosy: oxplot
priority: normal
severity: normal
status: open
title: argparse: assertion failure if optional argument has square/round brackets in metavar
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file24554/argparse_wrap_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14046>
_______________________________________

From report at bugs.python.org  Sat Feb 18 06:28:16 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Feb 2012 05:28:16 +0000
Subject: [issue14027] distutils2 lack of pysetup.bat
In-Reply-To: <1329373939.69.0.162264279004.issue14027@psf.upfronthosting.co.za>
Message-ID: <1329542896.05.0.515617891127.issue14027@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi, and thanks for your interest in improving distutils2.

I am not a Windows user, much less developer, so I have many questions about your proposed pysetup.bat:
- Will ?@%~dp0\..\python.exe? get the proper path for people who do not install Python to C:\?
- Aren?t there issues with .bat scripts (or maybe it?s with .com scripts, I never remember)?
- Shouldn?t we install a pysetup.py script instead?
- Shouldn?t we generate an .exe file instead (see #12394)?

In other words, I need more info from Windows experts about what works best for Python developers :)

----------
nosy: +brian.curtin, pmoore, tim.golden, vinay.sajip
versions: +3rd party -Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14027>
_______________________________________

From report at bugs.python.org  Sat Feb 18 08:23:28 2012
From: report at bugs.python.org (Michal Sladek)
Date: Sat, 18 Feb 2012 07:23:28 +0000
Subject: [issue14047] UTF-8 Email Header
Message-ID: <1329549808.72.0.457462714436.issue14047@psf.upfronthosting.co.za>


New submission from Michal Sladek <michal at sladkovi.eu>:

Hello!

I am not a programmer so I appologize if I just don't understand the docs properly. I need to wirte a function which sends emails with utf-8 encoded subject and body. I tried something like this:

def sendMail (fromAddr, toAddr, subject, body = '', attachment = ''):
    message = email.mime.multipart.MIMEMultipart()
    message.add_header('From',fromAddr)
    message.add_header('To',toAddr)
    message['Subject'] = email.header.Header(subject,'utf-8')
    if (body != ''):
        msgPart = email.mime.text.MIMEText(body,'plain','utf-8')
        message.attach(msgPart)
    if (attachment != ''):
        if os.path.exists(attachment) == True:
            filename = attachment.rpartition(os.sep)[2]
            fp = open(attachment,'rb')
            msgPart = email.mime.base.MIMEBase('application','octet-stream')
            msgPart.set_payload(fp.read())
            fp.close()
            email.encoders.encode_base64(msgPart)
            msgPart.add_header('Content-Disposition','attachment',filename=filename)
            message.attach(msgPart)
    if smtpPort == 25:
        smtpCon = smtplib.SMTP(smtpSrv,smtpPort)
    else:
        smtpCon = smtplib.SMTP_SSL(smtpSrv,smtpPort)
    if (smtpUser != '') and (smtpPass != ''):
        smtpCon.login(smtpUser,smtpPass)
    smtpCon.send_message(message,mail_options=['UTF8SMTP','8BITMIME'])
    logger.info (_('Sent mail to: {0} with subject: {1}').format(toAddr,subject))
    smtpCon.quit()

I realized that adding email subject this way somehow brokes the message, so that the plain text body of the message is not visible on receiving side. I had to chnage the code like this:

    base64Subject = base64.b64encode(subject.encode('utf-8')).decode()
    encodedSubject = '=?UTF-8?B?{0}?='.format(base64Subject)
    message.add_header('Subject',encodedSubject)

Am I doing something wrong?

----------
messages: 153634
nosy: msladek
priority: normal
severity: normal
status: open
title: UTF-8 Email Header
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14047>
_______________________________________

From report at bugs.python.org  Sat Feb 18 10:00:50 2012
From: report at bugs.python.org (Scott Bannert)
Date: Sat, 18 Feb 2012 09:00:50 +0000
Subject: [issue14048] calendar bug related to September 2-14, 1752
Message-ID: <1329555650.42.0.80388367005.issue14048@psf.upfronthosting.co.za>


New submission from Scott Bannert <bannerts at gmail.com>:

Note: this is my first time to submit a bug or use this system

I might have found an issue with the calendar related to the point of time in history when the date was necessary to correct by 11 days.  Anyhow, the correction is made in a GNU+linux machine, so it seems like something worth fixing in python.  

How I discovered it:
I was reading through some posts on reddit when I came up on this one:
http://www.reddit.com/r/linux/comments/9jl2t/1_open_a_linux_terminal_2_enter_cal_9_1752_3_shit/
which seemed to state that in the September of 1752, they decided to skip from Wednesday the 2nd to Thursday the 14th.  Out of curiosity, I decided to see if Python had it recorded this way by typing in the following commands in python:

>>> import calendar
>>> calendar.TextCalendar().pryear(1752)

It was not corrected for the two versions of python I tried using (2.7 and 3.2).

----------
messages: 153635
nosy: bannerts
priority: normal
severity: normal
status: open
title: calendar bug related to September 2-14, 1752
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14048>
_______________________________________

From report at bugs.python.org  Sat Feb 18 10:47:43 2012
From: report at bugs.python.org (=?utf-8?q?Daniel_Neuh=C3=A4user?=)
Date: Sat, 18 Feb 2012 09:47:43 +0000
Subject: [issue9253] argparse: optional subparsers
In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za>
Message-ID: <1329558463.91.0.361509164875.issue9253@psf.upfronthosting.co.za>


Changes by Daniel Neuh?user <dasdasich at googlemail.com>:


----------
nosy: +DasIch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9253>
_______________________________________

From report at bugs.python.org  Sat Feb 18 11:00:03 2012
From: report at bugs.python.org (Paul Moore)
Date: Sat, 18 Feb 2012 10:00:03 +0000
Subject: [issue14027] distutils2 lack of pysetup.bat
In-Reply-To: <1329542896.05.0.515617891127.issue14027@psf.upfronthosting.co.za>
Message-ID: <CACac1F9nXHvY+P+v-cs=HiG=VrVKanJNAwpkLbiyvHh8ba-MSg@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

> - Will ?@%~dp0\..\python.exe? get the proper path for people who do not install Python to C:\?

%~dp0\..\python.exe locates python relative to the batch file (one
directory up) so will work as long as the bat file is in Scripts. The
@ just suppresses echo of the command.

> - Aren?t there issues with .bat scripts (or maybe it?s with .com scripts, I never remember)?

Yes. They don't nest, so to invoke pysetup in a batch file, you need
to write "call pysetup.bat". If you just use "pysetup", the command
never returns causing silent failures. Personally, I hate bat files
for this reason alone, but others seem happy to put up with them.

> - Shouldn?t we install a pysetup.py script instead?

That would be better, in my view.

> - Shouldn?t we generate an .exe file instead (see #12394)?

exe files probably give the best user experience, but are opaque which
is mildly annoying. Also, test very carefully on Win7. I have a vague
recollection that exes with setup and/or install in the names invoke
UAC, which is a complete pain. easy_install suffers from this, I
believe.

> In other words, I need more info from Windows experts about what works best for Python developers :)

Personally, "python -m packaging.run" works fine for me. I'd prefer
not to have a pysetup command at all, and change the documentation to
refer to the python -m form throughout. Second best would be an exe,
third would be pysetup.py (but again, the docs need changing), and
finally a bat file.

Another option would be a runnable pysetup module, so that python -m
pysetup (or maybe an install.py so python -m install) would work.
Paul.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14027>
_______________________________________

From report at bugs.python.org  Sat Feb 18 11:12:44 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Feb 2012 10:12:44 +0000
Subject: [issue13866] {urllib,
	urllib.parse}.urlencode should not use quote_plus
In-Reply-To: <1327529522.13.0.464287316871.issue13866@psf.upfronthosting.co.za>
Message-ID: <1329559964.02.0.649869235888.issue13866@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/issue13866>
_______________________________________

From report at bugs.python.org  Sat Feb 18 11:33:34 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 18 Feb 2012 10:33:34 +0000
Subject: [issue14048] calendar bug related to September 2-14, 1752
In-Reply-To: <1329555650.42.0.80388367005.issue14048@psf.upfronthosting.co.za>
Message-ID: <1329561214.09.0.478442952563.issue14048@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is documented behaviour:  see

http://docs.python.org/library/calendar.html

"""Most of these functions and classes rely on the datetime module which uses an idealized calendar, the current Gregorian calendar indefinitely extended in both directions. This matches the definition of the ?proleptic Gregorian? calendar in Dershowitz and Reingold?s book ?Calendrical Calculations?, where it?s the base calendar for all computations."""

Also note that things get messy if you try to correct this:  the 1752 correction that you refer to applies mainly to the British calendar, and it would be a little rude to impose that correction on Python users worldwide :-)  For other countries there are various adoption dates for the Gregorian calendar, and various corresponding corrections (e.g., Greece dropping 13 days in 1923).

No idea how GNU/Linux handles this;  what happens when you try 'cal 1923' on a machine with Greek locale settings?

So at best this is a feature request, but as a feature request it would need either significant discussion (the python-ideas list may be a good place for this), or at least an explicit suggestion of exactly how things should be changed.  Closing as invalid for now.

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14048>
_______________________________________

From report at bugs.python.org  Sat Feb 18 11:39:50 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Feb 2012 10:39:50 +0000
Subject: [issue13999] Queue references in multiprocessing doc points to Queue
	module and not to self
In-Reply-To: <1329072364.23.0.444581618774.issue13999@psf.upfronthosting.co.za>
Message-ID: <1329561590.29.0.296783888519.issue13999@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +ezio.melotti
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13999>
_______________________________________

From report at bugs.python.org  Sat Feb 18 11:41:37 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Feb 2012 10:41:37 +0000
Subject: [issue14003] __self__ on built-in functions is not as documented
In-Reply-To: <1329159935.3.0.264942191971.issue14003@psf.upfronthosting.co.za>
Message-ID: <1329561697.56.0.204977448481.issue14003@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/issue14003>
_______________________________________

From report at bugs.python.org  Sat Feb 18 11:44:35 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Feb 2012 10:44:35 +0000
Subject: [issue14034] the example in argparse doc is too complex
In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za>
Message-ID: <1329561875.57.0.541080785133.issue14034@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14034>
_______________________________________

From report at bugs.python.org  Sat Feb 18 11:48:24 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Feb 2012 10:48:24 +0000
Subject: [issue14042] json.dumps() documentation is slightly incorrect.
In-Reply-To: <1329494870.59.0.571991231564.issue14042@psf.upfronthosting.co.za>
Message-ID: <1329562104.33.0.318713488793.issue14042@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See #13770 and #13769.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14042>
_______________________________________

From report at bugs.python.org  Sat Feb 18 12:39:45 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 18 Feb 2012 11:39:45 +0000
Subject: [issue14027] distutils2 lack of pysetup.bat
In-Reply-To: <1329373939.69.0.162264279004.issue14027@psf.upfronthosting.co.za>
Message-ID: <1329565185.5.0.0481936626104.issue14027@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Also, we normally set ".py", and ".pyw" into the PATHEXT environment variable, so that a script "pysetup.py" can be invoked from the command-line as just "pysetup" without the suffix. This gives the same experience as using a "pysetup.bat".

I would say that pysetup seems a little more polished (and shorter) than the -m form, especially for users new to packaging. After that, I agree with Paul's ordering of .exe, with the setup script having to be named pysetup-script.py if we use the "standard" mechanism, or else if we use a custom .exe, it can of course be called whatever we want.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14027>
_______________________________________

From report at bugs.python.org  Sat Feb 18 12:56:29 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 18 Feb 2012 11:56:29 +0000
Subject: [issue13978] OSError exception in multiprocessing module when using
	os.remove() on NFS
In-Reply-To: <1328811848.71.0.527301304196.issue13978@psf.upfronthosting.co.za>
Message-ID: <1329566189.93.0.921379594118.issue13978@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I'm closing, since the manager should be shutdown (and TMPDIR on NFS isn't a good idea).

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13978>
_______________________________________

From report at bugs.python.org  Sat Feb 18 13:10:57 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Sat, 18 Feb 2012 12:10:57 +0000
Subject: [issue13579] string.Formatter doesn't understand the !a conversion
	specifier
In-Reply-To: <1323587450.48.0.625379374057.issue13579@psf.upfronthosting.co.za>
Message-ID: <1329567057.92.0.757840371062.issue13579@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

Updated. The NEWS line is now at the top of the section.

>As near as I can tell, the two change block beginning with 
>+In less formal terms,
>[...]
>are strictly re-wrapping and no text changes. Correct?

Yes. Just a pydev question here: I now this re-wrapping
adds noise to the patch, but can/should be done?

Please correct me if I'm wrong: one should try to
limit the line width to 80. If one word starts before
and ends behind is not bad but new words should start
in a new line.

Now in the devguide states ?To perform a quick sanity check on your path, you can run make patchcheck?

I did that (I'm using the mq approach here) but I get no useful information (AFAIN):
-----------------------------------------------
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
Usually, copying Modules/Setup.dist to Modules/Setup will work.
-----------------------------------------------
./python ./Tools/scripts/patchcheck.py
Getting the list of files that have been added/changed ... 0 files
Fixing whitespace ... 0 files
Fixing C file whitespace ... 0 files
Fixing docs whitespace ... 0 files
Docs modified ... NO
Misc/ACKS updated ... NO
Misc/NEWS updated ... NO


Thanks in advance !

----------
Added file: http://bugs.python.org/file24555/issue13579_47288880cc9e.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13579>
_______________________________________

From report at bugs.python.org  Sat Feb 18 13:22:58 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 18 Feb 2012 12:22:58 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1329567778.63.0.141318553169.issue11051@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

As noted by Antoine somewhere else (don't remember if it was on the bug tracker or mailing list), most of the startup time is due to site import:

"""
cf at neobox:~/python/cpython$ time ./python -c ''
[44249 refs]

real    0m0.445s
user    0m0.376s
sys     0m0.032s
cf at neobox:~/python/cpython$ time ./python -S -c ''
[35211 refs]

real    0m0.181s
user    0m0.144s
sys     0m0.016s
"""

And that's mostly user time, the stat() calls don't weight much here.

Here's the output of a profiling:
"""

   Ordered by: cumulative time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
      2/1    0.006    0.003    0.303    0.303 {built-in method exec}
        1    0.004    0.004    0.303    0.303 test_startup.py:1(<module>)
        1    0.000    0.000    0.267    0.267 site.py:509(main)
        1    0.000    0.000    0.237    0.237 site.py:254(addusersitepackages)
        1    0.000    0.000    0.236    0.236 site.py:231(getusersitepackages)
        1    0.006    0.006    0.226    0.226 site.py:217(getuserbase)
        1    0.011    0.011    0.214    0.214 sysconfig.py:1(<module>)
        1    0.004    0.004    0.122    0.122 configparser.py:120(<module>)
       30    0.006    0.000    0.120    0.004 {built-in method __build_class__}
        9    0.000    0.000    0.116    0.013 re.py:204(compile)
        9    0.002    0.000    0.116    0.013 functools.py:185(wrapper)
        9    0.000    0.000    0.113    0.013 re.py:256(_compile)
        9    0.001    0.000    0.113    0.013 sre_compile.py:488(compile)
        1    0.001    0.001    0.096    0.096 configparser.py:555(RawConfigParser)
"""

On my (somewhat old) laptop, sysconfig import consumes 1/3 of the 
total startup time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11051>
_______________________________________

From report at bugs.python.org  Sat Feb 18 13:59:58 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 18 Feb 2012 12:59:58 +0000
Subject: [issue14049] execfile() fails on files that use global variables
	inside functions
Message-ID: <1329569998.87.0.931536345344.issue14049@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

main.py below fails to execute local.py, which work ok (outputs '2') when processed directly in console.

Docs are not explaining anything. They spread fear and uncertainty around locals, but nothing is said why globals may fail.
http://docs.python.org/library/functions.html#execfile


---[cut main.py]---
values = {}
glavues = {}
execfile('local.py', glavues, values)
---[/cut]-----------

---[cut local.py]---
x = 1
def weird():
    y = x + 1
    return y
print weird()
---[/cut]-----------



Traceback (most recent call last):
  File "main.py", line 5, in <module>
    execfile('local.py', glavues, values)
  File "local.py", line 7, in <module>
    print weird()
  File "local.py", line 5, in weird
    y = x + 1
NameError: global name 'x' is not defined

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 153643
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: execfile() fails on files that use global variables inside functions
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14049>
_______________________________________

From report at bugs.python.org  Sat Feb 18 15:03:12 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 18 Feb 2012 14:03:12 +0000
Subject: [issue14001] CVE-2012-0845 Python v2.7.2 / v3.2.2
	(SimpleXMLRPCServer): DoS (excessive CPU usage) by processing
	malformed XMLRPC / HTTP POST request
In-Reply-To: <1329140734.41.0.0376676358855.issue14001@psf.upfronthosting.co.za>
Message-ID: <E1RyksY-0002iy-I8@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 24244a744d01 by Charles-Fran?ois Natali in branch '2.6':
Issue #14001: CVE-2012-0845: xmlrpc: Fix an endless loop in SimpleXMLRPCServer
http://hg.python.org/cpython/rev/24244a744d01

New changeset 0c02f30b2538 by Charles-Fran?ois Natali in branch '2.7':
Issue #14001: CVE-2012-0845: xmlrpc: Fix an endless loop in SimpleXMLRPCServer
http://hg.python.org/cpython/rev/0c02f30b2538

New changeset 4dd5a94fd3e3 by Charles-Fran?ois Natali in branch '3.1':
Issue #14001: CVE-2012-0845: xmlrpc: Fix an endless loop in SimpleXMLRPCServer
http://hg.python.org/cpython/rev/4dd5a94fd3e3

New changeset cd67740ce653 by Charles-Fran?ois Natali in branch '3.2':
Issue #14001: CVE-2012-0845: xmlrpc: Fix an endless loop in SimpleXMLRPCServer
http://hg.python.org/cpython/rev/cd67740ce653

New changeset 5756b295b6fb by Charles-Fran?ois Natali in branch 'default':
Issue #14001: CVE-2012-0845: xmlrpc: Fix an endless loop in SimpleXMLRPCServer
http://hg.python.org/cpython/rev/5756b295b6fb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14001>
_______________________________________

From report at bugs.python.org  Sat Feb 18 15:58:56 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 18 Feb 2012 14:58:56 +0000
Subject: [issue13997] Clearly explain the bare minimum Python 3 users should
	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329577136.92.0.644653115348.issue13997@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The other thing that came out of the rambling Unicode thread on python-ideas is that we should clearly articulate the options for processing files in a task-based fashion and describe the trade-offs for the different alternatives.

I started writing up my notes on that as a tracker comment, but the became a little... long: http://readthedocs.org/docs/ncoghlan_devs-python-notes/en/latest/py3k_text_file_processing.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sat Feb 18 16:21:08 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 18 Feb 2012 15:21:08 +0000
Subject: [issue13579] string.Formatter doesn't understand the !a conversion
	specifier
In-Reply-To: <1329567057.92.0.757840371062.issue13579@psf.upfronthosting.co.za>
Message-ID: <CADiSq7f90to2gCbTV+frKzQ1TU=hxRBhXFY5TUrrAhe7_D23bg@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

On Sat, Feb 18, 2012 at 10:10 PM, Francisco Mart?n Brugu?
<report at bugs.python.org> wrote:
> ./python ./Tools/scripts/patchcheck.py
> Getting the list of files that have been added/changed ... 0 files
> Fixing whitespace ... 0 files
> Fixing C file whitespace ... 0 files
> Fixing docs whitespace ... 0 files
> Docs modified ... NO
> Misc/ACKS updated ... NO
> Misc/NEWS updated ... NO

I suspect mq will confuse make patchcheck (since it looks for
differences between the working copy and the hg branch tip, and there
are no such differences for an applied mq patch).

Cheers,
Nick.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13579>
_______________________________________

From report at bugs.python.org  Sat Feb 18 17:05:37 2012
From: report at bugs.python.org (Jason Yeo)
Date: Sat, 18 Feb 2012 16:05:37 +0000
Subject: [issue14026] test_cmd_line_script should include more sys.argv checks
In-Reply-To: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za>
Message-ID: <1329581137.92.0.300631457012.issue14026@psf.upfronthosting.co.za>


Jason Yeo <jasonyeo88 at gmail.com> added the comment:

>Just define a list of example args as a module global, append them to 
>the run_args in _check_script, and check them against sys.argv[1:] with 
>assertEqual() in the test script.

Okay I have done that but the assertion passes in all the tests except in test_issue8202 and test_issue8202_dash_m_file_ignored. It seems that the script didn't receive any arguments from the cmd line from the way it is executed in these functions. 

I have attached a patch to let you see what I am doing. Let me know if I am wrong. Thanks.

----------
Added file: http://bugs.python.org/file24556/14026patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14026>
_______________________________________

From report at bugs.python.org  Sat Feb 18 17:55:20 2012
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sat, 18 Feb 2012 16:55:20 +0000
Subject: [issue14012] Misc tarfile fixes
In-Reply-To: <1329235837.42.0.144867770777.issue14012@psf.upfronthosting.co.za>
Message-ID: <1329584120.55.0.229693704055.issue14012@psf.upfronthosting.co.za>


Changes by Lars Gust?bel <lars at gustaebel.de>:


----------
assignee:  -> lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14012>
_______________________________________

From report at bugs.python.org  Sat Feb 18 17:58:49 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 18 Feb 2012 16:58:49 +0000
Subject: [issue14050] Tutorial, list.sort() and items comparability
Message-ID: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

I'm providing patches for what reported at http://mail.python.org/pipermail/docs/2012-February/007481.html . I'm not sure on wording or even if we want them in the tutorial section, but I think it would be nice to have it documented nonetheless.

----------
assignee: docs at python
components: Documentation
files: list_sort-py27.diff
keywords: patch
messages: 153648
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Tutorial, list.sort() and items comparability
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24557/list_sort-py27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14050>
_______________________________________

From report at bugs.python.org  Sat Feb 18 17:58:56 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 18 Feb 2012 16:58:56 +0000
Subject: [issue14050] Tutorial, list.sort() and items comparability
In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za>
Message-ID: <1329584336.49.0.784881896985.issue14050@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


Added file: http://bugs.python.org/file24558/list_sort-py32.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14050>
_______________________________________

From report at bugs.python.org  Sat Feb 18 18:45:29 2012
From: report at bugs.python.org (Alex Gaynor)
Date: Sat, 18 Feb 2012 17:45:29 +0000
Subject: [issue14051] Cannot set attributes on staticmethod
Message-ID: <1329587129.39.0.150393564133.issue14051@psf.upfronthosting.co.za>


New submission from Alex Gaynor <alex.gaynor at gmail.com>:

This is inconsistant with regular functions, which unfortunately prevents them from being used interchangeably.

----------
messages: 153649
nosy: alex
priority: normal
severity: normal
status: open
title: Cannot set attributes on staticmethod

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14051>
_______________________________________

From report at bugs.python.org  Sat Feb 18 19:10:04 2012
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sat, 18 Feb 2012 18:10:04 +0000
Subject: [issue14013] tarfile should expose supported formats
In-Reply-To: <1329236847.51.0.270430673151.issue14013@psf.upfronthosting.co.za>
Message-ID: <1329588604.33.0.900412148835.issue14013@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I think this is a reasonable proposal. I think it is good style to let tarfile figure out which supported compression methods are available instead of shutil or the user. So far I have no objections.

Following 3.3's crypt module, I think the name `methods' is superior to `formats' (maybe `compression_methods' is even better). Also, crypt's concept of a sorted list from stronger to weaker could also make sense here: ["xz", "bz2", "gz"]. Why not?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14013>
_______________________________________

From report at bugs.python.org  Sat Feb 18 19:12:49 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Feb 2012 18:12:49 +0000
Subject: [issue14040] Deprecate some of the module file formats
In-Reply-To: <1329485796.8.0.890516593146.issue14040@psf.upfronthosting.co.za>
Message-ID: <1329588769.57.0.202214863325.issue14040@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch with tests.

----------
Added file: http://bugs.python.org/file24559/impsuffix2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14040>
_______________________________________

From report at bugs.python.org  Sat Feb 18 19:23:28 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 18 Feb 2012 18:23:28 +0000
Subject: [issue14040] Deprecate some of the module file formats
In-Reply-To: <1329485796.8.0.890516593146.issue14040@psf.upfronthosting.co.za>
Message-ID: <1329589408.82.0.397741766634.issue14040@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

In this case, I propose to drop the feature without deprecation. It is very easy to adjust the build process of packages that still use the feature, and even end users can rename the files.

If you want to improve ease-of-use, you could still do the stat calls, and record whether a file would have been imported. If then the import fails, put a message into the import error saying the /some/where/somemodule.so was ignored because the file name is no longer supported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14040>
_______________________________________

From report at bugs.python.org  Sat Feb 18 19:25:45 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 18 Feb 2012 18:25:45 +0000
Subject: [issue14051] Cannot set attributes on staticmethod
In-Reply-To: <1329587129.39.0.150393564133.issue14051@psf.upfronthosting.co.za>
Message-ID: <1329589545.22.0.064506830521.issue14051@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/issue14051>
_______________________________________

From report at bugs.python.org  Sat Feb 18 19:28:37 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 18 Feb 2012 18:28:37 +0000
Subject: [issue14040] Deprecate some of the module file formats
In-Reply-To: <1329485796.8.0.890516593146.issue14040@psf.upfronthosting.co.za>
Message-ID: <1329589717.1.0.866899712874.issue14040@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/issue14040>
_______________________________________

From report at bugs.python.org  Sat Feb 18 19:37:28 2012
From: report at bugs.python.org (Eric Snow)
Date: Sat, 18 Feb 2012 18:37:28 +0000
Subject: [issue14040] Deprecate some of the module file formats
In-Reply-To: <1329485796.8.0.890516593146.issue14040@psf.upfronthosting.co.za>
Message-ID: <1329590248.85.0.0497878735573.issue14040@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14040>
_______________________________________

From report at bugs.python.org  Sat Feb 18 19:42:05 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 18 Feb 2012 18:42:05 +0000
Subject: [issue14003] __self__ on built-in functions is not as documented
In-Reply-To: <1329159935.3.0.264942191971.issue14003@psf.upfronthosting.co.za>
Message-ID: <1329590525.21.0.952188223696.issue14003@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/issue14003>
_______________________________________

From report at bugs.python.org  Sat Feb 18 20:42:43 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Feb 2012 19:42:43 +0000
Subject: [issue13997] Clearly explain the bare minimum Python 3 users should
	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1329594163.37.0.00436649168239.issue13997@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Yes, the 'how to' alternatives, with + and -, should be included in the doc addition. I thought it the best thing to come out of the python-ideas thread.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13997>
_______________________________________

From report at bugs.python.org  Sat Feb 18 20:50:27 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Feb 2012 19:50:27 +0000
Subject: [issue14051] Cannot set attributes on staticmethod
In-Reply-To: <1329587129.39.0.150393564133.issue14051@psf.upfronthosting.co.za>
Message-ID: <1329594627.77.0.587168117738.issue14051@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Interpreter Core
nosy: +benjamin.peterson
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14051>
_______________________________________

From report at bugs.python.org  Sat Feb 18 20:51:39 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Feb 2012 19:51:39 +0000
Subject: [issue14026] test_cmd_line_script should include more sys.argv checks
In-Reply-To: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za>
Message-ID: <1329594699.13.0.208914322826.issue14026@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t understand why you import the module inside the same module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14026>
_______________________________________

From report at bugs.python.org  Sat Feb 18 20:55:44 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Feb 2012 19:55:44 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329594944.36.0.891225760095.issue14043@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Another possibility would be to include an explicit invalidate_caches() function in importlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Sat Feb 18 21:38:47 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Feb 2012 20:38:47 +0000
Subject: [issue14052] importlib mixes up '.' and os.getcwd()
Message-ID: <1329597527.35.0.680600221226.issue14052@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

An empty sys.path string means the current directory in relative terms:

$ touch foo.py
$ python3 -c "import foo; print(foo.__file__)"
foo.py


But importlib uses os.getcwd() instead in PathFinder._path_importer_cache(). This impacts semantics of path searching, as well as the values of __file__ and __cached__ attributes.

----------
assignee: brett.cannon
components: Library (Lib)
messages: 153656
nosy: brett.cannon, pitrou
priority: normal
severity: normal
status: open
title: importlib mixes up '.' and os.getcwd()
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14052>
_______________________________________

From report at bugs.python.org  Sat Feb 18 21:50:06 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 18 Feb 2012 20:50:06 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1329598206.78.0.647918833181.issue6884@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Test output:

    test test_distutils failed -- Traceback (most recent call last):
      File "C:\Users\Nadeem\Code\python2\python27\lib\distutils\tests\test_filelist.py", line 230, in test_process_template
        self.assertEqual(file_list.files, ['d/b.py', 'd/d/e.py'])
    AssertionError: Lists differ: [] != ['d/b.py', 'd/d/e.py']

    Second list contains 2 additional elements.
    First extra element 0:
    d/b.py

    - []
    + ['d/b.py', 'd/d/e.py']

Output of sdist:

    C:\Users\Nadeem\Code\keyring>..\python2\python27\PCbuild\python_d setup.py sdist

    C:\Users\Nadeem\Code\python2\python27\lib\distutils\dist.py:267: UserWarning: Unknown distribution option: 'extras_require'
      warnings.warn(msg)
    options (after parsing config files):
    options (after parsing command line):
    option dict for 'sdist' command:
      {}
    running sdist
    Distribution.get_command_obj(): creating 'sdist' command object
    running check
    Distribution.get_command_obj(): creating 'check' command object
    Distribution.get_command_obj(): creating 'build_py' command object
    Distribution.get_command_obj(): creating 'build' command object
    reading manifest template 'MANIFEST.in'
[... output omitted - applying other regexes ...]
    include *.txt
    include_pattern: applying regex r'^[^/]*\.txt\Z(?ms)'
     adding CHANGES.txt
     adding CONTRIBUTORS.txt
     adding .hg\last-message.txt
    exclude_pattern: applying regex r'^build\\.*'
    exclude_pattern: applying regex r'^keyring\-0\.8\\.*'
    exclude_pattern: applying regex r'(^|/|\\)(RCS|CVS|\.svn|\.hg|\.git|\.bzr|_darcs)(/|\\).*'
     removing .hg\last-message.txt
    writing manifest file 'MANIFEST'
[... output omitted - creating directories; copying and adding files ...]
    removing 'keyring-0.8' (and everything under it)

As you can see, the "include *.txt" directive still catches ".hg\last-message.txt".

The problem seems to be that while you've fixed the prefix-handling codepath in
translate_pattern(), glob_to_re() is still hardcoded to use "/". I've been able to
get the desired behavior by changing glob_to_re() as follows (note the need to
double-escape os.sep):

         # character except the special characters.
         # XXX currently the "special characters" are just slash -- i.e. this is
         # Unix-only.
    -    pattern_re = re.sub(r'((?<!\\)(\\\\)*)\.', r'\1[^/]', pattern_re)
    +    pattern_re = re.sub(r'((?<!\\)(\\\\)*)\.',
    +                        r'\1[^' + re.escape(re.escape(os.sep)) + ']',
    +                        pattern_re)
    
         return pattern_re

Of course, the comment above should also be updated.

Also, this change results in a different set of test breakages:

    ======================================================================
    FAIL: test_glob_to_re (distutils.tests.test_filelist.FileListTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "C:\Users\Nadeem\Code\python2\python27\lib\distutils\tests\test_filelist.py", line 42, in test_glob_to_re
        self.assertEqual(glob_to_re('foo*'), 'foo[^/]*\\Z(?ms)')
    AssertionError: 'foo[^\\\\]*\\Z(?ms)' != 'foo[^/]*\\Z(?ms)'

    ======================================================================
    FAIL: test_process_template (distutils.tests.test_filelist.FileListTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "C:\Users\Nadeem\Code\python2\python27\lib\distutils\tests\test_filelist.py", line 182, in test_process_template
        self.assertEqual(file_list.files, ['a.py'])
    AssertionError: Lists differ: ['a.py', 'd/c.py'] != ['a.py']

    First list contains 1 additional elements.
    First extra element 1:
    d/c.py

    - ['a.py', 'd/c.py']
    + ['a.py']

These are both clearly due to the tests using hardcoded Unix paths instead
of os.sep and os.path.join().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sat Feb 18 21:52:53 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Feb 2012 20:52:53 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329598373.33.0.755212957091.issue14043@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is a patch demonstrating invalidate_caches().
As for test_runpy, it seems runpy uses imp.get_loader(), so I don't see how it can remain synchronized with importlib's state.

----------
Added file: http://bugs.python.org/file24560/listdir_cache3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Sat Feb 18 22:42:26 2012
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 18 Feb 2012 21:42:26 +0000
Subject: [issue14051] Cannot set attributes on staticmethod
In-Reply-To: <1329587129.39.0.150393564133.issue14051@psf.upfronthosting.co.za>
Message-ID: <1329601346.27.0.776497679967.issue14051@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/issue14051>
_______________________________________

From report at bugs.python.org  Sun Feb 19 00:37:08 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Sat, 18 Feb 2012 23:37:08 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2 and
	python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1329608228.22.0.131066835216.issue6784@psf.upfronthosting.co.za>


Merlijn van Deen <valhallasw at gmail.com> added the comment:

Any news on this?

Just as a note, pickletools.py also does not reflect the current behaviour; pickle types STRING, BINSTRING and SHORT_BINSTRING are all defined with stack_after=[pystring]:

[1, line 992]
    I(name='STRING',
      code='S',
      arg=stringnl,
      stack_before=[],
      stack_after=[pystring],
      proto=0,
      doc=(...)
     )

although the doc=... does describe it will be decoded, the object type of pystring is still defined as bytes:

[1, line 747]
pystring = StackObject(
               name='string',
               obtype=bytes,
               doc="A Python (8-bit) string object.")


[1] http://hg.python.org/cpython/file/98df29d51e12/Lib/pickletools.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Sun Feb 19 00:42:21 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 18 Feb 2012 23:42:21 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329608541.42.0.592859963379.issue14043@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I wouldn't worry too much about test_runpy as it has always been a touchy test for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Sun Feb 19 01:16:05 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 19 Feb 2012 00:16:05 +0000
Subject: [issue14026] test_cmd_line_script should include more sys.argv checks
In-Reply-To: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za>
Message-ID: <1329610565.71.0.112690538513.issue14026@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The second instance is inside the source code string that's written out as the script to be run in the subprocess. Not a bad idea actually:
- it avoids writing the example args twice (which is what I was thinking of doing)
- it avoids turning the test_script into a string formatting template (which is something I've been trying to avoid for that test)
- it provides an additional sanity check on how sys.path is being initialised in the subprocess

For the two failures, I suggest modifying _check_script() to return the "rc, out, err" from the underlying assert_python_ok() call, then updating the two offending tests to call _check_script() appropriately instead of calling assert_python_ok() directly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14026>
_______________________________________

From report at bugs.python.org  Sun Feb 19 01:52:26 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 19 Feb 2012 00:52:26 +0000
Subject: [issue14040] Deprecate some of the module file formats
In-Reply-To: <1329485796.8.0.890516593146.issue14040@psf.upfronthosting.co.za>
Message-ID: <1329612746.69.0.435270008289.issue14040@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I like Martin's suggestion of simply throwing an error. But then again I also really like his idea of simply not warning since it's easier. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14040>
_______________________________________

From report at bugs.python.org  Sun Feb 19 01:55:28 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 19 Feb 2012 00:55:28 +0000
Subject: [issue14052] importlib mixes up '.' and os.getcwd()
In-Reply-To: <1329597527.35.0.680600221226.issue14052@psf.upfronthosting.co.za>
Message-ID: <1329612928.1.0.375975119287.issue14052@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

It's surprisingly difficult to get right because tests will fail if you keep the path relative in other situations (such as test_cmd_line_script). It was an absolute pain to get it to where it is now. If you can make it keep the relative path and pass the test then that's great, but relative file paths suck for compatibility and I don't think they are that useful to begin with.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14052>
_______________________________________

From report at bugs.python.org  Sun Feb 19 02:21:01 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 19 Feb 2012 01:21:01 +0000
Subject: [issue12627] Implement PEP 394: The "python" Command on Unix-Like
	Systems
In-Reply-To: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>
Message-ID: <E1RyvST-00082V-VO@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 499796937b7a by Ned Deily in branch '2.7':
Issue #12627: Implement PEP 394 for OS X framework builds.
http://hg.python.org/cpython/rev/499796937b7a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12627>
_______________________________________

From report at bugs.python.org  Sun Feb 19 03:03:18 2012
From: report at bugs.python.org (Ned Deily)
Date: Sun, 19 Feb 2012 02:03:18 +0000
Subject: [issue12627] Implement PEP 394: The "python" Command on Unix-Like
	Systems
In-Reply-To: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>
Message-ID: <1329616998.55.0.119032594362.issue12627@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Changeset 499796937b7a implements PEP 394 for OS X framework builds on Python 2.7.  OS X framework builds already created versioned symlinks for all executables and scripts installed in the framework bin directory, of the general form ${cmd} - ${cmd}2.7.  This is all accomplished in some additional targets in Mac/Makefile which are automatically added by configure for framework builds and supersede the standard processing in the main Makefile bininstall and altbininstall targets.  The changes here add the additional hierarchy of ${cmd} -> ${cmd}2 -> ${cmd}2.7.  Per previous practice, all of the links are created in the framework bin directory for both the install and altinstall targets.  This is consistent with the long-standing recommendation to manage multiple framework versions by adding and ordering framework bin directories on $PATH.  Also, per past practice, symlinks to all framework bin entries are created in $prefix/bin (by default, /usr/local/bin) for the install target and only versioned links are created for altinstall, although the use of these links is not recommended for framework builds and their installation is optional with the standard OS X installers.

No changes are needed for 3.2 or 3.3 at this time.  Although the Mac/Makefile targets don't quite create all of the versioned links in $prefix/bin, the installer build script does the right thing by creating symlinks to everything in the fw bin directory.

In many respects, the current situation for framework builds is less than ideal, with duplicated code, vestigial links, and, more importantly, a clumsy and non-transparent method for managing multiple versions.  I intend to revisit this area prior to Python 3.3 feature code cutoff as a separate issue.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12627>
_______________________________________

From report at bugs.python.org  Sun Feb 19 03:52:35 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 19 Feb 2012 02:52:35 +0000
Subject: [issue13500] Hitting EOF gets cmd.py into a infinite EOF on return
	loop
In-Reply-To: <1322578601.01.0.207872314852.issue13500@psf.upfronthosting.co.za>
Message-ID: <E1Rywt5-0005wR-FX@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5af5e6b2c053 by Jesus Cea in branch 'default':
Test for issue #13500
http://hg.python.org/cpython/rev/5af5e6b2c053

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13500>
_______________________________________

From report at bugs.python.org  Sun Feb 19 03:55:11 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 19 Feb 2012 02:55:11 +0000
Subject: [issue13500] Hitting EOF gets cmd.py into a infinite EOF on return
	loop
In-Reply-To: <1322578601.01.0.207872314852.issue13500@psf.upfronthosting.co.za>
Message-ID: <E1Rywvc-00069Q-Ip@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0d442e166c8f by Jesus Cea in branch '2.7':
Test for issue #13500
http://hg.python.org/cpython/rev/0d442e166c8f

New changeset 3a40af30449e by Jesus Cea in branch '3.2':
Test for issue #13500
http://hg.python.org/cpython/rev/3a40af30449e

New changeset ad204ed6ac51 by Jesus Cea in branch 'default':
MERGE: Test for issue #13500
http://hg.python.org/cpython/rev/ad204ed6ac51

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13500>
_______________________________________

From report at bugs.python.org  Sun Feb 19 04:21:28 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 19 Feb 2012 03:21:28 +0000
Subject: [issue13500] Hitting EOF gets cmd.py into a infinite EOF on return
	loop
In-Reply-To: <1322578601.01.0.207872314852.issue13500@psf.upfronthosting.co.za>
Message-ID: <E1RyxL5-0000Ay-F5@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2909e60e7e13 by Jesus Cea in branch '2.7':
Fix Test for issue #13500
http://hg.python.org/cpython/rev/2909e60e7e13

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13500>
_______________________________________

From report at bugs.python.org  Sun Feb 19 05:16:27 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 19 Feb 2012 04:16:27 +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: <1329624987.97.0.476176870809.issue7475@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/issue7475>
_______________________________________

From report at bugs.python.org  Sun Feb 19 05:30:50 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 19 Feb 2012 04:30:50 +0000
Subject: [issue14030] Be more careful about selecting the compiler in distutils
In-Reply-To: <1329385035.22.0.0715283153402.issue14030@psf.upfronthosting.co.za>
Message-ID: <1329625850.21.0.737997070086.issue14030@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/issue14030>
_______________________________________

From report at bugs.python.org  Sun Feb 19 06:43:00 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Sun, 19 Feb 2012 05:43:00 +0000
Subject: [issue13579] string.Formatter doesn't understand the !a conversion
	specifier
In-Reply-To: <CADiSq7f90to2gCbTV+frKzQ1TU=hxRBhXFY5TUrrAhe7_D23bg@mail.gmail.com>
Message-ID: <4F3FDA32.6060208@email.de>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

> I suspect mq will confuse make patchcheck (since it looks for
> differences between the working copy and the hg branch tip, and there
> are no such differences for an applied mq patch).

Does it makes sense to open a feature request for that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13579>
_______________________________________

From report at bugs.python.org  Sun Feb 19 07:14:40 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 19 Feb 2012 06:14:40 +0000
Subject: [issue14051] Cannot set attributes on staticmethod
In-Reply-To: <1329587129.39.0.150393564133.issue14051@psf.upfronthosting.co.za>
Message-ID: <E1Rz02h-0000Dl-2g@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f46deae68e34 by Benjamin Peterson in branch 'default':
allow arbitrary attributes on classmethod and staticmethod (closes #14051)
http://hg.python.org/cpython/rev/f46deae68e34

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14051>
_______________________________________

From report at bugs.python.org  Sun Feb 19 07:20:34 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 06:20:34 +0000
Subject: [issue12393] Packaging should provide support for extensible
	categories
In-Reply-To: <1308905605.65.0.75321405353.issue12393@psf.upfronthosting.co.za>
Message-ID: <1329632434.39.0.0734457312276.issue12393@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve had a look at your implementation.  It is an interesting use of properties, but doesn?t quite fit into how packaging works.  Most of the options parsing and validation (from config files and command-line alike) is done in each command?s finalize_options method, some parsing and validation is done in the config module (for the metadata, files and soon extension sections), and the section named ?global? is validated by the Distribution (or maybe Dispatcher now) class.  So I?ll certainly reuse your tests, but will have to redo the implementation.

I?m also wondering if install_data?s options are the right place for this.  For example, does it make sense to allow ?pysetup run install_data --categories spam=blah??  (Any command option can be given on the command line.)  Maybe the global section of setup.cfg would be better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12393>
_______________________________________

From report at bugs.python.org  Sun Feb 19 09:31:41 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 08:31:41 +0000
Subject: [issue14047] UTF-8 Email Header
In-Reply-To: <1329549808.72.0.457462714436.issue14047@psf.upfronthosting.co.za>
Message-ID: <1329640301.67.0.631082835269.issue14047@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello Michal.  This bug tracker is used to collect bug reports and feature requests, not for general support.  Please use the python-list mailing list, also known as the comp.lang.python newgroup, or #python on IRC (Freenode), or Stack Overflow, or any other discussion venue.  If you do find that the Python docs are erroneous, misleading or incomplete, then feel free to say so and we?ll reopen this report to see how we can improve the docs.  Cheers!

----------
nosy: +eric.araujo
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: behavior -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14047>
_______________________________________

From report at bugs.python.org  Sun Feb 19 09:33:29 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 08:33:29 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1329640409.03.0.731850605272.issue11051@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/issue11051>
_______________________________________

From report at bugs.python.org  Sun Feb 19 09:34:34 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 19 Feb 2012 08:34:34 +0000
Subject: [issue14050] Tutorial, list.sort() and items comparability
In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za>
Message-ID: <1329640474.63.0.212753555001.issue14050@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

We could just mention that a TypeError is raised if some of the elements can't be compared. (Note that sorting a list that contains some types that cannot be compared might still succeed in some corner cases, but there's no reason to mention this).

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14050>
_______________________________________

From report at bugs.python.org  Sun Feb 19 09:36:25 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 08:36:25 +0000
Subject: [issue14050] Tutorial, list.sort() and items comparability
In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za>
Message-ID: <1329640585.58.0.818467593225.issue14050@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If I had read your patched version when I was a beginner, I don?t think it would have helped me much.  (Sorry for not coming up with an alternative right now, it?s late/early here and I?m tired :)

----------
nosy: +eric.araujo, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14050>
_______________________________________

From report at bugs.python.org  Sun Feb 19 09:37:00 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 08:37:00 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2 and
	python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1329640620.43.0.611923360193.issue6784@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Sun Feb 19 09:37:49 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 08:37:49 +0000
Subject: [issue14052] importlib mixes up '.' and os.getcwd()
In-Reply-To: <1329597527.35.0.680600221226.issue14052@psf.upfronthosting.co.za>
Message-ID: <1329640669.64.0.846069658598.issue14052@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14052>
_______________________________________

From report at bugs.python.org  Sun Feb 19 09:45:40 2012
From: report at bugs.python.org (Michal Sladek)
Date: Sun, 19 Feb 2012 08:45:40 +0000
Subject: [issue14047] UTF-8 Email Header
In-Reply-To: <1329640301.67.0.631082835269.issue14047@psf.upfronthosting.co.za>
Message-ID: <CANQ64JZVNWpDDtJctDxitbOg71OiZe7T8Ud6_NJ4769107riEw@mail.gmail.com>


Michal Sladek <michal at sladkovi.eu> added the comment:

Hello Eric!

I believe that there is a bug which prevents adding UTF-8 encoded
suject to multipart message properly. But because I am not a
programmer, I admin I might be wrong. So if you are a programmer and
you don't see any obvious mistake in my example code, open that bug
report again. Because in my opinion that code should work properly and
it does not.

Best regards

Michal

Dne 19. ?nora 2012 9:31 ?ric Araujo <report at bugs.python.org> napsal(a):
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Hello Michal. ?This bug tracker is used to collect bug reports and feature requests, not for general support. ?Please use the python-list mailing list, also known as the comp.lang.python newgroup, or #python on IRC (Freenode), or Stack Overflow, or any other discussion venue. ?If you do find that the Python docs are erroneous, misleading or incomplete, then feel free to say so and we?ll reopen this report to see how we can improve the docs. ?Cheers!
>
> ----------
> nosy: +eric.araujo
> resolution: ?-> invalid
> stage: ?-> committed/rejected
> status: open -> closed
> type: behavior ->
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue14047>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14047>
_______________________________________

From report at bugs.python.org  Sun Feb 19 09:52:05 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 08:52:05 +0000
Subject: [issue14047] UTF-8 Email Header
In-Reply-To: <1329549808.72.0.457462714436.issue14047@psf.upfronthosting.co.za>
Message-ID: <1329641525.12.0.237923637614.issue14047@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Sorry, I cannot right now take the time to go through the doc and your code.  Please use any of the friendly venues I listed in my previous message to get help on your code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14047>
_______________________________________

From report at bugs.python.org  Sun Feb 19 09:58:47 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 08:58:47 +0000
Subject: [issue6039] cygwin compilers should not check compiler versions
In-Reply-To: <1242471954.24.0.755904874213.issue6039@psf.upfronthosting.co.za>
Message-ID: <1329641927.53.0.862692115018.issue6039@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Closing for lack of information.  Will reopen if someone explains what the problem is.

----------
assignee: tarek -> eric.araujo
nosy: +eric.araujo
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6039>
_______________________________________

From report at bugs.python.org  Sun Feb 19 10:03:51 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 09:03:51 +0000
Subject: [issue4918] Windows installer created with Python 2.5 does not work
	with Python 2.6.1
In-Reply-To: <1231738106.14.0.212121765754.issue4918@psf.upfronthosting.co.za>
Message-ID: <1329642231.86.0.168607736781.issue4918@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Not sure if there is much to be done here; I don?t know if it is a reasonable expectation that an installer created with 2.X still work with 2.X+1, and anyway only 2.7 could get a bugfix now.

----------
nosy: +eric.araujo
title: Windows installer created with Python 2.5  does not work with Python 2.6.1 -> Windows installer created with Python 2.5 does not work with Python 2.6.1
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4918>
_______________________________________

From report at bugs.python.org  Sun Feb 19 10:04:41 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 09:04:41 +0000
Subject: [issue7509] AttributeError: MSVCCompiler instance has no attribute
	'_MSVCCompiler__root'
In-Reply-To: <1260858289.28.0.0186938090611.issue7509@psf.upfronthosting.co.za>
Message-ID: <1329642281.82.0.0969251796677.issue7509@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7509>
_______________________________________

From report at bugs.python.org  Sun Feb 19 10:11:14 2012
From: report at bugs.python.org (Michal Sladek)
Date: Sun, 19 Feb 2012 09:11:14 +0000
Subject: [issue14047] UTF-8 Email Header
In-Reply-To: <1329641525.12.0.237923637614.issue14047@psf.upfronthosting.co.za>
Message-ID: <CANQ64JY_gLcu6tsQKVU8PO3prya=7NsOam2kPMrWsA0Qi_UsmA@mail.gmail.com>


Michal Sladek <michal at sladkovi.eu> added the comment:

I guess you don't understand me.

My script works properly. I don't need any help with it. OK? I have
found a workaround and I am happy with it for now. But I think, there
is a problem in current version of Python language.

Now, what should I do to report the bug with adding UTF-8 encoded
header? I described the problem, I submitted the example code. How can
I draw developers attention to the problem when you close the bug?

Dne 19. ?nora 2012 9:52 ?ric Araujo <report at bugs.python.org> napsal(a):
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Sorry, I cannot right now take the time to go through the doc and your code. ?Please use any of the friendly venues I listed in my previous message to get help on your code.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue14047>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14047>
_______________________________________

From report at bugs.python.org  Sun Feb 19 10:11:24 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 09:11:24 +0000
Subject: [issue8918] distutils test_config_cmd failure on Solaris
In-Reply-To: <1275846660.59.0.731483262347.issue8918@psf.upfronthosting.co.za>
Message-ID: <1329642684.27.0.052876145544.issue8918@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

We have a Solaris buildbot but it?s offline, so I don?t know if this bug is still current.  If it is, then it should be easy to use ?cc + ' -P'? for that OS (IIUC the test can just be ?if sys.platform == 'solaris'?).

----------
assignee: tarek -> eric.araujo
components: +Distutils2
nosy: +alexis, eric.araujo
stage:  -> test needed
title: distutils test failure on solaris: IOError: [Errno 2] No such file or directory: '_configtest.i' -> distutils test_config_cmd failure on Solaris
versions: +3rd party, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8918>
_______________________________________

From report at bugs.python.org  Sun Feb 19 10:14:17 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 09:14:17 +0000
Subject: [issue4636] bdist_wininst installer with install script raises
	exception
In-Reply-To: <1229030167.98.0.0716327891895.issue4636@psf.upfronthosting.co.za>
Message-ID: <1329642857.99.0.627105915067.issue4636@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The crash message is the same as the one in #4918; it looks like bdist_wininst need better error reporting.

----------
assignee: tarek -> eric.araujo
stage:  -> test needed
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4636>
_______________________________________

From report at bugs.python.org  Sun Feb 19 10:14:33 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Feb 2012 09:14:33 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1329642873.1.0.0977797829198.issue13703@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Attaching reviewed version for 3.1 with unified env var PYTHONHASHSEED and encompassing Antoine's and Greg's review comments.

----------
Added file: http://bugs.python.org/file24561/hash-patch-3.1-gb.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Sun Feb 19 10:21:32 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Feb 2012 09:21:32 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1329643292.82.0.515264669236.issue13703@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file24561/hash-patch-3.1-gb.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Sun Feb 19 10:21:53 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Feb 2012 09:21:53 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1329643313.65.0.954078406115.issue13703@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

New version, with the hope that it gets a "review" link.

----------
Added file: http://bugs.python.org/file24562/hash-patch-3.1-gb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Sun Feb 19 10:24:25 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 09:24:25 +0000
Subject: [issue8526] msilib doesn't support multiple CAB instances in same
	installer
In-Reply-To: <1272154034.54.0.42494510324.issue8526@psf.upfronthosting.co.za>
Message-ID: <1329643465.4.0.166750828522.issue8526@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Martin, are you rejecting this bug report as worksforme or is it a valid feature request?

----------
components:  -Distutils
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8526>
_______________________________________

From report at bugs.python.org  Sun Feb 19 10:32:28 2012
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Sun, 19 Feb 2012 09:32:28 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2 and
	python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1329643948.13.0.294749704083.issue6784@psf.upfronthosting.co.za>


Ronny Pfannschmidt <ronny.pfannschmidt at gmail.com> added the comment:

im unlikely to find the time to try and fix pickle/cpickle myself in the next few months

----------
nosy: +Ronny.Pfannschmidt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Sun Feb 19 10:38:44 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 09:38:44 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1329644324.2.0.592676938458.issue6884@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It?s strange that glob_to_re needs fixing too; at this point I?m not sure if we?re still fixing my commit or if the original code never worked properly on Windows.  Could you run the same tests with a Python < 2.7?

BTW I wonder if #9691 is yet another manifestation of this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sun Feb 19 10:44:06 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 09:44:06 +0000
Subject: [issue1173134] improvement of the script adaptation for the win32
	platform
Message-ID: <1329644646.02.0.319089231985.issue1173134@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

For distutils2, we?re going to generate .exe wrappers on Windows, like setuptools does (see #12394).

distutils is feature-frozen.

----------
assignee: tarek -> eric.araujo
components: +Distutils2 -Distutils, Windows
nosy: +alexis, eric.araujo
resolution:  -> rejected
stage:  -> committed/rejected
superseder:  -> packaging: generate scripts from callable (dotted paths)
versions: +3rd party, Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1173134>
_______________________________________

From report at bugs.python.org  Sun Feb 19 10:47:55 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 09:47:55 +0000
Subject: [issue1173134] improvement of the script adaptation for the win32
	platform
Message-ID: <1329644875.53.0.6433333097.issue1173134@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/issue1173134>
_______________________________________

From report at bugs.python.org  Sun Feb 19 10:51:44 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 09:51:44 +0000
Subject: [issue7719] distutils: ignore .nfsXXXX files
In-Reply-To: <1263669405.52.0.706975841329.issue7719@psf.upfronthosting.co.za>
Message-ID: <1329645104.63.0.0158040856275.issue7719@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks to Sandro?s explanation and a passage in the Unix Haters Handbook, I now think that ignoring .nfs* files is a safe change.  If should not be hard to add a test for this in test_sdist.

----------
assignee: tarek -> eric.araujo
keywords: +easy
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7719>
_______________________________________

From report at bugs.python.org  Sun Feb 19 10:59:46 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Feb 2012 09:59:46 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1329645586.75.0.467185464715.issue13703@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file24562/hash-patch-3.1-gb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Sun Feb 19 11:00:46 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Feb 2012 10:00:46 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1329645646.79.0.800047908372.issue13703@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

New patch fixes failures due to sys.flags backwards compatibility.

With PYTHONHASHSEED=random, at least those tests still fail:
test_descr test_json test_set test_ttk_textonly test_urllib

Do we want to fix them in 3.1?

----------
Added file: http://bugs.python.org/file24563/hash-patch-3.1-gb-03.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Sun Feb 19 11:01:34 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 19 Feb 2012 10:01:34 +0000
Subject: [issue4918] Windows installer created with Python 2.5 does not work
	with Python 2.6.1
In-Reply-To: <1231738106.14.0.212121765754.issue4918@psf.upfronthosting.co.za>
Message-ID: <1329645694.7.0.0668192600815.issue4918@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Installers "ought to" work for subsequent versions if they contain pure-Python packages (i.e. no extension modules). I agree that the issue is obsolete for 2.x, but it may still exist for 3.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4918>
_______________________________________

From report at bugs.python.org  Sun Feb 19 11:03:33 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 19 Feb 2012 10:03:33 +0000
Subject: [issue8526] msilib doesn't support multiple CAB instances in same
	installer
In-Reply-To: <1272154034.54.0.42494510324.issue8526@psf.upfronthosting.co.za>
Message-ID: <1329645813.66.0.0984912753207.issue8526@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As a feature request, it's fine - but I have no intention to work on this feature.

----------
assignee: loewis -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8526>
_______________________________________

From report at bugs.python.org  Sun Feb 19 11:06:23 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 19 Feb 2012 10:06:23 +0000
Subject: [issue8526] msilib doesn't support multiple CAB instances in same
	installer
In-Reply-To: <1272154034.54.0.42494510324.issue8526@psf.upfronthosting.co.za>
Message-ID: <1329645983.67.0.186036757562.issue8526@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8526>
_______________________________________

From report at bugs.python.org  Sun Feb 19 11:15:36 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Feb 2012 10:15:36 +0000
Subject: [issue11051] Improve Python 3.3 startup time
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1329646536.16.0.530776344533.issue11051@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I changed the title of the issue because what matters is the total startup time, not how it is improved :-)

----------
title: system calls per import -> Improve Python 3.3 startup time

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11051>
_______________________________________

From report at bugs.python.org  Sun Feb 19 11:19:05 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 10:19:05 +0000
Subject: [issue4918] Windows installer created with Python X.Y does not work
	with Python X.Y+1
In-Reply-To: <1231738106.14.0.212121765754.issue4918@psf.upfronthosting.co.za>
Message-ID: <1329646745.69.0.421921421262.issue4918@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks, keeping it open.  If I manage to get a VM set up I will see if this is reproducible.

----------
components: +Distutils2
nosy: +alexis
title: Windows installer created with Python 2.5 does not work with Python 2.6.1 -> Windows installer created with Python X.Y does not work with Python X.Y+1
versions: +3rd party, Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4918>
_______________________________________

From report at bugs.python.org  Sun Feb 19 11:19:31 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 10:19:31 +0000
Subject: [issue8526] msilib doesn't support multiple CAB instances in same
	installer
In-Reply-To: <1272154034.54.0.42494510324.issue8526@psf.upfronthosting.co.za>
Message-ID: <1329646771.77.0.97203754547.issue8526@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy:  -eric.araujo
type: behavior -> enhancement
versions:  -Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8526>
_______________________________________

From report at bugs.python.org  Sun Feb 19 11:22:03 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 10:22:03 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1329646923.36.0.948800983059.issue13703@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> With PYTHONHASHSEED=random, at least those tests still fail:
> test_descr test_json test_set test_ttk_textonly test_urllib
>
> Do we want to fix them in 3.1?

It the failures are caused by the test depending on dict order (i.e. not real bugs, not changed behavior), then I think we can live with them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Sun Feb 19 11:23:56 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 19 Feb 2012 10:23:56 +0000
Subject: [issue14001] CVE-2012-0845 Python v2.7.2 / v3.2.2
	(SimpleXMLRPCServer): DoS (excessive CPU usage) by processing
	malformed XMLRPC / HTTP POST request
In-Reply-To: <1329140734.41.0.0376676358855.issue14001@psf.upfronthosting.co.za>
Message-ID: <1329647036.15.0.998703090106.issue14001@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Committed, thanks!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14001>
_______________________________________

From report at bugs.python.org  Sun Feb 19 11:35:36 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Feb 2012 10:35:36 +0000
Subject: [issue11051] Improve Python 3.3 startup time
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1329647736.14.0.530603740491.issue11051@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Using the following patch, "./python -s -c pass" is 2x faster than without the patch!

diff --git a/Lib/site.py b/Lib/site.py
--- a/Lib/site.py
+++ b/Lib/site.py
@@ -518,7 +518,8 @@ def main():
     known_paths = removeduppaths()
     if ENABLE_USER_SITE is None:
         ENABLE_USER_SITE = check_enableusersite()
-    known_paths = addusersitepackages(known_paths)
+    if ENABLE_USER_SITE:
+        known_paths = addusersitepackages(known_paths)
     known_paths = addsitepackages(known_paths)
     if sys.platform == 'os2emx':
         setBEGINLIBPATH()

-s with the patch doesn't import the sysconfig module. So if we want to speed up Python, the first step is to optimize it, at least the function getting the user site packages directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11051>
_______________________________________

From report at bugs.python.org  Sun Feb 19 11:56:32 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 19 Feb 2012 10:56:32 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1329648992.56.0.452392365594.issue6884@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> It?s strange that glob_to_re needs fixing too; at this point I?m not sure if we?re still fixing my commit or if the original code never worked properly on Windows.  Could you run the same tests with a Python < 2.7?

The original code never worked properly on Windows - that's what the XXX
comment in glob_to_re() is about. I've been able to reproduce the problem
(erroneously including ".hg\last-message.txt") on v2.7.2 (8527427914a2).

> BTW I wonder if #9691 is yet another manifestation of this bug.

It looks like it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sun Feb 19 12:00:58 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 19 Feb 2012 11:00:58 +0000
Subject: [issue9691] sdist includes files that are not in MANIFEST.in
In-Reply-To: <1282822249.86.0.974734126224.issue9691@psf.upfronthosting.co.za>
Message-ID: <1329649258.19.0.645494085013.issue9691@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

This happens because the glob-to-regexp translator assumes that the
directory separator is "/", regardless of platform. Consequently, the
regexp for "include *.py" ends up matching "sandbox\dummy.py" erroneously
on Windows.

The problem is currently being discussed in issue 6884; I'm marking this
issue as a duplicate.

----------
nosy: +nadeem.vawda
resolution:  -> duplicate
superseder:  -> Impossible to include file in sdist that starts with 'build' on Win32

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9691>
_______________________________________

From report at bugs.python.org  Sun Feb 19 12:56:30 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 19 Feb 2012 11:56:30 +0000
Subject: [issue12393] Packaging should provide support for extensible
	categories
In-Reply-To: <1308905605.65.0.75321405353.issue12393@psf.upfronthosting.co.za>
Message-ID: <1329652590.28.0.979348233688.issue12393@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> So I?ll certainly reuse your tests, but will have to redo the implementation.

That's fine, but please bear in mind what I said about a 100% declarative approach being insufficient - see the Windows example I gave, where Windows APIs have to be called at installation time to determine how the categories are set up. My tests don't cater for that, but in my view it's an important requirement that shouldn't be lost. That's why I put the code into a hook, install_data being the one which required minimal changes to the code.

I'm not wedded to the specific implementation, simple though it is - I was aiming for a solution that worked and would be easy to review. I agree that install_data may not be the best section for this, and the global section seems more reasonable. But the key thing, apart from the parsing logic etc., is to allow changes / additions to the categories to be made at installation time by user-defined code (=> hook).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12393>
_______________________________________

From report at bugs.python.org  Sun Feb 19 13:39:46 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 19 Feb 2012 12:39:46 +0000
Subject: [issue13090] test_multiprocessing: memory leaks
In-Reply-To: <1329343497.1.0.562177752755.issue13090@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0U+a95BcmTQKZxxictnotSP1gGM6jizB=fpJxbjRJF2w@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Two others seem to be the internal "bootstate" structure used to
> run thread objects (daemon threads?).

Even for daemon threads, since the boostate structure is freed when
the thread's run() method returns, this shouldn't show up as a
"definitely lost" leak. It wouldn't be freed on exit, but it should
still be reachable.

However, I have a stupid question: are those logs for the main
process, or for child processes ?
Because if fork() is called while other threads are running, since
only the main thread exists in the child process, all the blocks only
reachable from the other threads stacks at the time of the fork -
among which the bootstate structure, and probably the buffer allocated
in posix_read() while a thread is blocked on the read() syscall - are
effectively leaked in the child process since they're not referenced
anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13090>
_______________________________________

From report at bugs.python.org  Sun Feb 19 13:45:35 2012
From: report at bugs.python.org (Vladimir Rutsky)
Date: Sun, 19 Feb 2012 12:45:35 +0000
Subject: [issue13857] Add textwrap.indent() as counterpart to textwrap.dedent()
In-Reply-To: <1327462635.84.0.618726818638.issue13857@psf.upfronthosting.co.za>
Message-ID: <1329655535.26.0.753330311904.issue13857@psf.upfronthosting.co.za>


Changes by Vladimir Rutsky <altsysrq at gmail.com>:


----------
nosy: +rutsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13857>
_______________________________________

From report at bugs.python.org  Sun Feb 19 15:13:23 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 19 Feb 2012 14:13:23 +0000
Subject: [issue14052] importlib mixes up '.' and os.getcwd()
In-Reply-To: <1329597527.35.0.680600221226.issue14052@psf.upfronthosting.co.za>
Message-ID: <1329660803.05.0.870162661702.issue14052@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Purging __file__ of relative references isn't a problem - they're *supposed* to always be absolute. The import.c version just stuffs it up sometimes (mainly due to the way it handles the empty string in the path).

IOW, while the importlib behaviour *is* different from the old behaviour, it's really a long overdue fix rather than a defect.
(You can still induce weirdness by adding paths involving '.' or '..' to sys.path, but that's more a case of "don't do that". We add the empty string ourselves, so we should handle it more cleanly than we do in import.c)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14052>
_______________________________________

From report at bugs.python.org  Sun Feb 19 15:24:31 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Sun, 19 Feb 2012 14:24:31 +0000
Subject: [issue14053] Make Tools/scripts/patchcheck.py compatible with
	mercurial mqueues.
Message-ID: <1329661471.35.0.733956428931.issue14053@psf.upfronthosting.co.za>


New submission from Francisco Mart?n Brugu? <francismb at email.de>:

The devguide (http://docs.python.org/devguide/patch.html) recommends the use of the mercurial ?mq? feature to work with patches and that works IMHO very well. It also states that before sending the patch a sanity check should be done ('devguide: Preparation and Generation'). At this stage, if one has the patch as tip (hg qapplied), the advice to run ?pathcheck? doesn't help as no changes are noticed.

The message is:
-----------------------------------------------
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
Usually, copying Modules/Setup.dist to Modules/Setup will work.
-----------------------------------------------
./python ./Tools/scripts/patchcheck.py
Getting the list of files that have been added/changed ... 0 files
Fixing whitespace ... 0 files
Fixing C file whitespace ... 0 files
Fixing docs whitespace ... 0 files
Docs modified ... NO
Misc/ACKS updated ... NO
Misc/NEWS updated ... NO
The tool should check if some mq patches are applied (from ?normal? tip to ?mqtip? and make it's checks there.

Thanks in advance !

Francis

----------
components: Demos and Tools, Devguide
messages: 153703
nosy: ezio.melotti, francismb
priority: normal
severity: normal
status: open
title: Make Tools/scripts/patchcheck.py compatible with mercurial mqueues.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14053>
_______________________________________

From report at bugs.python.org  Sun Feb 19 15:57:00 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 19 Feb 2012 14:57:00 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1329663420.52.0.299229285047.issue13248@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Sun Feb 19 16:28:14 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Sun, 19 Feb 2012 15:28:14 +0000
Subject: [issue13579] string.Formatter doesn't understand the !a conversion
	specifier
In-Reply-To: <4F3FDA32.6060208@email.de>
Message-ID: <4F4106BA.90805@email.de>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

Well, it's done:

http://bugs.python.org/issue14053

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13579>
_______________________________________

From report at bugs.python.org  Sun Feb 19 16:49:20 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Sun, 19 Feb 2012 15:49:20 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2 and
	python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1329666560.9.0.287473229089.issue6784@psf.upfronthosting.co.za>


Merlijn van Deen <valhallasw at gmail.com> added the comment:

Last night, I hacked together a wrapper to do what loewis suggested [1]. It pickles bytes to str (for protocol <= 2), and unpickles str to bytes.

If I (ever) get the build system and tests of python itself to work, I'll try and see if I can implement a nicer solution - at least for pickle.py.

[1] https://github.com/valhallasw/py2/blob/master/bytestrpickle.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Sun Feb 19 16:49:50 2012
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 19 Feb 2012 15:49:50 +0000
Subject: [issue14051] Cannot set attributes on staticmethod
In-Reply-To: <1329587129.39.0.150393564133.issue14051@psf.upfronthosting.co.za>
Message-ID: <1329666590.63.0.207272170927.issue14051@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Wouldn't it make more sense to somehow share the dict with the underlying function?

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14051>
_______________________________________

From report at bugs.python.org  Sun Feb 19 16:53:44 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Feb 2012 15:53:44 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2 and
	python3
In-Reply-To: <1329666560.9.0.287473229089.issue6784@psf.upfronthosting.co.za>
Message-ID: <1329666625.3442.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If I (ever) get the build system and tests of python itself to work,

If you have any problems with that, don't hesitate to ask on python-dev
(or see http://mail.python.org/mailman/listinfo/core-mentorship )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Sun Feb 19 17:09:25 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Feb 2012 16:09:25 +0000
Subject: [issue13842] Cannot pickle Ellipsis or NotImplemented
In-Reply-To: <1327346659.12.0.712807876778.issue13842@psf.upfronthosting.co.za>
Message-ID: <1329667765.16.0.364375112936.issue13842@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I haven't taken a look at the patch in detail, but it lacks some tests.
Pickling tests are generally in Lib/test/pickletester.py, they are invoked by test_pickle and test_pickletools.

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13842>
_______________________________________

From report at bugs.python.org  Sun Feb 19 17:09:37 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Feb 2012 16:09:37 +0000
Subject: [issue13842] Cannot pickle Ellipsis or NotImplemented
In-Reply-To: <1327346659.12.0.712807876778.issue13842@psf.upfronthosting.co.za>
Message-ID: <1329667777.52.0.778924873729.issue13842@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +hynek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13842>
_______________________________________

From report at bugs.python.org  Sun Feb 19 17:17:18 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 19 Feb 2012 16:17:18 +0000
Subject: [issue14053] Make Tools/scripts/patchcheck.py compatible with
	mercurial mqueues.
In-Reply-To: <1329661471.35.0.733956428931.issue14053@psf.upfronthosting.co.za>
Message-ID: <1329668238.83.0.022970003848.issue14053@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14053>
_______________________________________

From report at bugs.python.org  Sun Feb 19 17:18:18 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Feb 2012 16:18:18 +0000
Subject: [issue13842] Cannot pickle Ellipsis or NotImplemented
In-Reply-To: <1327346659.12.0.712807876778.issue13842@psf.upfronthosting.co.za>
Message-ID: <1329668298.2.0.721526705886.issue13842@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm completely new to the C API so not sure if the way I am building
> python strings (to pass to save_global) is correct

It's correct but it's probably less efficient than calling a more specialized function, such as PyUnicode_FromString():
http://docs.python.org/dev/c-api/unicode.html#PyUnicode_FromString

You also have to check the return value (for non-NULL, NULL meaning an error occurred) before calling save_global with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13842>
_______________________________________

From report at bugs.python.org  Sun Feb 19 17:18:47 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Feb 2012 16:18:47 +0000
Subject: [issue14053] Make Tools/scripts/patchcheck.py compatible with
	mercurial mqueues.
In-Reply-To: <1329661471.35.0.733956428931.issue14053@psf.upfronthosting.co.za>
Message-ID: <1329668327.53.0.263941869287.issue14053@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +eric.araujo
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14053>
_______________________________________

From report at bugs.python.org  Sun Feb 19 17:42:46 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 19 Feb 2012 16:42:46 +0000
Subject: [issue14051] Cannot set attributes on staticmethod
In-Reply-To: <1329587129.39.0.150393564133.issue14051@psf.upfronthosting.co.za>
Message-ID: <1329669766.55.0.762960361682.issue14051@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

You can wrap anything with staticmethod, so it might not have a __dict__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14051>
_______________________________________

From report at bugs.python.org  Sun Feb 19 18:10:41 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Feb 2012 17:10:41 +0000
Subject: [issue14054] test_importlib failures under Windows
Message-ID: <1329671441.02.0.700049402355.issue14054@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

======================================================================
FAIL: test_case_sensitive (importlib.test.extension.test_case_sensitivity.ExtensionModuleCaseSensitivityTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\importlib\test\extension\test_case_sensitivity.py", line 27, in test_case_sensitive
    self.assertIsNone(loader)
AssertionError: <importlib._bootstrap._ExtensionFileLoader object at 0x07C0C850> is not None

======================================================================
FAIL: test_sensitive (importlib.test.source.test_case_sensitivity.CaseSensitivityTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\importlib\test\source\test_case_sensitivity.py", line 46, in test_sensitive
    self.assertIsNone(insensitive)
AssertionError: <importlib._bootstrap._SourceFileLoader object at 0x1259FDC8> is not None

----------
assignee: brett.cannon
components: Library (Lib), Tests
messages: 153711
nosy: brett.cannon, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: test_importlib failures under Windows
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14054>
_______________________________________

From report at bugs.python.org  Sun Feb 19 18:15:26 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Feb 2012 17:15:26 +0000
Subject: [issue14040] Deprecate some of the module file formats
In-Reply-To: <1329485796.8.0.890516593146.issue14040@psf.upfronthosting.co.za>
Message-ID: <1329671726.4.0.265934417775.issue14040@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch simply removing the suffixes.

----------
Added file: http://bugs.python.org/file24564/removesuffixes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14040>
_______________________________________

From report at bugs.python.org  Sun Feb 19 19:17:18 2012
From: report at bugs.python.org (Catalin Iacob)
Date: Sun, 19 Feb 2012 18:17:18 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <1324386392.48.0.968435833624.issue13641@psf.upfronthosting.co.za>
Message-ID: <1329675438.34.0.351704102831.issue13641@psf.upfronthosting.co.za>


Catalin Iacob <iacobcatalin at gmail.com> added the comment:

Attached v2 of patch where mixing str and binary data for altchars or map01 raises TypeError.

I also added a note for each of the changed functions that it also accepts strings (but didn't also update the docstrings).

When writing the docs, the new functionality seemed hard to describe; maybe that means this issue only complicates things and is not worth it, or maybe it just means I don't have experience at writing docs.

But, regardless of having worked at a patch, I have to admit that I'm also not 100% sure this issue is a good idea. I *do* think that either both this issue and #13637 should be accepted or both rejected.

----------
Added file: http://bugs.python.org/file24565/issue13641-alternative-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Sun Feb 19 19:21:54 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Feb 2012 18:21:54 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <1324386392.48.0.968435833624.issue13641@psf.upfronthosting.co.za>
Message-ID: <1329675714.92.0.937052770829.issue13641@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think trying to prevent mixed argument types is completely overkill. There's no ambiguity since they all have to be ASCII anyway.
So I would prefer to commit issue13641-alternative-v1.patch

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Sun Feb 19 19:22:38 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Sun, 19 Feb 2012 18:22:38 +0000
Subject: [issue14053] Make Tools/scripts/patchcheck.py compatible with
	mercurial mqueues.
In-Reply-To: <1329661471.35.0.733956428931.issue14053@psf.upfronthosting.co.za>
Message-ID: <1329675758.77.0.569127735237.issue14053@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

Here is a patch that works for me. Please check and review it.

Thanks in advance!

Francis

----------
keywords: +patch
Added file: http://bugs.python.org/file24566/issue14053_336a614f35a3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14053>
_______________________________________

From report at bugs.python.org  Sun Feb 19 19:59:45 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 19 Feb 2012 18:59:45 +0000
Subject: [issue13605] document argparse's nargs=REMAINDER
In-Reply-To: <1323955710.42.0.753468095058.issue13605@psf.upfronthosting.co.za>
Message-ID: <E1RzByz-0001S9-EZ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 996efb0425c5 by Sandro Tosi in branch '3.2':
Issue #13605: use print() in argparse nargs example
http://hg.python.org/cpython/rev/996efb0425c5

New changeset c3daa6a834c6 by Sandro Tosi in branch 'default':
Issue #13605: merge with 3.2
http://hg.python.org/cpython/rev/c3daa6a834c6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13605>
_______________________________________

From report at bugs.python.org  Sun Feb 19 19:59:45 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 19 Feb 2012 18:59:45 +0000
Subject: [issue14047] UTF-8 Email Header
In-Reply-To: <1329549808.72.0.457462714436.issue14047@psf.upfronthosting.co.za>
Message-ID: <1329677985.32.0.446358010773.issue14047@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Michal, it's your wording of your report, and also some of the contents that caused Eric's reaction. When you conclude with "Am I doing something wrong?", then your message is *not* a bug report, but a question for help (namely, you are asking somebody to find out whether you did something wrong).

Please structure bug reports as follows:
1. this is what I did
2. this is what happened
3. this is what I expected to happen instead

Your report gives hints at 1, but neither discusses 2 or 3. I.e. you say what code you write, but you did not say (AFAICT) what parameters you passed to the function. And you did not say what happened when you passed the parameters.

This is important information, as the first step of us is to reproduce the bug report, i.e. try out all your steps and see whether the same happens also when we do it (which often enough is not the case).

Since this bug report is already filled with unrelated meta-discussion, please submit a new bug report in the style I explain above.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14047>
_______________________________________

From report at bugs.python.org  Sun Feb 19 20:03:21 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Sun, 19 Feb 2012 19:03:21 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2 and
	python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1329678201.81.0.295094590742.issue6784@psf.upfronthosting.co.za>


Changes by Merlijn van Deen <valhallasw at gmail.com>:


Added file: http://bugs.python.org/file24567/test_bytestrpickle.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Sun Feb 19 20:08:10 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Sun, 19 Feb 2012 19:08:10 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2 and
	python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1329678490.57.0.0127552207963.issue6784@psf.upfronthosting.co.za>


Merlijn van Deen <valhallasw at gmail.com> added the comment:

OK, this is the pickle.py patch. A new parameter 'bytestr' has been added to both _Pickler and _Unpickler to toggle the pickle.string<=>bytes behaviour:

_Pickler:
IF protocol <= 2 AND bytestr=True
THEN bytes are stored as STRING/SHORT_BINSTRING/BINSTRING
ELSE (the old behaviour; obj for protocol <=2, else BINARY)

_Unpickler:
IF bytestr=True
THEN STRING/SHORT_BINSTRING/BINSTRING are read as bytes
ELSE they are read as str (old behaviour)

I also extracted the decoding stuff from the three string reading functions to a single one.

----------
keywords: +patch
Added file: http://bugs.python.org/file24568/pickle.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Sun Feb 19 20:10:29 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Sun, 19 Feb 2012 19:10:29 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2 and
	python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1329678629.97.0.82956755679.issue6784@psf.upfronthosting.co.za>


Merlijn van Deen <valhallasw at gmail.com> added the comment:

P.S. (sorry for forgetting this in the original post ;-))

Both 
  ./python -m test -G -v test_pickle
and
  ./python test_bytestrpickle.py
pass, but I have not run the entire test suite, as that takes ~90 minutes on my laptop....

The test script should of course be merged with test_pickle.py at some time....

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Sun Feb 19 20:27:14 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 19 Feb 2012 19:27:14 +0000
Subject: [issue13090] test_multiprocessing: memory leaks
In-Reply-To: <CAH_1eM0U+a95BcmTQKZxxictnotSP1gGM6jizB=fpJxbjRJF2w@mail.gmail.com>
Message-ID: <20120219192711.GA9540@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Charles-Fran??ois Natali <report at bugs.python.org> wrote:
> However, I have a stupid question: are those logs for the main
> process, or for child processes ?

Valgrind was run with --trace-children=no. However, the option is a bit
tricky, since it only affects tracing of sub-processes initiated via the
exec system call.

Even with --trace-children=no Valgrind *does* trace into the child of a fork:

http://valgrind.org/docs/manual/manual-core.html#manual-core.basicopts

> Because if fork() is called while other threads are running, since
> only the main thread exists in the child process, all the blocks only
> reachable from the other threads stacks at the time of the fork -
> among which the bootstate structure, and probably the buffer allocated
> in posix_read() while a thread is blocked on the read() syscall - are
> effectively leaked in the child process since they're not referenced
> anymore.

All lines of the log I posted are prefixed with ==3047==, which should
be the process number of the main thread.

I don't know if Valgrind reports leaks in a forked-without-exec-child
as part of the parent process log. But it could be the case here.

Regarding the posix_read leak: Running with --num-callers=50 shows
that it's also thread related:

==8736== 37 bytes in 1 blocks are definitely lost in loss record 383 of 10,841
==8736==    at 0x4C2154B: malloc (vg_replace_malloc.c:236)
==8736==    by 0x5476A5: PyBytes_FromStringAndSize (bytesobject.c:98)
==8736==    by 0x4EC94B: posix_read (posixmodule.c:7010)
==8736==    by 0x58417C: PyCFunction_Call (methodobject.c:81)
==8736==    by 0x496AE0: call_function (ceval.c:4051)
==8736==    by 0x491D87: PyEval_EvalFrameEx (ceval.c:2674)
==8736==    by 0x494D5D: PyEval_EvalCodeEx (ceval.c:3426)
==8736==    by 0x496FD2: fast_function (ceval.c:4149)
==8736==    by 0x496C13: call_function (ceval.c:4072)
==8736==    by 0x491D87: PyEval_EvalFrameEx (ceval.c:2674)
==8736==    by 0x494D5D: PyEval_EvalCodeEx (ceval.c:3426)
==8736==    by 0x496FD2: fast_function (ceval.c:4149)
==8736==    by 0x496C13: call_function (ceval.c:4072)
==8736==    by 0x491D87: PyEval_EvalFrameEx (ceval.c:2674)
==8736==    by 0x494D5D: PyEval_EvalCodeEx (ceval.c:3426)
==8736==    by 0x496FD2: fast_function (ceval.c:4149)
==8736==    by 0x496C13: call_function (ceval.c:4072)
==8736==    by 0x491D87: PyEval_EvalFrameEx (ceval.c:2674)
==8736==    by 0x494D5D: PyEval_EvalCodeEx (ceval.c:3426)
==8736==    by 0x56A637: function_call (funcobject.c:669)
==8736==    by 0x53A203: PyObject_Call (abstract.c:2150)
==8736==    by 0x497B32: ext_do_call (ceval.c:4366)
==8736==    by 0x49213B: PyEval_EvalFrameEx (ceval.c:2715)
==8736==    by 0x496EC7: fast_function (ceval.c:4139)
==8736==    by 0x496C13: call_function (ceval.c:4072)
==8736==    by 0x491D87: PyEval_EvalFrameEx (ceval.c:2674)
==8736==    by 0x496EC7: fast_function (ceval.c:4139)
==8736==    by 0x496C13: call_function (ceval.c:4072)
==8736==    by 0x491D87: PyEval_EvalFrameEx (ceval.c:2674)
==8736==    by 0x494D5D: PyEval_EvalCodeEx (ceval.c:3426)
==8736==    by 0x56A637: function_call (funcobject.c:669)
==8736==    by 0x53A203: PyObject_Call (abstract.c:2150)
==8736==    by 0x551FE1: method_call (classobject.c:320)
==8736==    by 0x53A203: PyObject_Call (abstract.c:2150)
==8736==    by 0x49638A: PyEval_CallObjectWithKeywords (ceval.c:3931)
==8736==    by 0x4E347F: t_bootstrap (_threadmodule.c:997)
==8736==    by 0x4E2DFC6: start_thread (in /lib/libpthread-2.7.so)
==8736==    by 0x579C64C: clone (in /lib/libc-2.7.so)
==8736==

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13090>
_______________________________________

From report at bugs.python.org  Sun Feb 19 20:38:55 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Feb 2012 19:38:55 +0000
Subject: [issue13090] test_multiprocessing: memory leaks
In-Reply-To: <20120219192711.GA9540@sleipnir.bytereef.org>
Message-ID: <1329680135.3442.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Regarding the posix_read leak: Running with --num-callers=50 shows
> that it's also thread related:

Would be nice to know if it's a daemon thread. Daemon threads are simply
killed by the OS at shutdown.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13090>
_______________________________________

From report at bugs.python.org  Sun Feb 19 20:44:57 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Feb 2012 19:44:57 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1329525929.53.0.489354380759.issue13627@psf.upfronthosting.co.za>
Message-ID: <1329680497.3442.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Could you provide a patch with those proposed changes?

Le samedi 18 f?vrier 2012 ? 00:45 +0000, Vinay Sajip a ?crit :
> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> 
> Almost there. The file now compiles, but a failure occurs in a later step due to compression functionality being unavailable:
> 
> building '_ssl' extension
> gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -IInclude -I. -I./Include -I/Users/vinay/projects/pythonv -c /Users/vinay/projects/pythonv/Modules/_ssl.c -o build/temp.macosx-10.5-i386-3.3/Users/vinay/projects/pythonv/Modules/_ssl.o
> /Users/vinay/projects/pythonv/Modules/_ssl.c: In function ?_get_peer_alt_names?:
> /Users/vinay/projects/pythonv/Modules/_ssl.c:645: warning: passing argument 2 of ?ASN1_item_d2i? from incompatible pointer type
> /Users/vinay/projects/pythonv/Modules/_ssl.c:650: warning: passing argument 2 of ?method->d2i? from incompatible pointer type
> /Users/vinay/projects/pythonv/Modules/_ssl.c: In function ?PySSL_compression?:
> /Users/vinay/projects/pythonv/Modules/_ssl.c:1022: warning: implicit declaration of function ?SSL_get_current_compression?
> /Users/vinay/projects/pythonv/Modules/_ssl.c:1022: warning: assignment makes pointer from integer without a cast
> gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.5-i386-3.3/Users/vinay/projects/pythonv/Modules/_ssl.o -L/usr/local/lib -lssl -lcrypto -o build/lib.macosx-10.5-i386-3.3/_ssl.so
> *** WARNING: renaming "_ssl" since importing it failed: dlopen(build/lib.macosx-10.5-i386-3.3/_ssl.so, 2): Symbol not found: _SSL_get_current_compression
>   Referenced from: /Users/vinay/projects/pythonv/build/lib.macosx-10.5-i386-3.3/_ssl.so
>   Expected in: dynamic lookup
> 
> Failed to build these modules:
> _ssl                                                  
> 
> It looks as if OPENSSL_NO_COMP needs to be defined in _ssl.c if the OpenSSL version is too old and not already defined. With this change:
> 
> #if OPENSSL_VERSION_NUMBER < 0x0090800fL && !defined(OPENSSL_NO_COMP)
> # define OPENSSL_NO_COMP
> #endif
> 
> the ssl library builds without errors. However, test_ssl fails because it still expects OP_SINGLE_ECDH_USE to be defined. With this change in test_constants:
> 
>         if ssl.HAS_ECDH:
>             ssl.OP_SINGLE_ECDH_USE
> 
> all tests pass.
> 
> I notice that the test there for OP_NO_COMPRESSION is version-based rather than capability-based, and it might be a good idea to change this too.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13627>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Sun Feb 19 21:13:15 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 19 Feb 2012 20:13:15 +0000
Subject: [issue14053] Make Tools/scripts/patchcheck.py compatible with
	mercurial mqueues.
In-Reply-To: <1329661471.35.0.733956428931.issue14053@psf.upfronthosting.co.za>
Message-ID: <1329682395.55.0.536127757839.issue14053@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Thanks for taking this up; it's something that's been bothering me for a
while now.

A couple of comments:

- The mq_changed_files() function will break if the user has specified
  git-format diffs in their ~/.hgrc file. In this case, the diff command
  in the output will begin with "diff --git" instead of "diff -r".

- What happens if a file has been deleted by the patch? The regular
  "hg status" command is set up to only return the added/modified files.
  You might want to check whether the file currently exists before adding
  it to the list of filenames to check.

- Have you considered the possibility of there being multiple patches?
  In this case, I think it makes sense to check the files in every patch,
  not just the topmost.


  An alternative approach that solves all three of these problems is to
  check whether we have any patches applied (using "hg qapplied"), and if
  this is the case, then add "--rev qbase" to the "hg status" command
  line. This will list all files added/modified by patches as well as by
  uncommitted changes.


- Using an mq command (e.g. qdiff or qapplied) will fail if the user does
  not have the mq extension enabled. In this case, mq_changed_files()
  should not allow Mercurial's error message to be printed. Ideally, it
  should distinguish between this and other errors by checking the
  subprocess's stderr, so that if a different error occurs, we can still
  print out the error message.

- In changed_files(), I don't think it makes sense to create an empty
  list ("files = []") and then append to it immediately. It would be
  better to just initialize "files" directly from the list comprehension.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14053>
_______________________________________

From report at bugs.python.org  Sun Feb 19 21:17:40 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 19 Feb 2012 20:17:40 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1329682660.56.0.676831839976.issue13627@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Attached.

----------
Added file: http://bugs.python.org/file24569/ssl-ecdh.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Sun Feb 19 21:26:26 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Feb 2012 20:26:26 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1329682660.56.0.676831839976.issue13627@psf.upfronthosting.co.za>
Message-ID: <1329682986.3442.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Attached.

Thanks. Should be fixed in 1a06f0a8120f. Can you check? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Sun Feb 19 21:28:46 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 19 Feb 2012 20:28:46 +0000
Subject: [issue14055] Implement __sizeof__ for etree Element
Message-ID: <1329683326.4.0.779702582093.issue14055@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

The cElementTree Element currently returns an incorrect response to sys.getsizeof, as it doesn't account for the extra structure, and for the child pointers array. This patch corrects the computation.

----------
files: sizeof.diff
keywords: patch
messages: 153726
nosy: loewis
priority: normal
severity: normal
status: open
title: Implement __sizeof__ for etree Element
Added file: http://bugs.python.org/file24570/sizeof.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14055>
_______________________________________

From report at bugs.python.org  Sun Feb 19 21:32:22 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Feb 2012 20:32:22 +0000
Subject: [issue14055] Implement __sizeof__ for etree Element
In-Reply-To: <1329683326.4.0.779702582093.issue14055@psf.upfronthosting.co.za>
Message-ID: <1329683542.73.0.916070757325.issue14055@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Library (Lib)
nosy: +flox
stage:  -> patch review
type:  -> enhancement
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14055>
_______________________________________

From report at bugs.python.org  Sun Feb 19 22:04:07 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 19 Feb 2012 21:04:07 +0000
Subject: [issue14040] Deprecate some of the module file formats
In-Reply-To: <1329485796.8.0.890516593146.issue14040@psf.upfronthosting.co.za>
Message-ID: <1329685447.35.0.270649427931.issue14040@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm in favour of the removesuffixes.patch. However, it will need to be accompanied with a whatsnew change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14040>
_______________________________________

From report at bugs.python.org  Sun Feb 19 23:31:58 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 22:31:58 +0000
Subject: [issue9691] sdist includes files that are not in MANIFEST.in
In-Reply-To: <1282822249.86.0.974734126224.issue9691@psf.upfronthosting.co.za>
Message-ID: <1329690718.68.0.862042198295.issue9691@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9691>
_______________________________________

From report at bugs.python.org  Sun Feb 19 23:34:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 22:34:07 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1329690847.24.0.0279053630284.issue6884@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The original code never worked properly on Windows - that's what the XXX comment in glob_to_re() is
> about. I've been able to reproduce the problem (erroneously including ".hg\last-message.txt") on
> v2.7.2 (8527427914a2).
Can you reproduce the ?include buildout.cfg? bug too?  (2.7.2 doesn?t include neither Antoine?s changeset nor mine, right?)

(Want another one?  #1702551  Blergh)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sun Feb 19 23:39:05 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 22:39:05 +0000
Subject: [issue14019] Unify tests for str.format and string.Formatter
In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za>
Message-ID: <1329691145.11.0.834806083809.issue14019@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

(ISTM that such test improvements would be beneficial to all branches, and we would also eschew merge issues if we change all branches.  Other core devs sometimes object to test improvements or additions in stable branches though.)

----------
keywords: +easy
nosy: +eric.araujo
versions: +Python 2.6, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14019>
_______________________________________

From report at bugs.python.org  Sun Feb 19 23:41:29 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 22:41:29 +0000
Subject: [issue14053] Make patchcheck compatible with MQ
In-Reply-To: <1329661471.35.0.733956428931.issue14053@psf.upfronthosting.co.za>
Message-ID: <1329691289.74.0.979801294288.issue14053@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +brett.cannon
title: Make Tools/scripts/patchcheck.py compatible with mercurial mqueues. -> Make patchcheck compatible with MQ

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14053>
_______________________________________

From report at bugs.python.org  Sun Feb 19 23:42:04 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 22:42:04 +0000
Subject: [issue14040] Deprecate some of the module file formats
In-Reply-To: <1329485796.8.0.890516593146.issue14040@psf.upfronthosting.co.za>
Message-ID: <1329691324.91.0.250203461198.issue14040@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/issue14040>
_______________________________________

From report at bugs.python.org  Sun Feb 19 23:54:13 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 22:54:13 +0000
Subject: [issue14034] first example in argparse doc is too complicated
In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za>
Message-ID: <1329692053.5.0.754612134253.issue14034@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think I was rude too when I called you off, apologies.  I?ll gladly review or help with a patch.

----------
title: the example in argparse doc is too complex -> first example in argparse doc is too complicated

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14034>
_______________________________________

From report at bugs.python.org  Mon Feb 20 00:16:32 2012
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 19 Feb 2012 23:16:32 +0000
Subject: [issue12702] shutil.copytree() should use os.lutimes() to copy the
	metadata of symlinks
In-Reply-To: <1312612968.3.0.232528111658.issue12702@psf.upfronthosting.co.za>
Message-ID: <1329693392.72.0.308657721604.issue12702@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

I think this issue fixed in changeset 74194:cf57ef65bcd0.

See: http://hg.python.org/cpython/rev/cf57ef65bcd0#l2.75

----------
nosy: +berkerpeksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12702>
_______________________________________

From report at bugs.python.org  Mon Feb 20 00:16:38 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 23:16:38 +0000
Subject: [issue12393] Packaging should provide support for extensible
	categories
In-Reply-To: <1308905605.65.0.75321405353.issue12393@psf.upfronthosting.co.za>
Message-ID: <1329693398.82.0.287705875671.issue12393@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> That's fine, but please bear in mind what I said about a 100% declarative approach being insufficient
Well, the config file approach supports simple cases, and for people needing Windows API calls, they will be able to use a pre-command hook.  In that case though, there will be no validation; this is a general problem with how commands and hooks work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12393>
_______________________________________

From report at bugs.python.org  Mon Feb 20 00:32:55 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 23:32:55 +0000
Subject: [issue14056] Misc doc changes for tarfile
Message-ID: <1329694375.61.0.870450235951.issue14056@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

A few things to improve in tarfile?s doc:

a) I found the heading ?The following variables are available on module level? strange; does ?variable? mean that users are able to edit tarfile.ENCODING to control the default encoding used?  The answer is no, as ENCODING is bound to a function default argument value and a class attribute at import time.  I suggest changing this heading for something like ?Module-level constants?, and move it before the doc for the *_FORMATS constants (the attached diff makes it look like I moved these constants, but I actually moved ENCODING?same result).

b) The doc does not say that the availability of compression formats depends on the optional compilation of some modules.  Someone following the link to the module docs for gzip, bz2 or lzma can find the info, but I think a bit more explicitness wouldn?t hurt.  The attached patch for 3.2 tries to inline the info, but is a bit clumsy; alternatively, a table like this could be added near the top:

   Support depends on the availability of certain optional modules:

   ========= =========================================== =============
   Format    Description                                 Requires
   ========= =========================================== =============
   ``xz``    xz'ed tar file (:file:`.tar.xz`)            :mod:`lzma`
   ``bz2``   bzip2'ed tar file (:file:`.tar.bz2`)        :mod:`bz2`
   ``gz``    gzip'ed tar file (:file:`.tar.gz`)          :mod:`gzip`
   ========= =========================================== =============

c) The seealso section links to zipfile, just like the into text, but not to shutil.

Please let me know what suggestions you approve or reject and I?ll commit them.

----------
assignee: eric.araujo
components: Documentation
files: misc-tarfile-doc-changes-3.2.diff
keywords: patch
messages: 153733
nosy: eric.araujo, lars.gustaebel
priority: normal
severity: normal
stage: commit review
status: open
title: Misc doc changes for tarfile
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24571/misc-tarfile-doc-changes-3.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14056>
_______________________________________

From report at bugs.python.org  Mon Feb 20 00:39:35 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 23:39:35 +0000
Subject: [issue14012] Misc tarfile fixes
In-Reply-To: <1329235837.42.0.144867770777.issue14012@psf.upfronthosting.co.za>
Message-ID: <1329694775.44.0.430071327974.issue14012@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Another one: now that shutil provides archiving operations, there is a circular dependency between tarfile and shutil.  It does not cause problems*, as both modules use qualified names, but it may be a good thing to avoid import cascades for performance reasons.  The single shutil function used by tarfile could be inlined, as I did in distutils2, or you may reject this idea.

* Except in distutils2?s backport, see http://hg.python.org/distutils2/rev/c1b1b537196d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14012>
_______________________________________

From report at bugs.python.org  Mon Feb 20 00:47:15 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Feb 2012 23:47:15 +0000
Subject: [issue14057] Speedup sysconfig startup
Message-ID: <1329695235.07.0.0035365594313.issue14057@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

On my laptop, start Python compiled in debug mode takes 600 ms. Half of this time is spend in the site module. And most of this time is spend in load the sysconfig module, which parse sysconfig.cfg, just to get the user site packages directory.

Attached patch adds a copy of configparser.RawConfigParser, specialized to parse sysconfig.cfg. Using this patch, Python startup is 25% faster (I didn't check in release mode).

----------
files: sysconfig_parser.patch
keywords: patch
messages: 153735
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
status: open
title: Speedup sysconfig startup
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file24572/sysconfig_parser.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14057>
_______________________________________

From report at bugs.python.org  Mon Feb 20 00:47:36 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Feb 2012 23:47:36 +0000
Subject: [issue11051] Improve Python 3.3 startup time
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1329695256.96.0.651850038578.issue11051@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I opened the issue #14057 for the sysconfig parser.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11051>
_______________________________________

From report at bugs.python.org  Mon Feb 20 00:48:54 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Feb 2012 23:48:54 +0000
Subject: [issue14057] Speedup sysconfig startup
In-Reply-To: <1329695235.07.0.0035365594313.issue14057@psf.upfronthosting.co.za>
Message-ID: <1329695334.94.0.0508619464928.issue14057@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

To speed up python -s, the following patch avoids loading the sysconfig module:

diff --git a/Lib/site.py b/Lib/site.py
--- a/Lib/site.py
+++ b/Lib/site.py
@@ -518,7 +518,8 @@ def main():
     known_paths = removeduppaths()
     if ENABLE_USER_SITE is None:
         ENABLE_USER_SITE = check_enableusersite()
-    known_paths = addusersitepackages(known_paths)
+    if ENABLE_USER_SITE:
+        known_paths = addusersitepackages(known_paths)
     known_paths = addsitepackages(known_paths)
     if sys.platform == 'os2emx':
         setBEGINLIBPATH()

I don't know if this patch is correct.

----------
nosy: +eric.araujo, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14057>
_______________________________________

From report at bugs.python.org  Mon Feb 20 00:58:44 2012
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 19 Feb 2012 23:58:44 +0000
Subject: [issue14057] Speedup sysconfig startup
In-Reply-To: <1329695235.07.0.0035365594313.issue14057@psf.upfronthosting.co.za>
Message-ID: <1329695924.08.0.208050035223.issue14057@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14057>
_______________________________________

From report at bugs.python.org  Mon Feb 20 01:21:52 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Feb 2012 00:21:52 +0000
Subject: [issue14057] Speedup sysconfig startup
In-Reply-To: <1329695235.07.0.0035365594313.issue14057@psf.upfronthosting.co.za>
Message-ID: <1329697312.31.0.605767714312.issue14057@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The site.getusersitepackages, site.addusersitepackages and co. functions all call one function which makes sure site.USER_SITE is set according to envvars and command-line options; under python -s, addusersitepackages will not add the user site dir to sys.path, but it will cause site.USER_SITE to be set (to False), so that?s why I can?t be sure that your patch does not change behavior.  test_site has good coverage for IIRC (just not sure if it covers starting python -s/-S and then importing site, and python -s/-S then import site then call site.main).

I regret that all these site functions are public, now we can?t simplify them to have the setting of site.USER_SITE in only one place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14057>
_______________________________________

From report at bugs.python.org  Mon Feb 20 01:22:50 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 20 Feb 2012 00:22:50 +0000
Subject: [issue14057] Speedup sysconfig startup
In-Reply-To: <1329695235.07.0.0035365594313.issue14057@psf.upfronthosting.co.za>
Message-ID: <1329697370.33.0.652081055853.issue14057@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/issue14057>
_______________________________________

From report at bugs.python.org  Mon Feb 20 01:36:52 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Feb 2012 00:36:52 +0000
Subject: [issue14054] test_importlib failures under Windows
In-Reply-To: <1329671441.02.0.700049402355.issue14054@psf.upfronthosting.co.za>
Message-ID: <E1RzHFK-0003mJ-Qn@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5b4b70bd2b6f by Brett Cannon in branch 'default':
Fix a failing importlib test under Windows.
http://hg.python.org/cpython/rev/5b4b70bd2b6f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14054>
_______________________________________

From report at bugs.python.org  Mon Feb 20 01:38:22 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 20 Feb 2012 00:38:22 +0000
Subject: [issue14054] test_importlib failures under Windows
In-Reply-To: <1329671441.02.0.700049402355.issue14054@psf.upfronthosting.co.za>
Message-ID: <1329698302.04.0.960724793491.issue14054@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14054>
_______________________________________

From report at bugs.python.org  Mon Feb 20 01:38:27 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 20 Feb 2012 00:38:27 +0000
Subject: [issue14054] test_importlib failures under Windows
In-Reply-To: <1329671441.02.0.700049402355.issue14054@psf.upfronthosting.co.za>
Message-ID: <1329698307.16.0.949088048327.issue14054@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
stage: needs patch -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14054>
_______________________________________

From report at bugs.python.org  Mon Feb 20 01:39:43 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 20 Feb 2012 00:39:43 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1329698383.55.0.596976964848.issue13627@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Good news: the _ssl module builds OK, the ssl module can be imported, and test_ssl now has no failures on Mac OS X 10.5.8 / OpenSSL 0.9.7 :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Mon Feb 20 01:45:47 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 20 Feb 2012 00:45:47 +0000
Subject: [issue14058] test_sys has started failing
Message-ID: <1329698747.36.0.192554030731.issue14058@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

vinay at eta-natty:~/tools/cpython$ ./python Lib/test/regrtest.py test_sys
[1/1] test_sys
test test_sys failed -- Traceback (most recent call last):
  File "/home/vinay/tools/cpython/Lib/test/test_sys.py", line 737, in test_objecttypes
    class c():
  File "/home/vinay/tools/cpython/Lib/test/test_sys.py", line 745, in c
    check(foo, size(h + 'P'))
  File "/home/vinay/tools/cpython/Lib/test/test_sys.py", line 616, in check_sizeof
    self.assertEqual(result, size, msg)
AssertionError: 28 != 24 : wrong size for <class 'staticmethod'>: got 28, expected 24

1 test failed:
    test_sys

Failure on Ubuntu Natty (32-bit) and also occurs on Mac OS X 10.5.8.

----------
components: Library (Lib)
messages: 153741
nosy: vinay.sajip
priority: normal
severity: normal
status: open
title: test_sys has started failing
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14058>
_______________________________________

From report at bugs.python.org  Mon Feb 20 01:47:01 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Feb 2012 00:47:01 +0000
Subject: [issue14058] test_sys has started failing
In-Reply-To: <1329698747.36.0.192554030731.issue14058@psf.upfronthosting.co.za>
Message-ID: <1329698821.8.0.321091316197.issue14058@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think Benjamin just fixed that.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14058>
_______________________________________

From report at bugs.python.org  Mon Feb 20 01:47:41 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Feb 2012 00:47:41 +0000
Subject: [issue14058] test_sys has started failing
In-Reply-To: <1329698747.36.0.192554030731.issue14058@psf.upfronthosting.co.za>
Message-ID: <1329698861.4.0.608372777292.issue14058@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

http://hg.python.org/cpython/rev/ecaf7ace5169

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14058>
_______________________________________

From report at bugs.python.org  Mon Feb 20 01:52:18 2012
From: report at bugs.python.org (Matt Joiner)
Date: Mon, 20 Feb 2012 00:52:18 +0000
Subject: [issue14059] Implement multiprocessing.Barrier
Message-ID: <1329699138.74.0.937439869593.issue14059@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

There is no Barrier in multiprocessing corresponding to threading.Barrier.

----------
components: Library (Lib)
messages: 153744
nosy: anacrolix
priority: normal
severity: normal
status: open
title: Implement multiprocessing.Barrier
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14059>
_______________________________________

From report at bugs.python.org  Mon Feb 20 01:52:57 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Feb 2012 00:52:57 +0000
Subject: [issue13605] document argparse's nargs=REMAINDER
In-Reply-To: <1323955710.42.0.753468095058.issue13605@psf.upfronthosting.co.za>
Message-ID: <1329699177.47.0.805700810902.issue13605@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have added the missing ?::? before code blocks (one was added by the patch you committed, others were already here).

I?m not entirely sure they are needed (Python code blocks seem to be autodetected and show up colorized too), but I did it for consistency (and to make my editor detect them).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13605>
_______________________________________

From report at bugs.python.org  Mon Feb 20 01:55:12 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 20 Feb 2012 00:55:12 +0000
Subject: [issue12837] Patch for issue #12810 removed a valid check on socket
	ancillary data
In-Reply-To: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za>
Message-ID: <1329699312.22.0.607539236323.issue12837@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Since we never solved this I'm still getting compiler warnings. Can we decide on a solution for this so I can go back to be warning-free (sans `-Wno-unused-value -Wno-empty-body -Qunused-arguments`)?


/Users/bcannon/Developer/repo/cpython/bootstrap_importlib/Modules/socketmodule.c:1439:22: warning: comparison of unsigned expression < 0 is always false
      [-Wtautological-compare]
        if (flowinfo < 0 || flowinfo > 0xfffff) {
            ~~~~~~~~ ^ ~
/Users/bcannon/Developer/repo/cpython/bootstrap_importlib/Modules/socketmodule.c:1948:74: warning: comparison of unsigned expression < 0 is always false
      [-Wtautological-compare]
    if (cmsgh == NULL || msg->msg_control == NULL || msg->msg_controllen < 0)
                                                     ~~~~~~~~~~~~~~~~~~~ ^ ~
/Users/bcannon/Developer/repo/cpython/bootstrap_importlib/Modules/socketmodule.c:5062:18: warning: comparison of unsigned expression < 0 is always false
      [-Wtautological-compare]
    if (flowinfo < 0 || flowinfo > 0xfffff) {
        ~~~~~~~~ ^ ~
3 warnings generated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12837>
_______________________________________

From report at bugs.python.org  Mon Feb 20 01:55:40 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Feb 2012 00:55:40 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>
Message-ID: <E1RzHXX-0005JT-1P@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset bbaab666e6c7 by Antoine Pitrou in branch 'default':
Issue #14043: Speed up importlib's _FileFinder by at least 8x, and add a new importlib.invalidate_caches() function.
http://hg.python.org/cpython/rev/bbaab666e6c7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Mon Feb 20 01:56:06 2012
From: report at bugs.python.org (Matt Joiner)
Date: Mon, 20 Feb 2012 00:56:06 +0000
Subject: [issue14060] Implement a CSP-style channel
Message-ID: <1329699366.61.0.518357475552.issue14060@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

>From the mailing list, there is some interest in a CSP-style channel. http://mail.python.org/pipermail/python-ideas/2012-February/014073.html

----------
components: Library (Lib)
messages: 153748
nosy: anacrolix
priority: normal
severity: normal
status: open
title: Implement a CSP-style channel
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14060>
_______________________________________

From report at bugs.python.org  Mon Feb 20 01:57:36 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Feb 2012 00:57:36 +0000
Subject: [issue14043] Speed-up importlib's _FileFinder
In-Reply-To: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>
Message-ID: <1329699456.29.0.8583694751.issue14043@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed now (with invalidate_caches() as well).

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14043>
_______________________________________

From report at bugs.python.org  Mon Feb 20 02:03:24 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 20 Feb 2012 01:03:24 +0000
Subject: [issue14052] importlib mixes up '.' and os.getcwd()
In-Reply-To: <1329597527.35.0.680600221226.issue14052@psf.upfronthosting.co.za>
Message-ID: <1329699804.42.0.241519198292.issue14052@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/issue14052>
_______________________________________

From report at bugs.python.org  Mon Feb 20 02:05:03 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Feb 2012 01:05:03 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1329645646.79.0.800047908372.issue13703@psf.upfronthosting.co.za>
Message-ID: <1329699702.1819.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> With PYTHONHASHSEED=random, at least those tests still fail:
> test_descr test_json test_set test_ttk_textonly test_urllib
> 
> Do we want to fix them in 3.1?

I don't know, but we'll have to fix them in 3.2 to avoid breaking the
buildbots. So we might also fix them in 3.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Mon Feb 20 02:09:06 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 20 Feb 2012 01:09:06 +0000
Subject: [issue14055] Implement __sizeof__ for etree Element
In-Reply-To: <1329683326.4.0.779702582093.issue14055@psf.upfronthosting.co.za>
Message-ID: <1329700146.87.0.853016174823.issue14055@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/issue14055>
_______________________________________

From report at bugs.python.org  Mon Feb 20 02:22:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Feb 2012 01:22:07 +0000
Subject: [issue14027] distutils2 lack of pysetup.bat
In-Reply-To: <1329373939.69.0.162264279004.issue14027@psf.upfronthosting.co.za>
Message-ID: <1329700927.19.0.0528955068059.issue14027@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

[Paul]
> %~dp0\..\python.exe locates python relative to the batch file (one directory up) so will work as long
> as the bat file is in Scripts. The @ just suppresses echo of the command.

Okay, so a pysetup.bat script installed by pythonX.Y.exe will be put in that Python?s Scripts directory and will call that Python when invoked.  Sounds good.

>> - Aren?t there issues with .bat scripts (or maybe it?s with .com scripts, I never remember)?
> Yes. They don't nest, so to invoke pysetup in a batch file, you need to write "call pysetup.bat". If
> you just use "pysetup", the command never returns causing silent failures. Personally, I hate bat files
> for this reason alone, but others seem happy to put up with them.

Noted.  (I?ve been reading old mailing list archives and found this sort of criticism in bat vs. com discussions.)

>> - Shouldn?t we install a pysetup.py script instead?
> That would be better, in my view.

Okay, I can do this for the short term.  ??.? (sorry if that does not read right, I seem to have font problems), would that satisfy you?

>> - Shouldn?t we generate an .exe file instead (see #12394)?
> exe files probably give the best user experience, but are opaque which is mildly annoying. Also, test
> very carefully on Win7. I have a vague recollection that exes with setup and/or install in the names
> invoke UAC, which is a complete pain. easy_install suffers from this, I believe.

Oh dear, what an horror story.  I really wish we won?t have to rename pysetup, it?s the only generic and available name we could agree on.

> Personally, "python -m packaging.run" works fine for me. I'd prefer not to have a pysetup command at
> all, and change the documentation to refer to the python -m form throughout. Second best would be an exe,
> third would be pysetup.py (but again, the docs need changing), and finally a bat file.

Thanks for the feedback.  I don?t think we?re going to move away from a main script; we?re making packaging more useful and more robust, and having a script is IMO a message as well as a convenience.


[Vinay]
> After that, I agree with Paul's ordering of .exe, with the setup script having to be named
> pysetup-script.py if we use the "standard" mechanism, or else if we use a custom .exe, it can of course
> be called whatever we want.

I don?t understand the notions of standard vs. custom.  Does standard mean setuptools?  #12394 is not quite ready yet, so nothing is set in stone, but if possible I?d prefer to generate pysetup.exe.  Let?s move the sub-discussion there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14027>
_______________________________________

From report at bugs.python.org  Mon Feb 20 02:22:50 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Feb 2012 01:22:50 +0000
Subject: [issue14027] Add pysetup script for Windows
In-Reply-To: <1329373939.69.0.162264279004.issue14027@psf.upfronthosting.co.za>
Message-ID: <1329700970.72.0.17547579421.issue14027@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> eric.araujo
title: distutils2 lack of pysetup.bat -> Add pysetup script for Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14027>
_______________________________________

From report at bugs.python.org  Mon Feb 20 02:27:18 2012
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 20 Feb 2012 01:27:18 +0000
Subject: [issue14027] Add pysetup script for Windows
In-Reply-To: <1329373939.69.0.162264279004.issue14027@psf.upfronthosting.co.za>
Message-ID: <1329701238.25.0.364935064696.issue14027@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

I'd rather we not add a batch file and choose one of the other options outlined above. I haven't used this new pysetup thing so I'm not familiar with which would be the best experience, but in other cases all of the ones listed are better than batch files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14027>
_______________________________________

From report at bugs.python.org  Mon Feb 20 02:31:04 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 20 Feb 2012 01:31:04 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1329701464.37.0.0315343600197.issue13703@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

+1 for fixing all tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Mon Feb 20 02:55:05 2012
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 20 Feb 2012 01:55:05 +0000
Subject: [issue11698] Improve repr for structseq objects to show named,
	but unindexed fields
In-Reply-To: <1301264097.04.0.982421975108.issue11698@psf.upfronthosting.co.za>
Message-ID: <1329702905.89.0.516945800941.issue11698@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

I'd like to work on this issue. I found the Objects/structseq.c [1] file. Am I on the right path?

Thanks!

[1] http://hg.python.org/cpython/file/5b4b70bd2b6f/Objects/structseq.c#l157

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11698>
_______________________________________

From report at bugs.python.org  Mon Feb 20 02:56:39 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Feb 2012 01:56:39 +0000
Subject: [issue11698] Improve repr for structseq objects to show named,
	but unindexed fields
In-Reply-To: <1301264097.04.0.982421975108.issue11698@psf.upfronthosting.co.za>
Message-ID: <1329702999.8.0.878397334982.issue11698@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

You are!  See the devguide for more setup guidelines.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11698>
_______________________________________

From report at bugs.python.org  Mon Feb 20 03:06:16 2012
From: report at bugs.python.org (Scott Bowman)
Date: Mon, 20 Feb 2012 02:06:16 +0000
Subject: [issue14005] IDLE Crash when running/saving a file
In-Reply-To: <1329173466.12.0.791681771945.issue14005@psf.upfronthosting.co.za>
Message-ID: <1329703576.15.0.718458245956.issue14005@psf.upfronthosting.co.za>


Scott Bowman <scott.thomas.bowman at gmail.com> added the comment:

Well it seems like all I needed to do was restart my machine. Everything is working fine now. Thanks for your responses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14005>
_______________________________________

From report at bugs.python.org  Mon Feb 20 03:13:32 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Feb 2012 02:13:32 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <1324386392.48.0.968435833624.issue13641@psf.upfronthosting.co.za>
Message-ID: <1329704012.2.0.643319009488.issue13641@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK' I'm back to being 100% on the side of rejecting both of these changes.  ASCII is not unocode, it is bytes.  You can decode it to unicode but it is not unicode.  Those transformations operate bytes to bytes, not bytes to unicode.

We made the bytes unicode separation to avoid the problem where you have a working program that unexpectedly gets non ASCII input and blows up with a unicode error.  IMO these patches are reintroducing that problem.  The programer should have to explicitly encode to ASCII if they are inadvisedly workimg with it in a string as part of a wire protocol (why else would they be using these transforms).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Mon Feb 20 03:19:39 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Feb 2012 02:19:39 +0000
Subject: [issue14013] tarfile should expose supported formats
In-Reply-To: <1329236847.51.0.270430673151.issue14013@psf.upfronthosting.co.za>
Message-ID: <1329704379.77.0.821033351466.issue14013@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the quick reply.

> I think it is good style to let tarfile figure out which supported compression methods are
> available instead of shutil or the user.
Note that shutil will not be wholly transparent when I?m done with the refactoring, as it will be able to translate 'xztar', 'bztar' and 'gztar' to tarfile mode strings, but will need to have a special case to morph 'bztar' to 'bz2'.  It will be a small ugliness.

(There will also be ugliness in packaging: Even if I make it transparently supports all formats that shutil supports, I?ll need to have a bit of duplication because packaging has a preferred format by platform.  Well.)

> Following 3.3's crypt module, I think the name `methods' is superior to `formats' (maybe
> `compression_methods' is even better).
Note that crypt?s methods really are instances of something called Method.  hashlib has algorithms_guaranteed and algorithms_available since 3.2 and shutil uses get_archive_formats and get_unpack_formats.  I went for tarfile.compression_formats.

> Also, crypt's concept of a sorted list from stronger to weaker could also make sense here:
Sure.  In my first patch I put gz first as it should be universally available, and then put xz before bz2 as I think bz2 is quickly losing ground to xz (even GNU and Debian are switching to xz for their archives).  The attached patch follows your idea.

BTW I will gladly wait for commits related to the other bugs (misc bugs and misc doc edits) and refresh my patch then.

----------
Added file: http://bugs.python.org/file24573/add-tarfile.compression_formats.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14013>
_______________________________________

From report at bugs.python.org  Mon Feb 20 03:21:46 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Feb 2012 02:21:46 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <1329704012.2.0.643319009488.issue13641@psf.upfronthosting.co.za>
Message-ID: <1329704305.1819.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> OK' I'm back to being 100% on the side of rejecting both of these
> changes.  ASCII is not unocode, it is bytes.  You can decode it to
> unicode but it is not unicode.  Those transformations operate bytes to
> bytes, not bytes to unicode.

ASCII is just a subset of the unicode character set.

> We made the bytes unicode separation to avoid the problem where you
> have a working program that unexpectedly gets non ASCII input and
> blows up with a unicode error.

How is blowing up with a unicode error worse than blowing up with a
ValueError? Both indicate wrong input. At worse the code could catch
UnicodeError and re-raise it as ValueError, but I don't see the point.

> The programer should have to explicitly encode to ASCII if they are
> inadvisedly workimg with it in a string as part of a wire protocol
> (why else would they be using these transforms).

Inadvisedly? There are many situations where you can have base64 data in
some unicode strings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Mon Feb 20 03:24:10 2012
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Feb 2012 02:24:10 +0000
Subject: [issue14005] IDLE Crash when running/saving a file
In-Reply-To: <1329173466.12.0.791681771945.issue14005@psf.upfronthosting.co.za>
Message-ID: <1329704650.07.0.907461820603.issue14005@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14005>
_______________________________________

From report at bugs.python.org  Mon Feb 20 03:31:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Feb 2012 02:31:07 +0000
Subject: [issue14061] Clean up archiving code in shutil
Message-ID: <1329705067.15.0.02936958618.issue14061@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

shutil.make_archive suffers from these issues:

- It always supports the 'zip' and 'gztar' formats but if Python is built without zlib then they won?t work.  Even if this is probably rare, the code should be robust.  Likewise, the tests detect the availability of bz2 but not zlib/gzip.

- If zipfile is not found, it tries to call a zip program.  I think this approach (inherited from distutils, which did that before zipfile and tarfile were in the stdlib) should be dropped.  I don?t like shutil using distutils.spawn, I don?t like a Python module calling an external program, and I think nearly everyone has a Python compiled with zlib now.

I want to work on a patch to fix this.  The first point would not change the behavior for most users, it would only modify the list of formats ?guaranteed? by the docs, so I think it?s okay for stable branches; the second point is probably inappropriate for stable branches.

----------
components: Library (Lib)
messages: 153760
nosy: eric.araujo, georg.brandl, nadeem.vawda, tarek
priority: normal
severity: normal
status: open
title: Clean up archiving code in shutil
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14061>
_______________________________________

From report at bugs.python.org  Mon Feb 20 03:33:48 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Feb 2012 02:33:48 +0000
Subject: [issue5411] shutil should support all formats supported by tarfile
	automatically
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1329705228.53.0.0622087610302.issue5411@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: add xz compression support to shutil -> shutil should support all formats supported by tarfile automatically

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5411>
_______________________________________

From report at bugs.python.org  Mon Feb 20 03:33:56 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Feb 2012 02:33:56 +0000
Subject: [issue5411] shutil should support all formats supported by tarfile
	automatically
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1329705236.92.0.809827687227.issue5411@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file24433/shutil-xz.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5411>
_______________________________________

From report at bugs.python.org  Mon Feb 20 03:34:02 2012
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 20 Feb 2012 02:34:02 +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: <1329705242.5.0.392164752609.issue3561@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Attached is an in-progress patch.

I still need to figure out how to hook up the GUI to condition the path manipulation. A few locations have said to do conditional environment modification via the Component table, but I haven't been able to get some placeholder in there based on whether or not PREPEND is true/false from the GUI.

Right now if you build an installer with this it will always modify the path even if you haven't chosen the option to do so.

http://briancurtin.com/python-dev/python-3.3.15390.msi is an example installer. Note that it's not a signed installer, it's unofficial, and I don't support it whatsoever. It's merely provided as a sample of what the GUI looks like, and you can install it, see what happens, then uninstall and see that the path modification is properly undone.

----------
assignee:  -> brian.curtin
keywords: +patch
Added file: http://bugs.python.org/file24574/prependpath_in-progress.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3561>
_______________________________________

From report at bugs.python.org  Mon Feb 20 03:35:56 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Feb 2012 02:35:56 +0000
Subject: [issue5411] shutil should support all formats supported by tarfile
	automatically
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1329705356.29.0.747013437388.issue5411@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
dependencies: +Clean up archiving code in shutil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5411>
_______________________________________

From report at bugs.python.org  Mon Feb 20 04:42:02 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 20 Feb 2012 03:42:02 +0000
Subject: [issue11698] Improve repr for structseq objects to show named,
	but unindexed fields
In-Reply-To: <1301264097.04.0.982421975108.issue11698@psf.upfronthosting.co.za>
Message-ID: <1329709322.6.0.406894986554.issue11698@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/issue11698>
_______________________________________

From report at bugs.python.org  Mon Feb 20 05:01:28 2012
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 20 Feb 2012 04:01:28 +0000
Subject: [issue14060] Implement a CSP-style channel
In-Reply-To: <1329699366.61.0.518357475552.issue14060@psf.upfronthosting.co.za>
Message-ID: <1329710488.02.0.465141320155.issue14060@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/issue14060>
_______________________________________

From report at bugs.python.org  Mon Feb 20 05:06:43 2012
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 20 Feb 2012 04:06:43 +0000
Subject: [issue14060] Implement a CSP-style channel
In-Reply-To: <1329699366.61.0.518357475552.issue14060@psf.upfronthosting.co.za>
Message-ID: <1329710803.22.0.804055832901.issue14060@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Note that Go channels have an optional buffer.  That makes them more like the queue module, except the latter doesn't support zero-sized queues.  How hard would it be to add that?  And are there really use cases in Python for unbuffered channels?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14060>
_______________________________________

From report at bugs.python.org  Mon Feb 20 06:06:46 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 20 Feb 2012 05:06:46 +0000
Subject: [issue14053] Make patchcheck compatible with MQ
In-Reply-To: <1329661471.35.0.733956428931.issue14053@psf.upfronthosting.co.za>
Message-ID: <1329714406.16.0.924511121299.issue14053@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Actually I would change the devguide/patch.html page to focus less on mq (but this is a bit orthogonal).
The easiest thing to do is to make some changes and use "hg diff > patch.diff" and the devguide should advertise this IMHO.  This also works fine with `make patchcheck`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14053>
_______________________________________

From report at bugs.python.org  Mon Feb 20 06:43:49 2012
From: report at bugs.python.org (Jan Kratochvil)
Date: Mon, 20 Feb 2012 05:43:49 +0000
Subject: [issue10112] Use -Wl, --dynamic-list=x.list,
	not -Xlinker -export-dynamic
In-Reply-To: <1287137785.61.0.962664170792.issue10112@psf.upfronthosting.co.za>
Message-ID: <1329716629.07.0.66971663367.issue10112@psf.upfronthosting.co.za>


Jan Kratochvil <jan.kratochvil at redhat.com> added the comment:

There was a bug for non-shared build of Python, thanks.

This patch is an improvement on its but it is not yet complete.
One should also replace "-Xlinker -export-dynamic" by "-Wl,--dynamic-list" so that linking application with libpython is no longer intrusive.

But I found out GDB does not need to be affected by this Bug.  When I use -fvisibility=hidden for GDB .c files then "-Xlinker -export-dynamic" has no longer any negative effect (GDB was using only "-Wl,--dynamic-list" now which works without libpython but not with libpython). Therefore I no longer mind much about this Bug.

Still at least:
1771024 libpython2.7.so.1.0
->
1757776 libpython2.7.so.1.0

Even with clean tree the upstream build generates for me:
Python build finished, but the necessary bits to build these modules were not found:
_bsddb             _ssl               bsddb185
dl                 imageop            sunaudiodev

(so sunaudiodev.c was changed without any testing of it)

----------
Added file: http://bugs.python.org/file24575/hidden4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10112>
_______________________________________

From report at bugs.python.org  Mon Feb 20 06:43:59 2012
From: report at bugs.python.org (Jan Kratochvil)
Date: Mon, 20 Feb 2012 05:43:59 +0000
Subject: [issue10112] Use -Wl, --dynamic-list=x.list,
	not -Xlinker -export-dynamic
In-Reply-To: <1287137785.61.0.962664170792.issue10112@psf.upfronthosting.co.za>
Message-ID: <1329716639.24.0.0307029246133.issue10112@psf.upfronthosting.co.za>


Changes by Jan Kratochvil <jan.kratochvil at redhat.com>:


Removed file: http://bugs.python.org/file24221/hidden.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10112>
_______________________________________

From report at bugs.python.org  Mon Feb 20 08:14:24 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 20 Feb 2012 07:14:24 +0000
Subject: [issue13605] document argparse's nargs=REMAINDER
In-Reply-To: <1329699177.47.0.805700810902.issue13605@psf.upfronthosting.co.za>
Message-ID: <CAPdtAj0apsz2oi15MwAACWRTQ9Hde+TCioxRWEyi7Z8Q1nrFng@mail.gmail.com>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

On Mon, Feb 20, 2012 at 01:52, ?ric Araujo <report at bugs.python.org> wrote:
> I?m not entirely sure they are needed (Python code blocks seem to be autodetected and show up colorized too), but I did it for consistency (and to make my editor detect them).

Yeah, I refrained to add them since the code blocks were already
correctly identified; but consistency is Good :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13605>
_______________________________________

From report at bugs.python.org  Mon Feb 20 09:03:29 2012
From: report at bugs.python.org (Michal Sladek)
Date: Mon, 20 Feb 2012 08:03:29 +0000
Subject: [issue14062] UTF-8 Email Subject problem
Message-ID: <1329725009.21.0.0898146100656.issue14062@psf.upfronthosting.co.za>


New submission from Michal Sladek <michal at sladkovi.eu>:

Hello!

I think there is a problem when adding UTF-8 subject to email message. I wrote following function (its code is based on examples I found in offical docs) which should send an email with UTF-8 subject, UTF-8 plain text body and attached file when all arguments are given. 
fromAddr - address of sender
toAddr - address of recipient
subject - subject
body - text of email body
attachment - full path to file we want to attach

Here is the code:

def sendMail (fromAddr, toAddr, subject, body = '', attachment = ''):
    message = email.mime.multipart.MIMEMultipart()
    message.add_header('From',fromAddr)
    message.add_header('To',toAddr)

    message['Subject'] = email.header.Header(subject,'utf-8')

    if (body != ''):
        msgPart = email.mime.text.MIMEText(body,'plain','utf-8')
        message.attach(msgPart)
    if (attachment != ''):
        if os.path.exists(attachment) == True:
            filename = attachment.rpartition(os.sep)[2]
            fp = open(attachment,'rb')
            msgPart = email.mime.base.MIMEBase('application','octet-stream')
            msgPart.set_payload(fp.read())
            fp.close()
            email.encoders.encode_base64(msgPart)
            msgPart.add_header('Content-Disposition','attachment',filename=filename)
            message.attach(msgPart)
    if smtpPort == 25:
        smtpCon = smtplib.SMTP(smtpSrv,smtpPort)
    else:
        smtpCon = smtplib.SMTP_SSL(smtpSrv,smtpPort)
    if (smtpUser != '') and (smtpPass != ''):
        smtpCon.login(smtpUser,smtpPass)
    smtpCon.send_message(message,mail_options=['UTF8SMTP','8BITMIME'])
    smtpCon.quit()

Running the function with following arguments:

sendMail('rzrobot at seznam.cz','msladek at volny.cz','?lu?ou?k? k??','?p?l ??belsk? ?dy')

produces following output on receiving side:

Return-Path: <rzrobot at seznam.cz>
Received: from smtp2.seznam.cz (smtp2.seznam.cz [77.75.76.43])
	by mx1.volny.cz (Postfix) with ESMTP id DD6BB2E09CD
	for <msladek at volny.cz>; Mon, 20 Feb 2012 08:34:38 +0100 (CET)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=seznam.cz;
	h=Received:Content-Type:MIME-Version:From:To:Subject:--===============1029508565==:MIME-Version:Content-Transfer-Encoding:X-Smtpd:X-Seznam-User:X-Session:X-Country:X-Virus-Info:X-Seznam-SPF:X-Seznam-DomainKeys;
	b=cdU1VSRTCDf0x2CeBNbLJxYSOhSy7r9lNp+1s7+bed6AGBI48vufe3q7f8JFxlfTc
	ulZIDptWi6PMvlZYCBkh1uzTKcihZR7MCoxgW0PJLO1LX5elTJsZ/GTc5oe/GZXkTPT
	qwj1EQIlVn0dpZtt4jIzfC2RrO2IRieR2rozeQM=
Received: from dvr.ph.sladkovi.eu (ip-84-42-150-218.net.upcbroadband.cz [84.42.150.218])	by email-relay2.ng.seznam.cz (Seznam SMTPD 1.2.15-6 at 18976) with ESMTP;	Mon, 20 Feb 2012 08:34:35 +0100 (CET)  
Content-Type: multipart/mixed; boundary="===============1029508565=="
MIME-Version: 1.0
From: rzrobot at seznam.cz
To: msladek at volny.cz
Subject: =?utf-8?b?xb5sdcWlb3XEjWvDvSBrxa/FiA==?= 
X-DKIM-Status: fail
X-Virus: no (m2.volny.internal - Mon, 20 Feb 2012 08:34:40 +0100 (CET))
X-Spam: no (m2.volny.internal - Mon, 20 Feb 2012 08:34:41 +0100 (CET))
X-Received-Date: Mon, 20 Feb 2012 08:34:42 +0100 (CET)

--===============1029508565==:Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
X-Smtpd: 1.2.15-6 at 18976
X-Seznam-User: rzrobot at seznam.cz
X-Session: 11
X-Country: CZ
X-Virus-Info:clean
X-Seznam-SPF:neutral
X-Seznam-DomainKeys:unknown

w7pwxJtsIMSPw6FiZWxza8OpIMOzZHk=

--===============1029508565==--

Although no attachment argument was given, the client says that message has an attachment of unknown type and that message does not contain any text at all. See that message part header :Content-Type: text/plain; charset="utf-8" is part of the message part boundary instead of beeing inside of the message part.

When I change the code of function to generate the subject manually and add it via add_header like this:

def sendMail (fromAddr, toAddr, subject, body = '', attachment = ''):
    message = email.mime.multipart.MIMEMultipart()
    message.add_header('From',fromAddr)
    message.add_header('To',toAddr)

    base64Subject = base64.b64encode(subject.encode('utf-8')).decode()
    encodedSubject = '=?UTF-8?B?{0}?='.format(base64Subject)
    message.add_header('Subject',encodedSubject)

    if (body != ''):
        msgPart = email.mime.text.MIMEText(body,'plain','utf-8')
        message.attach(msgPart)
    if (attachment != ''):
        if os.path.exists(attachment) == True:
            filename = attachment.rpartition(os.sep)[2]
            fp = open(attachment,'rb')
            msgPart = email.mime.base.MIMEBase('application','octet-stream')
            msgPart.set_payload(fp.read())
            fp.close()
            email.encoders.encode_base64(msgPart)
            msgPart.add_header('Content-Disposition','attachment',filename=filename)
            message.attach(msgPart)
    if smtpPort == 25:
        smtpCon = smtplib.SMTP(smtpSrv,smtpPort)
    else:
        smtpCon = smtplib.SMTP_SSL(smtpSrv,smtpPort)
    if (smtpUser != '') and (smtpPass != ''):
        smtpCon.login(smtpUser,smtpPass)
    smtpCon.send_message(message,mail_options=['UTF8SMTP','8BITMIME'])
    smtpCon.quit()

Then everything is OK on receiving side, both subject and plaint text body are visible:

Return-Path: <rzrobot at seznam.cz>
Received: from smtp2.seznam.cz (smtp2.seznam.cz [77.75.76.43])
	by mx1.volny.cz (Postfix) with ESMTP id 177092E0825
	for <msladek at volny.cz>; Mon, 20 Feb 2012 08:51:58 +0100 (CET)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=seznam.cz;
	h=Received:Content-Type:MIME-Version:From:To:Subject:X-Smtpd:X-Seznam-User:X-Session:X-Country:X-Virus-Info:X-Seznam-SPF:X-Seznam-DomainKeys;
	b=F2A6GhX0TWVjnrB4vx/ayc1BTGDFxBI96oI0fk/gr/tgP0jlV1UC91m4i/O4ay+Bg
	lfka88qa71XZOlHtY2vl7zxYjGPJ97pRCdtqWB+JcNOa5bMsk6lmjMHh+A+FQ2e7+yb
	1F091t0nMcQlarriF8sD5rNjhuRYjvCv7kKbt8s=
Received: from dvr.ph.sladkovi.eu (ip-84-42-150-218.net.upcbroadband.cz [84.42.150.218])	by email-relay1.ng.seznam.cz (Seznam SMTPD 1.2.15-6 at 18976) with ESMTP;	Mon, 20 Feb 2012 08:51:55 +0100 (CET)  
Content-Type: multipart/mixed; boundary="===============1044203895=="
MIME-Version: 1.0
From: rzrobot at seznam.cz
To: msladek at volny.cz
Subject: =?UTF-8?B?xb5sdcWlb3XEjWvDvSBrxa/FiA==?=
X-Smtpd: 1.2.15-6 at 18976
X-Seznam-User: rzrobot at seznam.cz
X-Session: 11
X-Country: CZ
X-Virus-Info: clean
X-Seznam-SPF: neutral
X-Seznam-DomainKeys: unknown
X-DKIM-Status: pass seznam.cz
X-Virus: no (m2.volny.internal - Mon, 20 Feb 2012 08:52:00 +0100 (CET))
X-Spam: no (m2.volny.internal - Mon, 20 Feb 2012 08:52:01 +0100 (CET))
X-Received-Date: Mon, 20 Feb 2012 08:52:01 +0100 (CET)

--===============1044203895==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

w7pwxJtsIMSPw6FiZWxza8OpIMOzZHk=

--===============1044203895==--

I am not a programmer so I might overlook some obvious mistake in my code but for now I think it's a bug.

----------
components: None
messages: 153766
nosy: msladek
priority: normal
severity: normal
status: open
title: UTF-8 Email Subject problem
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14062>
_______________________________________

From report at bugs.python.org  Mon Feb 20 09:08:51 2012
From: report at bugs.python.org (Michal Sladek)
Date: Mon, 20 Feb 2012 08:08:51 +0000
Subject: [issue14047] UTF-8 Email Header
In-Reply-To: <1329677985.32.0.446358010773.issue14047@psf.upfronthosting.co.za>
Message-ID: <CANQ64Jb=M+j_W2W1msVH-bimC4SRDHHXyorE1d5J2kdha2cNEg@mail.gmail.com>


Michal Sladek <michal at sladkovi.eu> added the comment:

Hello Martin!

Thanks for your kind words and for giving me hints how to fill the bug
report properly. I hope this time it will be accepted (ID 14062).

Best regards

Michal

Dne 19. ?nora 2012 19:59 Martin v. L?wis <report at bugs.python.org> napsal(a):
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> Michal, it's your wording of your report, and also some of the contents that caused Eric's reaction. When you conclude with "Am I doing something wrong?", then your message is *not* a bug report, but a question for help (namely, you are asking somebody to find out whether you did something wrong).
>
> Please structure bug reports as follows:
> 1. this is what I did
> 2. this is what happened
> 3. this is what I expected to happen instead
>
> Your report gives hints at 1, but neither discusses 2 or 3. I.e. you say what code you write, but you did not say (AFAICT) what parameters you passed to the function. And you did not say what happened when you passed the parameters.
>
> This is important information, as the first step of us is to reproduce the bug report, i.e. try out all your steps and see whether the same happens also when we do it (which often enough is not the case).
>
> Since this bug report is already filled with unrelated meta-discussion, please submit a new bug report in the style I explain above.
>
> ----------
> nosy: +loewis
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue14047>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14047>
_______________________________________

From report at bugs.python.org  Mon Feb 20 09:18:41 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 20 Feb 2012 08:18:41 +0000
Subject: [issue14034] first example in argparse doc is too complicated
In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za>
Message-ID: <1329725921.63.0.327975806201.issue14034@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

I chose to go the way of a howto. I find argparse complex enough to deserve one.

note: I have checked each example on the 3 releases that possess the module (2.7, 3.2, and 3.3), and the differences in output are very small.

----------
keywords: +patch
Added file: http://bugs.python.org/file24576/argparse_howto.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14034>
_______________________________________

From report at bugs.python.org  Mon Feb 20 09:24:45 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 20 Feb 2012 08:24:45 +0000
Subject: [issue14050] Tutorial, list.sort() and items comparability
In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za>
Message-ID: <1329726285.89.0.859090277623.issue14050@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

An an aside, shouldn't that be "in-place" instead of "in place (http://en.wikipedia.org/wiki/In-place)?

----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14050>
_______________________________________

From report at bugs.python.org  Mon Feb 20 09:39:10 2012
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 20 Feb 2012 08:39:10 +0000
Subject: [issue13605] document argparse's nargs=REMAINDER
In-Reply-To: <1323955710.42.0.753468095058.issue13605@psf.upfronthosting.co.za>
Message-ID: <1329727150.36.0.154270556306.issue13605@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Blocks not introduced by "::" are *NOT* code blocks.

If they happen to begin with ">>> ", they are recognized as doctest blocks and colorized as doctests.

Doctest blocks shouldn't be indented. (The indent is a blockquote in this case.)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13605>
_______________________________________

From report at bugs.python.org  Mon Feb 20 10:31:22 2012
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 20 Feb 2012 09:31:22 +0000
Subject: [issue9253] argparse: optional subparsers
In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za>
Message-ID: <1329730282.73.0.644346451607.issue9253@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

The implementation looks along the right track. Now it just needs some tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9253>
_______________________________________

From report at bugs.python.org  Mon Feb 20 11:06:33 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 20 Feb 2012 10:06:33 +0000
Subject: [issue14027] Add pysetup script for Windows
In-Reply-To: <1329373939.69.0.162264279004.issue14027@psf.upfronthosting.co.za>
Message-ID: <1329732393.22.0.508245759501.issue14027@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> I don?t understand the notions of standard vs. custom.
> Does standard mean setuptools?  #12394 is not quite ready yet, so
> nothing is set in stone, but if possible I?d prefer to generate
> pysetup.exe.  Let?s move the sub-discussion there.

Okay, we'll continue on #12394, but I'll comment here on "standard vs. custom" - by "standard", I meant the setuptools way of doing it, but not necessarily using the setuptools code - see my comment in #12394 on an alternative. The basic method is that used by setuptools, but the specific implementation is different - somescript.exe opens somescript-script.py, reads a shebang line to find which Python to invoke, then invokes it with the script. By "custom" I meant "something else" without anything specific in mind - and I'm not sure it's worth the bother and extra work of a customised pysetup.exe.

Perhaps all or at least some of this could be simplified in 3.3 if the PEP 397 launcher is included in Python. Mark Hammond has re-started discussions about this on Python-dev, and hopefully we'll have a consensus to get it in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14027>
_______________________________________

From report at bugs.python.org  Mon Feb 20 11:11:22 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Feb 2012 10:11:22 +0000
Subject: [issue10112] Use -Wl, --dynamic-list=x.list,
	not -Xlinker -export-dynamic
In-Reply-To: <1287137785.61.0.962664170792.issue10112@psf.upfronthosting.co.za>
Message-ID: <1329732682.65.0.458551428771.issue10112@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/issue10112>
_______________________________________

From report at bugs.python.org  Mon Feb 20 11:26:25 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 20 Feb 2012 10:26:25 +0000
Subject: [issue13605] document argparse's nargs=REMAINDER
In-Reply-To: <1323955710.42.0.753468095058.issue13605@psf.upfronthosting.co.za>
Message-ID: <1329733585.51.0.233173986338.issue13605@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

(this is only concerning the latest commit)

Not sure if I should open a new issue, but why is there a print function at all, given that:

>>> print(parser.parse_args('--foo B cmd --arg1 XX ZZ'.split()))
Namespace(args=['--arg1', 'XX', 'ZZ'], command='cmd', foo='B')

>>> parser.parse_args('--foo B cmd --arg1 XX ZZ'.split())
Namespace(args=['--arg1', 'XX', 'ZZ'], command='cmd', foo='B')

----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13605>
_______________________________________

From report at bugs.python.org  Mon Feb 20 11:43:23 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Feb 2012 10:43:23 +0000
Subject: [issue13846] Add time.monotonic() function
In-Reply-To: <1327364549.64.0.960699645726.issue13846@psf.upfronthosting.co.za>
Message-ID: <1329734603.91.0.482669042211.issue13846@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Boost has a monotonic time implementation (steady_clock) for OS X:
http://svn.boost.org/svn/boost/trunk/boost/chrono/detail/inlined/mac/chrono.hpp

----------
nosy: +ned.deily, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13846>
_______________________________________

From report at bugs.python.org  Mon Feb 20 11:59:41 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 20 Feb 2012 10:59:41 +0000
Subject: [issue14058] test_sys has started failing
In-Reply-To: <1329698747.36.0.192554030731.issue14058@psf.upfronthosting.co.za>
Message-ID: <1329735581.41.0.219408370903.issue14058@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Yep, works now.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14058>
_______________________________________

From report at bugs.python.org  Mon Feb 20 12:06:06 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 20 Feb 2012 11:06:06 +0000
Subject: [issue14063] test_importlib failure on Mac OS X
Message-ID: <1329735966.21.0.756949345027.issue14063@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

======================================================================
FAIL: test_insensitive (importlib.test.source.test_case_sensitivity.CaseSensitivityTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/importlib/test/source/test_case_sensitivity.py", line 56, in test_insensitive
    self.assertIn(self.name, sensitive.get_filename(self.name))
AssertionError: 'MoDuLe' not found in '/var/folders/ZN/ZNY48Gb3FyW7he0qBsYJME+++TI/-Tmp-/tmpx6934s/sensitive/module.py'

Failure occurs when tested using a framework build (make frameworkinstall) on Mac OS X 10.5.8 (Leopard).

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
messages: 153776
nosy: brett.cannon, ronaldoussoren, vinay.sajip
priority: normal
severity: normal
status: open
title: test_importlib failure on Mac OS X
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14063>
_______________________________________

From report at bugs.python.org  Mon Feb 20 13:20:50 2012
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Feb 2012 12:20:50 +0000
Subject: [issue14063] test_importlib failure on Mac OS X
In-Reply-To: <1329735966.21.0.756949345027.issue14063@psf.upfronthosting.co.za>
Message-ID: <1329740450.24.0.265506381543.issue14063@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Also fails on 10.7 standard unix (non-framework) build on case-insensitive HFS+ fils system.

----------
assignee: ronaldoussoren -> brett.cannon
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14063>
_______________________________________

From report at bugs.python.org  Mon Feb 20 13:44:22 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 20 Feb 2012 12:44:22 +0000
Subject: [issue12428] functools test coverage
In-Reply-To: <1309255638.21.0.342456839611.issue12428@psf.upfronthosting.co.za>
Message-ID: <1329741862.73.0.530848122991.issue12428@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Just noticed one minor nit with the patch: the pure Python version of functools.partial should support "func" as a keyword argument that is passed to the underlying object. The trick is to declare a positional only argument like this:

def f(*args, **kwds):
    first, *args = args
    # etc...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12428>
_______________________________________

From report at bugs.python.org  Mon Feb 20 13:50:25 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 20 Feb 2012 12:50:25 +0000
Subject: [issue12428] functools test coverage
In-Reply-To: <1309255638.21.0.342456839611.issue12428@psf.upfronthosting.co.za>
Message-ID: <1329742225.54.0.777438528076.issue12428@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Also, the closure based implementation should be decorated with @staticmethod (see http://bugs.python.org/issue11704) and the tests updated accordingly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12428>
_______________________________________

From report at bugs.python.org  Mon Feb 20 13:56:39 2012
From: report at bugs.python.org (Bithin A)
Date: Mon, 20 Feb 2012 12:56:39 +0000
Subject: [issue14064] collections module imported twice in urllib/parse.py
Message-ID: <1329742599.87.0.0630282328331.issue14064@psf.upfronthosting.co.za>


New submission from Bithin A <bithin2007 at gmail.com>:

In urllib/parse.py the collections module is imported twice which is against the PEP8-- Style Guide for Python Code.

----------
components: Library (Lib)
files: multiple_imports.patch
keywords: patch
messages: 153780
nosy: Bithin.A
priority: normal
severity: normal
status: open
title: collections module imported twice in urllib/parse.py
Added file: http://bugs.python.org/file24577/multiple_imports.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14064>
_______________________________________

From report at bugs.python.org  Mon Feb 20 13:57:49 2012
From: report at bugs.python.org (Bithin A)
Date: Mon, 20 Feb 2012 12:57:49 +0000
Subject: [issue14064] collections module imported twice in urllib/parse.py
In-Reply-To: <1329742599.87.0.0630282328331.issue14064@psf.upfronthosting.co.za>
Message-ID: <1329742669.5.0.346447083994.issue14064@psf.upfronthosting.co.za>


Changes by Bithin A <bithin2007 at gmail.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14064>
_______________________________________

From report at bugs.python.org  Mon Feb 20 13:58:28 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 20 Feb 2012 12:58:28 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1329742708.25.0.89791852459.issue6884@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> (2.7.2 doesn?t include neither Antoine?s changeset nor mine, right?)

Correct; it dates back to June last year, before issue 13193 was filed.


> Can you reproduce the ?include buildout.cfg? bug too?

Yes, that problem is present in 2.7.2, but not in the current revision of
the 2.7 branch. In 2.7.2, the offending regex is r'^build\.*' (since
translate_pattern() uses os.path.join, and doesn't escape the separator),
whereas in 2.7-head the regex is r'^build/.*' (using a hardcoded "/").
2.7-head with your patch applied gives r'^build\\.*' (the correct value).

In this case (unlike #9691 and #14004), the problem was fixed by the
changes in issue 13193, since the offending code is in the
"if prefix is not None:" codepath of translate_pattern(), rather than in
glob_to_re().


While we're talking about translate_pattern(), I have a question about
this line:

    pattern_re = "^%s/.*%s" % (prefix_re, pattern_re)

It seems that if you specify both a prefix and a (nonempty) pattern, the
resulting regexp is something like "<PREFIX>/.*<PATTERN>", using the
pattern argument as a suffix. Is this the intended behavior? I would have
expected something like "<PREFIX>/(.*/)?<PATTERN>", defaulting to
"<PREFIX>/.*" if pattern is empty. For example, it seems wrong that
"recursive-include foo bar.*" matches foo/test_bar.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Mon Feb 20 14:09:45 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Feb 2012 13:09:45 +0000
Subject: [issue14052] importlib mixes up '.' and os.getcwd()
In-Reply-To: <1329597527.35.0.680600221226.issue14052@psf.upfronthosting.co.za>
Message-ID: <1329743385.39.0.636674585899.issue14052@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There was the following sporadic buildbot failure:


======================================================================
FAIL: test_package___file__ (test.test_imp.PEP3147Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_imp.py", line 333, in test_package___file__
    os.sep.join(('.', 'pep3147', '__init__.py')))
AssertionError: 'pep3147/__init__.py' != './pep3147/__init__.py'
- pep3147/__init__.py
+ ./pep3147/__init__.py
? ++


I wonder if the test suite is playing games and sometimes using importlib :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14052>
_______________________________________

From report at bugs.python.org  Mon Feb 20 15:31:32 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 20 Feb 2012 14:31:32 +0000
Subject: [issue14064] collections module imported twice in urllib/parse.py
In-Reply-To: <1329742599.87.0.0630282328331.issue14064@psf.upfronthosting.co.za>
Message-ID: <1329748292.26.0.716637248248.issue14064@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is perfectly fine the way it is. PEP 8 has nothing to say about it.

----------
nosy: +benjamin.peterson
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14064>
_______________________________________

From report at bugs.python.org  Mon Feb 20 15:46:35 2012
From: report at bugs.python.org (Bithin A)
Date: Mon, 20 Feb 2012 14:46:35 +0000
Subject: [issue14064] collections module imported twice in urllib/parse.py
In-Reply-To: <1329742599.87.0.0630282328331.issue14064@psf.upfronthosting.co.za>
Message-ID: <1329749195.97.0.671502533741.issue14064@psf.upfronthosting.co.za>


Changes by Bithin A <bithin2007 at gmail.com>:


Removed file: http://bugs.python.org/file24577/multiple_imports.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14064>
_______________________________________

From report at bugs.python.org  Mon Feb 20 16:47:44 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 20 Feb 2012 15:47:44 +0000
Subject: [issue14062] UTF-8 Email Subject problem
In-Reply-To: <1329725009.21.0.0898146100656.issue14062@psf.upfronthosting.co.za>
Message-ID: <1329752864.17.0.800525774039.issue14062@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/issue14062>
_______________________________________

From report at bugs.python.org  Mon Feb 20 17:26:48 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 20 Feb 2012 16:26:48 +0000
Subject: [issue14065] Element should support cyclic GC
Message-ID: <1329755208.03.0.143933032526.issue14065@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

The C implementation of xml.etree.ElementTree.Element needs to support cyclic GC. The attached script demonstrates the lack to support that: in 3.2, the script passes; in 3.3 (7697223df6df) it fails with an AssertionError as the cycle was not cleared. 

This is an incompatible change from 3.2.

----------
files: a.py
messages: 153784
nosy: loewis
priority: normal
severity: normal
status: open
title: Element should support cyclic GC
versions: Python 3.3
Added file: http://bugs.python.org/file24578/a.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14065>
_______________________________________

From report at bugs.python.org  Mon Feb 20 17:32:21 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 20 Feb 2012 16:32:21 +0000
Subject: [issue14065] Element should support cyclic GC
In-Reply-To: <1329755208.03.0.143933032526.issue14065@psf.upfronthosting.co.za>
Message-ID: <1329755541.97.0.792505808862.issue14065@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/issue14065>
_______________________________________

From report at bugs.python.org  Mon Feb 20 17:33:43 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Feb 2012 16:33:43 +0000
Subject: [issue14065] Element should support cyclic GC
In-Reply-To: <1329755208.03.0.143933032526.issue14065@psf.upfronthosting.co.za>
Message-ID: <1329755623.22.0.237482864002.issue14065@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Library (Lib)
nosy: +flox
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14065>
_______________________________________

From report at bugs.python.org  Mon Feb 20 18:16:40 2012
From: report at bugs.python.org (sbt)
Date: Mon, 20 Feb 2012 17:16:40 +0000
Subject: [issue14059] Implement multiprocessing.Barrier
In-Reply-To: <1329699138.74.0.937439869593.issue14059@psf.upfronthosting.co.za>
Message-ID: <1329758200.38.0.396713097749.issue14059@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

Here is an initial implementation.  Differences from threading.Barrier:

- I have not implemented reset().

- wait() returns 0 or -1.  One thread returns 0, the remainder return -1.
  This is different to threading.Barrier where each of the N threads 
  returns a unique index in range(N).

- I added an "action_args" parameter to the constructor.  This is a tuple 
  which provides argument to the "action" callback.  (This is because closures
  are not picklable, making no-argument callbacks rather limiting for 
  multiprocessing.)

----------
nosy: +sbt
Added file: http://bugs.python.org/file24579/barrier.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14059>
_______________________________________

From report at bugs.python.org  Mon Feb 20 18:20:04 2012
From: report at bugs.python.org (sbt)
Date: Mon, 20 Feb 2012 17:20:04 +0000
Subject: [issue14059] Implement multiprocessing.Barrier
In-Reply-To: <1329699138.74.0.937439869593.issue14059@psf.upfronthosting.co.za>
Message-ID: <1329758404.48.0.424076767575.issue14059@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

barrier_tests.py contains minor modifications of the unit tests for
threading.Barrier.  (The two tests using reset() are commented out.)

The implementation passes for me on Linux and Windows.

----------
Added file: http://bugs.python.org/file24580/barrier_tests.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14059>
_______________________________________

From report at bugs.python.org  Mon Feb 20 18:24:59 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 20 Feb 2012 17:24:59 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>
Message-ID: <1329758699.68.0.734034408021.issue13447@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +francismb
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Mon Feb 20 19:08:21 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Mon, 20 Feb 2012 18:08:21 +0000
Subject: [issue14053] Make Tools/scripts/patchcheck.py compatible with
	mercurial mqueues.
In-Reply-To: <1329682395.55.0.536127757839.issue14053@psf.upfronthosting.co.za>
Message-ID: <4F428C68.8060706@email.de>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

Nice feedback !

One question :

>
>    An alternative approach that solves all three of these problems is to
>    check whether we have any patches applied (using "hg qapplied"), and if
>    this is the case, then add "--rev qbase" to the "hg status" command
>    line. This will list all files added/modified by patches as well as by
>    uncommitted changes.
>

Shouldn't be --rev qparent ? with --rev qbase the first MQ patch applied 
changes are not listed ... (one wants the changes between
qparent and qtip)

----------
title: Make patchcheck compatible with MQ -> Make Tools/scripts/patchcheck.py compatible with mercurial mqueues.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14053>
_______________________________________

From report at bugs.python.org  Mon Feb 20 19:18:06 2012
From: report at bugs.python.org (Eric Snow)
Date: Mon, 20 Feb 2012 18:18:06 +0000
Subject: [issue14057] Speedup sysconfig startup
In-Reply-To: <1329695235.07.0.0035365594313.issue14057@psf.upfronthosting.co.za>
Message-ID: <1329761886.15.0.573906428355.issue14057@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14057>
_______________________________________

From report at bugs.python.org  Mon Feb 20 19:23:08 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Feb 2012 18:23:08 +0000
Subject: [issue14052] importlib mixes up '.' and os.getcwd()
In-Reply-To: <1329743385.39.0.636674585899.issue14052@psf.upfronthosting.co.za>
Message-ID: <1329761985.3382.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

[...]

And I can't reproduce, even when using --randseed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14052>
_______________________________________

From report at bugs.python.org  Mon Feb 20 19:28:22 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 20 Feb 2012 18:28:22 +0000
Subject: [issue14063] test_importlib failure on Mac OS X
In-Reply-To: <1329735966.21.0.756949345027.issue14063@psf.upfronthosting.co.za>
Message-ID: <1329762502.63.0.158445282199.issue14063@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Antoine, do you think this may have been triggered by your latest patch?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14063>
_______________________________________

From report at bugs.python.org  Mon Feb 20 19:28:55 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 20 Feb 2012 18:28:55 +0000
Subject: [issue14052] importlib mixes up '.' and os.getcwd()
In-Reply-To: <1329597527.35.0.680600221226.issue14052@psf.upfronthosting.co.za>
Message-ID: <1329762535.0.0.847938055432.issue14052@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The test suite does use importlib for some imports as finders from importlib for some packages stick around. I brought this up a way back but people thought it was actually a good idea to let importlib handle imports to stress test it.

Anyway, if it can't be reproduced then I don't think this is worth worrying about. As Nick pointed out, everything should be absolute anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14052>
_______________________________________

From report at bugs.python.org  Mon Feb 20 19:29:12 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 20 Feb 2012 18:29:12 +0000
Subject: [issue14052] importlib mixes up '.' and os.getcwd()
In-Reply-To: <1329597527.35.0.680600221226.issue14052@psf.upfronthosting.co.za>
Message-ID: <1329762552.87.0.859370208534.issue14052@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/issue14052>
_______________________________________

From report at bugs.python.org  Mon Feb 20 19:30:31 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Feb 2012 18:30:31 +0000
Subject: [issue14063] test_importlib failure on Mac OS X
In-Reply-To: <1329762502.63.0.158445282199.issue14063@psf.upfronthosting.co.za>
Message-ID: <1329762428.3382.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, do you think this may have been triggered by your latest patch?

I don't know, perhaps Vinay can bisect to find the offending commit?
(I don't have a Mac)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14063>
_______________________________________

From report at bugs.python.org  Mon Feb 20 19:31:38 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 20 Feb 2012 18:31:38 +0000
Subject: [issue14063] test_importlib failure on Mac OS X
In-Reply-To: <1329735966.21.0.756949345027.issue14063@psf.upfronthosting.co.za>
Message-ID: <1329762698.62.0.610931532762.issue14063@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I have a Mac, but I'm heading out the door; I will see if I can diagnose it and fix it tonight or tomorrow (unless someone beats me to it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14063>
_______________________________________

From report at bugs.python.org  Mon Feb 20 19:33:49 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Feb 2012 18:33:49 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <1324386392.48.0.968435833624.issue13641@psf.upfronthosting.co.za>
Message-ID: <E1RzY3Y-0005R5-1h@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c760bd844222 by Antoine Pitrou in branch 'default':
Issue #13641: Decoding functions in the base64 module now accept ASCII-only unicode strings.
http://hg.python.org/cpython/rev/c760bd844222

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Mon Feb 20 19:34:41 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Feb 2012 18:34:41 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <1324386392.48.0.968435833624.issue13641@psf.upfronthosting.co.za>
Message-ID: <1329762881.39.0.927740145261.issue13641@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed issue13641-alternative-v1.patch. I really think practicality beats purity here and, furthermore, there's no associated danger (non-ASCII data is rejected both as bytes and str).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Mon Feb 20 19:34:54 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Feb 2012 18:34:54 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <1324386392.48.0.968435833624.issue13641@psf.upfronthosting.co.za>
Message-ID: <1329762894.49.0.955394364262.issue13641@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Mon Feb 20 19:44:38 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Feb 2012 18:44:38 +0000
Subject: [issue14040] Deprecate some of the module file formats
In-Reply-To: <1329485796.8.0.890516593146.issue14040@psf.upfronthosting.co.za>
Message-ID: <E1RzYE1-0006TJ-8l@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 42f61304f77d by Antoine Pitrou in branch 'default':
Issue #14040: Remove rarely used file name suffixes for C extensions (under POSIX mainly).
http://hg.python.org/cpython/rev/42f61304f77d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14040>
_______________________________________

From report at bugs.python.org  Mon Feb 20 19:51:38 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 20 Feb 2012 18:51:38 +0000
Subject: [issue14053] Make Tools/scripts/patchcheck.py compatible with
	mercurial mqueues.
In-Reply-To: <1329661471.35.0.733956428931.issue14053@psf.upfronthosting.co.za>
Message-ID: <1329763898.45.0.555347707686.issue14053@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Shouldn't be --rev qparent ?

Yes, that's right. I seem to confuse qbase and qparent often...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14053>
_______________________________________

From report at bugs.python.org  Mon Feb 20 19:54:02 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Feb 2012 18:54:02 +0000
Subject: [issue14040] Deprecate some of the module file formats
In-Reply-To: <1329485796.8.0.890516593146.issue14040@psf.upfronthosting.co.za>
Message-ID: <1329764042.86.0.943329423129.issue14040@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've now committed the suffix removal patch with a what's new entry. Thanks!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14040>
_______________________________________

From report at bugs.python.org  Mon Feb 20 20:01:41 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Feb 2012 19:01:41 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <E1RzYUV-00084y-Mf@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f4b7ecf8a5f8 by Georg Brandl in branch '3.1':
Issue #13703: add a way to randomize the hash values of basic types (str, bytes, datetime)
http://hg.python.org/cpython/rev/f4b7ecf8a5f8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Mon Feb 20 20:01:41 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 20 Feb 2012 19:01:41 +0000
Subject: [issue14066] Crash in imputil.imp.find_module when a *directory*
	exists with the given name due to double-close of FILE*
Message-ID: <1329764501.42.0.487589660736.issue14066@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

$ mkdir some_directory_ending_with_a.py
$ python -c "import imputil; imputil.imp.find_module('some_directory_ending_with_a')"
*** glibc detected *** python: double free or corruption (!prev): 0x0000000001589bf0 ***
Aborted

What's happening is that call_find_module opens fp, and tries to create a PyFileObject from it:

  2844     if (fp != NULL) {
>>2845         fob = PyFile_FromFile(fp, pathname, fdp->mode, fclose);
  2846         if (fob == NULL) {
  2847             fclose(fp);
  2848             return NULL;
  2849         }
  2850     }

The call fails at the very end of fill_file_fields() inside the call to dircheck() here:
   180      f->f_fp = fp;
   181      f = dircheck(f);
   182      return (PyObject *) f;
   183  }
   184  

but f->fp == fp

Hence when fill_file_fields returns NULL, and f is cleaned up here:
   484      if (fill_file_fields(f, fp, o_name, mode, close) == NULL) {
>> 485          Py_DECREF(f);
   486          Py_DECREF(o_name);
   487          return NULL;
   488      }

then f->fp is closed within file_dealloc()

Then, when PyFile_FromFile returns NULL, call_find_module calls fclose(fp):
  2844     if (fp != NULL) {
  2845         fob = PyFile_FromFile(fp, pathname, fdp->mode, fclose);
  2846         if (fob == NULL) {
>>2847             fclose(fp);
  2848             return NULL;
  2849         }
  2850     }

and it attempts to close fp for the second time.

The documentation for PyFile_FromFile:
  http://docs.python.org/c-api/file.html#PyFile_FromFile
says:
"Return NULL and close the file using close on failure".

It therefore looks like call_find_module's fclose(fp) is incorrect here, and is what leads to the double-free.

----------
components: Library (Lib)
messages: 153799
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: Crash in imputil.imp.find_module when a *directory* exists with the given name due to double-close of FILE*
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14066>
_______________________________________

From report at bugs.python.org  Mon Feb 20 21:20:46 2012
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Feb 2012 20:20:46 +0000
Subject: [issue14063] test_importlib failure on Mac OS X
In-Reply-To: <1329735966.21.0.756949345027.issue14063@psf.upfronthosting.co.za>
Message-ID: <1329769246.31.0.985863281705.issue14063@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The first bad revision is:
changeset:   75048:bbaab666e6c7
parent:      75045:5b4b70bd2b6f
user:        Antoine Pitrou <solipsis at pitrou.net>
date:        Mon Feb 20 01:48:16 2012 +0100
summary:     Issue #14043: Speed up importlib's _FileFinder by at least 8x, and add a new importlib.invalidate_caches() function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14063>
_______________________________________

From report at bugs.python.org  Mon Feb 20 21:36:47 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 20 Feb 2012 20:36:47 +0000
Subject: [issue14066] Crash in imputil.imp.find_module when a *directory*
	exists with the given name due to double-close of FILE*
In-Reply-To: <1329764501.42.0.487589660736.issue14066@psf.upfronthosting.co.za>
Message-ID: <1329770207.06.0.404830224351.issue14066@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Duplicate of issue 7732

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> imp.find_module crashes Python if there exists a directory named "__init__.py"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14066>
_______________________________________

From report at bugs.python.org  Mon Feb 20 21:41:43 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Feb 2012 20:41:43 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <E1Rza3K-0000a5-13@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4a31f6b11e7a by Georg Brandl in branch '3.2':
Merge from 3.1: Issue #13703: add a way to randomize the hash values of basic types (str, bytes, datetime)
http://hg.python.org/cpython/rev/4a31f6b11e7a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Mon Feb 20 21:44:53 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Feb 2012 20:44:53 +0000
Subject: [issue14063] test_importlib failure on Mac OS X
In-Reply-To: <1329735966.21.0.756949345027.issue14063@psf.upfronthosting.co.za>
Message-ID: <1329770693.54.0.611249928831.issue14063@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you please try this patch?

----------
assignee: brett.cannon -> 
keywords: +patch
Added file: http://bugs.python.org/file24581/impcasing.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14063>
_______________________________________

From report at bugs.python.org  Mon Feb 20 21:55:58 2012
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Feb 2012 20:55:58 +0000
Subject: [issue14063] test_importlib failure on Mac OS X
In-Reply-To: <1329735966.21.0.756949345027.issue14063@psf.upfronthosting.co.za>
Message-ID: <1329771358.41.0.267381003103.issue14063@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

With impcasing.patch applied, test_importlib passes on OS X (10.7 with case-insensitive fs).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14063>
_______________________________________

From report at bugs.python.org  Mon Feb 20 22:10:28 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Feb 2012 21:10:28 +0000
Subject: [issue14063] test_importlib failure on Mac OS X
In-Reply-To: <1329735966.21.0.756949345027.issue14063@psf.upfronthosting.co.za>
Message-ID: <E1RzaV8-0003Wk-HE@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3297dcdad196 by Antoine Pitrou in branch 'default':
Issue #14063: fix test_importlib failure under OS X case-insensitive filesystems
http://hg.python.org/cpython/rev/3297dcdad196

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14063>
_______________________________________

From report at bugs.python.org  Mon Feb 20 22:11:30 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Mon, 20 Feb 2012 21:11:30 +0000
Subject: [issue14053] Make Tools/scripts/patchcheck.py compatible with
	mercurial mqueues.
In-Reply-To: <1329661471.35.0.733956428931.issue14053@psf.upfronthosting.co.za>
Message-ID: <1329772290.76.0.870658398904.issue14053@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

The patch is updated. Notice about:
[...]Ideally, it
  should distinguish between this and other errors by checking the
  subprocess's stderr, so that if a different error occurs, we can still
  print out the error message.
[?]
that should be improved as now stderr is ignored in 'mq_changed_files'
(user case: 'no mq extension enabled'). Suggestions are welcome!

> [..] but this is a bit orthogonal.
IMHO the MQ feature works very well for pydev newbies (as I'm) and it's
a good recommendation (it's a taste thing ...)

> The easiest thing to do is to make some changes and use
> "hg diff>  patch.diff" and the devguide should advertise this IMHO.  This also works fine with `make patchcheck`.

There is some small differences between diff, qdiff and status but if one uses MQ then diff isn't enough. One really wants to know the changes from qparent to qtip and using 'status' as proposed I thing that it's the best solution.

Cheers,
francis

----------
Added file: http://bugs.python.org/file24582/issue14053_1f9461ef6312.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14053>
_______________________________________

From report at bugs.python.org  Mon Feb 20 22:11:56 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Feb 2012 21:11:56 +0000
Subject: [issue14063] test_importlib failure on Mac OS X
In-Reply-To: <1329735966.21.0.756949345027.issue14063@psf.upfronthosting.co.za>
Message-ID: <1329772316.19.0.119800791804.issue14063@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, thanks for testing!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14063>
_______________________________________

From report at bugs.python.org  Mon Feb 20 22:12:22 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 20 Feb 2012 21:12:22 +0000
Subject: [issue14060] Implement a CSP-style channel
In-Reply-To: <1329699366.61.0.518357475552.issue14060@psf.upfronthosting.co.za>
Message-ID: <1329772342.26.0.949998992019.issue14060@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think zero-sized queues are exactly the right answer here.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14060>
_______________________________________

From report at bugs.python.org  Mon Feb 20 22:18:07 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Feb 2012 21:18:07 +0000
Subject: [issue14067] Avoid more stat() calls in importlib
Message-ID: <1329772687.53.0.782755770398.issue14067@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is an experimental patch that limits the frequency of stat() calls in _FileFinder.find_module(). It speeds up finding modules by 2x here, but unfortunately breaks some tests (which expect modules to appear immediately when created).

----------
components: Library (Lib)
files: imptime.patch
keywords: patch
messages: 153809
nosy: brett.cannon, ncoghlan, pitrou
priority: low
severity: normal
status: open
title: Avoid more stat() calls in importlib
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file24583/imptime.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14067>
_______________________________________

From report at bugs.python.org  Mon Feb 20 22:19:08 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 20 Feb 2012 21:19:08 +0000
Subject: [issue10112] Use -Wl, --dynamic-list=x.list,
	not -Xlinker -export-dynamic
In-Reply-To: <1287137785.61.0.962664170792.issue10112@psf.upfronthosting.co.za>
Message-ID: <1329772748.77.0.354278751594.issue10112@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch is fairly incomplete: it assumes that the compiler supports __attribute__((visibility())), but it really needs to check for that.

Also, there is no chance that this can go into Python 2.7; retargetting for 3.3.

----------
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10112>
_______________________________________

From report at bugs.python.org  Mon Feb 20 22:25:07 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 20 Feb 2012 21:25:07 +0000
Subject: [issue10112] Use -Wl, --dynamic-list=x.list,
	not -Xlinker -export-dynamic
In-Reply-To: <1287137785.61.0.962664170792.issue10112@psf.upfronthosting.co.za>
Message-ID: <1329773107.75.0.403508181421.issue10112@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/issue10112>
_______________________________________

From report at bugs.python.org  Mon Feb 20 22:31:22 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Mon, 20 Feb 2012 21:31:22 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>
Message-ID: <1329773482.28.0.254251268124.issue13447@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

+1

while working on #issue14053 I missed the test for the scripts (in this case some kind of mocking is needed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Mon Feb 20 22:32:35 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 20 Feb 2012 21:32:35 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1329773555.02.0.0600009934931.issue13405@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

jcea: BTW, will you be at PyCon US this year?  if so, can we sprint on getting the DTrace and SystemTap hooks into CPython in some form acceptable to the rest of the CPython maintainers?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Feb 20 22:40:01 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Feb 2012 21:40:01 +0000
Subject: [issue14067] Avoid more stat() calls in importlib
In-Reply-To: <1329772687.53.0.782755770398.issue14067@psf.upfronthosting.co.za>
Message-ID: <1329774001.5.0.129325917304.issue14067@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file24584/imptime.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14067>
_______________________________________

From report at bugs.python.org  Mon Feb 20 22:40:09 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Feb 2012 21:40:09 +0000
Subject: [issue14067] Avoid more stat() calls in importlib
In-Reply-To: <1329772687.53.0.782755770398.issue14067@psf.upfronthosting.co.za>
Message-ID: <1329774009.63.0.0790745321147.issue14067@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file24583/imptime.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14067>
_______________________________________

From report at bugs.python.org  Mon Feb 20 22:44:10 2012
From: report at bugs.python.org (Eric Snow)
Date: Mon, 20 Feb 2012 21:44:10 +0000
Subject: [issue14067] Avoid more stat() calls in importlib
In-Reply-To: <1329772687.53.0.782755770398.issue14067@psf.upfronthosting.co.za>
Message-ID: <1329774250.27.0.599549610179.issue14067@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14067>
_______________________________________

From report at bugs.python.org  Mon Feb 20 23:30:53 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 20 Feb 2012 22:30:53 +0000
Subject: [issue14053] Make Tools/scripts/patchcheck.py compatible with
	mercurial mqueues.
In-Reply-To: <1329661471.35.0.733956428931.issue14053@psf.upfronthosting.co.za>
Message-ID: <1329777053.12.0.351972891764.issue14053@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Hmm... it looks like mq_changed_files() duplicates a chunk of logic from
the existing changed_files() code. You can get rid of this redundancy by
replacing mq_changed_files() with a function that checks for applied MQ
patches; let's call it mq_patches_applied(). Then you can say:

    if mq_patches_applied():
        cmd += ' --rev qparent'

before the call to Popen in changed_files(), and leave the rest of the
function unmodified. The basic logic that the code will follow is this:

    if <MQ patches applied>:
        return files listed by 'hg status --added --modified --no-status --rev qparent'
    else:
        return files listed by 'hg status --added --modified --no-status'


The mq_patches_applied() function can be implemented by running
'hg qapplied' and checking whether it (a) prints at least one patch name,
(b) prints out nothing, or (c) gives an error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14053>
_______________________________________

From report at bugs.python.org  Tue Feb 21 00:04:40 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 20 Feb 2012 23:04:40 +0000
Subject: [issue14067] Avoid more stat() calls in importlib
In-Reply-To: <1329772687.53.0.782755770398.issue14067@psf.upfronthosting.co.za>
Message-ID: <1329779080.07.0.812417903566.issue14067@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The patch uses the time module which is not a built-in, so it breaks bootstrapping by directly importing a module, and an extension at that. At best you could switch to a modified _FileFinder after importlib is initially running and able to import extension modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14067>
_______________________________________

From report at bugs.python.org  Tue Feb 21 00:06:07 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Feb 2012 23:06:07 +0000
Subject: [issue14067] Avoid more stat() calls in importlib
In-Reply-To: <1329779080.07.0.812417903566.issue14067@psf.upfronthosting.co.za>
Message-ID: <1329778963.3382.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The patch uses the time module which is not a built-in, so it breaks
> bootstrapping by directly importing a module, and an extension at
> that. At best you could switch to a modified _FileFinder after
> importlib is initially running and able to import extension modules.

Yup, as I said it's more of a proof-of-concept.
(I was actually surprised that time is not a built-in module)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14067>
_______________________________________

From report at bugs.python.org  Tue Feb 21 00:20:15 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 20 Feb 2012 23:20:15 +0000
Subject: [issue14067] Avoid more stat() calls in importlib
In-Reply-To: <1329778963.3382.5.camel@localhost.localdomain>
Message-ID: <CAP1=2W6nCkT4p8KLe0NtfiZcCNH6ntf0p3TJeae=YTGK+A3btw@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Mon, Feb 20, 2012 at 18:06, Antoine Pitrou <report at bugs.python.org>wrote:

>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> > The patch uses the time module which is not a built-in, so it breaks
> > bootstrapping by directly importing a module, and an extension at
> > that. At best you could switch to a modified _FileFinder after
> > importlib is initially running and able to import extension modules.
>
> Yup, as I said it's more of a proof-of-concept.
> (I was actually surprised that time is not a built-in module)

Yeah, I had to double-check myself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14067>
_______________________________________

From report at bugs.python.org  Tue Feb 21 00:37:06 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Feb 2012 23:37:06 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <E1Rzcn3-0000Ha-DR@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ed76dc34b39d by Georg Brandl in branch 'default':
Merge 3.2: Issue #13703 plus some related test suite fixes.
http://hg.python.org/cpython/rev/ed76dc34b39d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Tue Feb 21 00:47:43 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Feb 2012 23:47:43 +0000
Subject: [issue14062] UTF-8 Email Subject problem
In-Reply-To: <1329725009.21.0.0898146100656.issue14062@psf.upfronthosting.co.za>
Message-ID: <1329781663.92.2.83594555317e-06.issue14062@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14062>
_______________________________________

From report at bugs.python.org  Tue Feb 21 00:48:12 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Feb 2012 23:48:12 +0000
Subject: [issue14053] Make patchcheck work with MQ
In-Reply-To: <1329661471.35.0.733956428931.issue14053@psf.upfronthosting.co.za>
Message-ID: <1329781692.92.0.577672676991.issue14053@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: Make Tools/scripts/patchcheck.py compatible with mercurial mqueues. -> Make patchcheck work with MQ

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14053>
_______________________________________

From report at bugs.python.org  Tue Feb 21 00:49:49 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Feb 2012 23:49:49 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>
Message-ID: <1329781789.07.0.357489420441.issue13447@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m pushing this higher on my todo list then.  I?ll certainly upload a patch for review here with the basic machinery, then commit it, and then we?ll be able to add tests for the tools we like.

----------
assignee:  -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Tue Feb 21 00:58:33 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Feb 2012 23:58:33 +0000
Subject: [issue14047] UTF-8 Email Header
In-Reply-To: <1329549808.72.0.457462714436.issue14047@psf.upfronthosting.co.za>
Message-ID: <1329782313.34.0.2785701028.issue14047@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I had written a message which read much like Martin?s and wanted to reopen this report, but apparently my flaky connection did not let it go through and now it?s lost.  My apologies for not understanding your report for what it was, and thanks for persevering.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14047>
_______________________________________

From report at bugs.python.org  Tue Feb 21 01:00:40 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Feb 2012 00:00:40 +0000
Subject: [issue14050] Tutorial, list.sort() and items comparability
In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za>
Message-ID: <1329782440.01.0.542914649895.issue14050@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Nope, the expression would be hyphenated only when used as an adjective:

- ?This sorts the sequence in place?
vs.
? ?Performs an in-place rearrangement by birthdate?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14050>
_______________________________________

From report at bugs.python.org  Tue Feb 21 01:01:43 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Feb 2012 00:01:43 +0000
Subject: [issue14034] Add argparse howto
In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za>
Message-ID: <1329782503.49.0.103312870639.issue14034@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Nice.  I?ll find time to review later; Steven, do you have objections on the idea of adding an argparse howto?  Do you want to review it yourself?

----------
nosy: +bethard
title: first example in argparse doc is too complicated -> Add argparse howto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14034>
_______________________________________

From report at bugs.python.org  Tue Feb 21 01:04:39 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Tue, 21 Feb 2012 00:04:39 +0000
Subject: [issue14053] Make patchcheck work with MQ
In-Reply-To: <1329661471.35.0.733956428931.issue14053@psf.upfronthosting.co.za>
Message-ID: <1329782679.73.0.948879315722.issue14053@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

Updated.

Interesting: I saw that repetition but due ?[?] Ideally, it
should distinguish between this and other errors by checking the
subprocess's stderr, so that if a different error occurs, we can still
print out the error message. [?]? I just wanted to keep cmd's separated first :-)

Let me know what can be done ?

Cheers,
francis

----------
Added file: http://bugs.python.org/file24585/issue14053_3297dcdad196.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14053>
_______________________________________

From report at bugs.python.org  Tue Feb 21 01:10:26 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Feb 2012 00:10:26 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
Message-ID: <1329783026.39.0.856112248201.issue1521950@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This time you should have received an email from Rietveld, I made sure that your ID was expanded to an email address.

I like all the suggestions you made in reply to my comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521950>
_______________________________________

From report at bugs.python.org  Tue Feb 21 01:11:59 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Feb 2012 00:11:59 +0000
Subject: [issue13605] document argparse's nargs=REMAINDER
In-Reply-To: <1323955710.42.0.753468095058.issue13605@psf.upfronthosting.co.za>
Message-ID: <1329783119.81.0.233064819032.issue13605@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Blocks not introduced by "::" are *NOT* code blocks.
> If they happen to begin with ">>> ", they are recognized as doctest blocks
> and colorized as doctests.

Ah, that?s it!  Thanks.  So we have two valid ways of marking up doctest-like blocks, ?::? ? indent and implicit markup, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13605>
_______________________________________

From report at bugs.python.org  Tue Feb 21 01:24:10 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Feb 2012 00:24:10 +0000
Subject: [issue13964] os.utimensat() and os.futimes() should accept Decimal,
	drop os.futimens()
In-Reply-To: <1328663994.2.0.189878263913.issue13964@psf.upfronthosting.co.za>
Message-ID: <1329783850.83.0.572802746013.issue13964@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Here is a first step: add _PyTime_ObjectToTimespec() to pytime.h and use it for signal.sigtimedwait().

signal.sigtimedwait(sigwait, (timeout_sec, timeout_nsec)) becomes signal.sigtimedwait(sigwait, timeout).

I chose pytime.h instead of timefuncs.h because I plan to use _PyTime_ObjectToTimespec() in the posix module. I don't want to have a copy of this function in each module: timefuncs.h requires to compile the module with _time.c.

----------
keywords: +patch
Added file: http://bugs.python.org/file24586/pytime.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13964>
_______________________________________

From report at bugs.python.org  Tue Feb 21 01:55:01 2012
From: report at bugs.python.org (Jason Yeo)
Date: Tue, 21 Feb 2012 00:55:01 +0000
Subject: [issue14026] test_cmd_line_script should include more sys.argv checks
In-Reply-To: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za>
Message-ID: <1329785701.64.0.277477730123.issue14026@psf.upfronthosting.co.za>


Jason Yeo <jasonyeo88 at gmail.com> added the comment:

>For the two failures, I suggest modifying _check_script() to return the 
>"rc, out, err" from the underlying assert_python_ok() call

I've decided to simple pass in *example_args into the assert_python_ok() in those two offending tests. There are less changes this way. Please let me know if I am doing this correctly. Thanks. ;)

----------
Added file: http://bugs.python.org/file24587/mypatch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14026>
_______________________________________

From report at bugs.python.org  Tue Feb 21 01:55:34 2012
From: report at bugs.python.org (Jason Yeo)
Date: Tue, 21 Feb 2012 00:55:34 +0000
Subject: [issue14026] test_cmd_line_script should include more sys.argv checks
In-Reply-To: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za>
Message-ID: <1329785734.07.0.745735332678.issue14026@psf.upfronthosting.co.za>


Changes by Jason Yeo <jasonyeo88 at gmail.com>:


Removed file: http://bugs.python.org/file24587/mypatch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14026>
_______________________________________

From report at bugs.python.org  Tue Feb 21 01:56:37 2012
From: report at bugs.python.org (Jason Yeo)
Date: Tue, 21 Feb 2012 00:56:37 +0000
Subject: [issue14026] test_cmd_line_script should include more sys.argv checks
In-Reply-To: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za>
Message-ID: <1329785797.35.0.0312419566014.issue14026@psf.upfronthosting.co.za>


Changes by Jason Yeo <jasonyeo88 at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file24588/14026v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14026>
_______________________________________

From report at bugs.python.org  Tue Feb 21 01:58:08 2012
From: report at bugs.python.org (Jason Yeo)
Date: Tue, 21 Feb 2012 00:58:08 +0000
Subject: [issue14026] test_cmd_line_script should include more sys.argv checks
In-Reply-To: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za>
Message-ID: <1329785888.28.0.464492603512.issue14026@psf.upfronthosting.co.za>


Changes by Jason Yeo <jasonyeo88 at gmail.com>:


Removed file: http://bugs.python.org/file24556/14026patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14026>
_______________________________________

From report at bugs.python.org  Tue Feb 21 02:06:42 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Feb 2012 01:06:42 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <1329762881.39.0.927740145261.issue13641@psf.upfronthosting.co.za>
Message-ID: <20120221010640.31F722500E7@webabinitio.net>


R. David Murray <rdmurray at bitdance.com> added the comment:

Non-ascii binary data should not be being rejected unless validate
is true.  So what are you going to do with non-ascii-range unicode in
that case?  Ignore it as well?  That can't be right.

I believe this should be discussed on python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Tue Feb 21 02:10:06 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Feb 2012 01:10:06 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <1324386392.48.0.968435833624.issue13641@psf.upfronthosting.co.za>
Message-ID: <1329786606.64.0.00290650566007.issue13641@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I disagree with this commit.  Reopening pending discussion on python-dev.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Tue Feb 21 02:11:27 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Feb 2012 01:11:27 +0000
Subject: [issue13637] binascii.a2b_* functions could accept unicode strings
In-Reply-To: <1324312244.97.0.383716057437.issue13637@psf.upfronthosting.co.za>
Message-ID: <1329786687.56.0.76878022644.issue13637@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I disagree with this feature.  Reopening pending discussion on python-dev.

----------
nosy: +r.david.murray
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13637>
_______________________________________

From report at bugs.python.org  Tue Feb 21 02:23:46 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Feb 2012 01:23:46 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <20120221010640.31F722500E7@webabinitio.net>
Message-ID: <1329787219.3382.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Non-ascii binary data should not be being rejected unless validate
> is true.  So what are you going to do with non-ascii-range unicode in
> that case?  Ignore it as well?  That can't be right.

It's not ignored, it raises ValueError. Since the common case it to feed
valid (not invalid) baseXX data to these functions, that's a very benign
limitation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Tue Feb 21 02:24:35 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Feb 2012 01:24:35 +0000
Subject: [issue5411] Add xz support to shutil
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1329787475.57.0.420898281926.issue5411@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have a working updated shutil module, tests pass and the documentation is improved.  I will make sure to make different commits for improving the tests, cleaning up some things, adding tarfile.compression_formats and removing duplication in shutil (see dep bugs), to be sure not to introduce regressions.

Before I finish and post the patch, I?d like feedback on a choice I made.  I don?t think it?s possible to have shutil automatically support all the formats that tarfile does, because of the spelling issue I mentioned.  Here?s what the code would look like (let me know if I should post it elsewhere or as a file to let you get syntax coloring):
          
  _ARCHIVE_FORMATS = {}
  _UNPACK_FORMATS = {}

  for fmt in tarfile.compression_formats:
      code = fmt + 'tar'
      ext = '.' + fmt
      desc = "%s'ed tar file" % fmt
      _ARCHIVE_FORMATS[code] = (_make_tarball, [('compress', fmt)], desc)
      _UNPACK_FORMATS[code] = ([ext], _unpack_tarfile, [], desc)

  # kludge to add alternate extension
  if 'gztar' in _ARCHIVE_FORMATS:
      _UNPACK_FORMATS['gztar'][0].append('.tgz')
      # XXX desc should say "gzip'ed tar file", not "gz'ed"

  # rectify naming incompatibility
  if 'bz2tar' in _ARCHIVE_FORMATS:
      # XXX alternative: make 'bztar' alias for 'bz2tar', but would complicate
      # manipulating the registries
      del _ARCHIVE_FORMATS['bz2tar']
      del _UNPACK_FORMATS['bz2tar']
      desc = "bzip2'ed tar file"
      _ARCHIVE_FORMATS['bztar'] = (_make_tarball, [('compress', 'bz2')], desc)
      _UNPACK_FORMATS['bztar'] = (['.bz2'], _unpack_tarfile, [], desc)

  # now add uncompressed tar and zip file

I really don?t like that code.  Given that tarfile is not extensible at run time, it is not a big deal to have to update shutil whenever we add a compression format to tarfile.  Therefore, I backtracked on my ?automatic support? idea but kept a lot of cleanup in did in the code.  Here?s what the code looks like:

  _ARCHIVE_FORMATS = {}
  _UNPACK_FORMATS = {}

  if 'xz' in tarfile.compression_formats:
      desc = "xz'ed tar file"
      # XXX '.xz' is not great, '.tar.xz' would be better
      _ARCHIVE_FORMATS['xztar'] = (_make_tarball, [('compress', 'xz')], desc)
      _UNPACK_FORMATS['xztar'] = (['.xz'], _unpack_tarfile, [], desc)

  if 'bz2' in tarfile.compression_formats:
      desc = "bzip2'ed tar file"
      _ARCHIVE_FORMATS['bztar'] = (_make_tarball, [('compress', 'bz2')], desc)
      _UNPACK_FORMATS['bztar'] = (['.bz2'], _unpack_tarfile, [], desc)

  if 'gz' in tarfile.compression_formats:
      desc = "gzip'ed tar file"
      _ARCHIVE_FORMATS['gztar'] = (_make_tarball, [('compress', 'gz')], desc)
      _UNPACK_FORMATS['gztar'] = (['.gz', '.tgz'], _unpack_tarfile, [], desc)

So, do you agree that ?not automated but not ugly? is better than ?automated with ugly klutches??

----------
title: shutil should support all formats supported by tarfile automatically -> Add xz support to shutil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5411>
_______________________________________

From report at bugs.python.org  Tue Feb 21 02:26:18 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Feb 2012 01:26:18 +0000
Subject: [issue5411] Add xz support to shutil
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1329787578.75.0.34329009146.issue5411@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

s/cleanup in did in the code/cleanup I did in the code/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5411>
_______________________________________

From report at bugs.python.org  Tue Feb 21 02:44:36 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 21 Feb 2012 01:44:36 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <E1RzemN-0001YC-QP@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6b7704fe1be1 by Barry Warsaw in branch '2.6':
- Issue #13703: oCERT-2011-003: add -R command-line option and PYTHONHASHSEED
http://hg.python.org/cpython/rev/6b7704fe1be1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Tue Feb 21 03:27:39 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Feb 2012 02:27:39 +0000
Subject: [issue5411] Add xz support to shutil
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1329791259.72.0.970461062944.issue5411@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Note that there is a way to get fully automated support for tar formats: tarfile could expose, in addition to the list compression_formats, another structure with the descriptions (e.g. ?gzip?ed tar file?) and file extensions (e.g. ['.gz', '.tgz'] ?no, it?s not '.tar.gz', which is unfortunate, and could cause Lars to reject that idea).  I?m just putting this here for reference, but my preference is still for the second idea I talk about in my precedent message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5411>
_______________________________________

From report at bugs.python.org  Tue Feb 21 03:34:42 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Feb 2012 02:34:42 +0000
Subject: [issue3354] Improve error reporting for the argument parsing C API
In-Reply-To: <1216040063.73.0.634067891199.issue3354@psf.upfronthosting.co.za>
Message-ID: <1329791682.03.0.170947519512.issue3354@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: Improve error reporting for the argument parsing API -> Improve error reporting for the argument parsing C API
versions: +Python 3.3 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3354>
_______________________________________

From report at bugs.python.org  Tue Feb 21 03:39:57 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Feb 2012 02:39:57 +0000
Subject: [issue2661] Mapping tests cannot be passed by user implementations
In-Reply-To: <1208642973.7.0.825847798287.issue2661@psf.upfronthosting.co.za>
Message-ID: <1329791997.13.0.842410800785.issue2661@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think it would be great to test the stdlib?s mapping classes against common tests; there is a patch to add more MutableMapping methods to dbm classes for example, and it was not trivial to get good test coverage.

Not sure about the status of the module though, i.e. if we should officially support people using mapping_tests to check their code; it would be very useful for classes that don?t inherit from an ABC, but the whole test package is not intended for public use.

----------
nosy: +eric.araujo
stage:  -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2661>
_______________________________________

From report at bugs.python.org  Tue Feb 21 03:52:04 2012
From: report at bugs.python.org (=?utf-8?b?5ZCv5pyXIOadqA==?=)
Date: Tue, 21 Feb 2012 02:52:04 +0000
Subject: [issue14068] problem with re
Message-ID: <1329792724.0.0.725083325394.issue14068@psf.upfronthosting.co.za>


Changes by ?? ? <yangqilang at gmail.com>:


----------
nosy: ??.?
priority: normal
severity: normal
status: open
title: problem with re

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14068>
_______________________________________

From report at bugs.python.org  Tue Feb 21 03:55:59 2012
From: report at bugs.python.org (py.user)
Date: Tue, 21 Feb 2012 02:55:59 +0000
Subject: [issue14069] In extensions (?...) the lookbehind assertion cannot
	choose between the beginning of string and a letter
Message-ID: <1329792959.02.0.649716496368.issue14069@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

>>> import re
>>> re.search(r'(?<=(a|b))(\w+)', 'abc').groups()
('a', 'bc')
>>> re.search(r'(?<=(^))(\w+)', 'abc').groups()
('', 'abc')
>>> re.search(r'(?<=(^|$))(\w+)', 'abc').groups()
('', 'abc')
>>> re.search(r'(?<=($|^))(\w+)', 'abc').groups()
('', 'abc')
>>> re.search(r'(?<=(^|a))(\w+)', 'abc').groups()
Traceback (most recent call last):
  File "/usr/local/lib/python3.2/functools.py", line 176, in wrapper
    result = cache[key]
KeyError: (<class 'str'>, '(?<=(^|a))(\\w+)', 0)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.2/re.py", line 158, in search
    return _compile(pattern, flags).search(string)
  File "/usr/local/lib/python3.2/re.py", line 255, in _compile
    return _compile_typed(type(pattern), pattern, flags)
  File "/usr/local/lib/python3.2/functools.py", line 180, in wrapper
    result = user_function(*args, **kwds)
  File "/usr/local/lib/python3.2/re.py", line 267, in _compile_typed
    return sre_compile.compile(pattern, flags)
  File "/usr/local/lib/python3.2/sre_compile.py", line 495, in compile
    code = _code(p, flags)
  File "/usr/local/lib/python3.2/sre_compile.py", line 480, in _code
    _compile(code, p.data, flags)
  File "/usr/local/lib/python3.2/sre_compile.py", line 115, in _compile
    raise error("look-behind requires fixed-width pattern")
sre_constants.error: look-behind requires fixed-width pattern
>>>

----------
components: Library (Lib), Regular Expressions
messages: 153836
nosy: ezio.melotti, py.user
priority: normal
severity: normal
status: open
title: In extensions (?...) the lookbehind assertion cannot choose between the beginning of string and a letter
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14069>
_______________________________________

From report at bugs.python.org  Tue Feb 21 03:56:36 2012
From: report at bugs.python.org (=?utf-8?b?5ZCv5pyXIOadqA==?=)
Date: Tue, 21 Feb 2012 02:56:36 +0000
Subject: [issue14068] problem with re split
Message-ID: <1329792996.32.0.66370663671.issue14068@psf.upfronthosting.co.za>


New submission from ?? ? <yangqilang at gmail.com>:

i use python to handle some string. 
here is my code:
# -*- coding: utf-8 -*- 
from lxml import etree
import collectcorpus
import re


doc = etree.parse("/home/harveyang/workspace/corpus/newsscrapy/news1.xml")

root = doc.getroot()
children = root.getchildren()
flag = 1
for child in children:
    if flag == len(children):
        content = child.find("content").text
        pattern = re.compile('?')
        sentences = re.split(pattern, content)
        print "*********************"
        for s in sentences:
            print s
        print "**********************"
#        collectcorpus.collectCorpusFromString(content)
    flag = flag + 1
when i use re split it print that: *********************
???????????????????????????????????????????????????????????????????????????????????????????????4800??????????????????????????????????????????????????????????1???????????????????????????????????????(Adelaide)???????????????????????????????????????????????????????????????????????????????????160???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????Rundle         mall??????????????????????????????????????????????????Hindle         St,????????????????????????????????????????????????????????????????????????????????12345??????????????????????????????????????????????????
**********************
done!

when i switch to use str split, it print that: *********************
?????????????????????????
?????????????????????????????????????????????????????????????????????4800???????????????????????????????????????????????
??????????1??????????????????????
????????????????(Adelaide)????????????
????????????????????????
???????????????????????????????????????
?????160??????????????????????????????????????
???????????????
????????????????????????
???????????????????????????????????????????????
?????????????????????????????????
?????????????????????????????????????????????????????????????????????????????
????????????????????????????
??????????????????????????????????
????????????????????????????????????
???????????????????????????????????????????????????
?????????????????????
????????????????????????Rundle         mall??????????????????????????????????????????????????Hindle         St,????????????????????????
???????????????????????????????????????????????????
???12345?????????????????????????????????????????????????

**********************
done!

it means that re's split does not work!!

----------
components: +Regular Expressions
nosy: +ezio.melotti
title: problem with re -> problem with re split
type:  -> behavior
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14068>
_______________________________________

From report at bugs.python.org  Tue Feb 21 03:58:52 2012
From: report at bugs.python.org (=?utf-8?b?5ZCv5pyXIOadqA==?=)
Date: Tue, 21 Feb 2012 02:58:52 +0000
Subject: [issue14068] problem with re split
In-Reply-To: <1329792996.32.0.66370663671.issue14068@psf.upfronthosting.co.za>
Message-ID: <1329793132.72.0.462096550901.issue14068@psf.upfronthosting.co.za>


?? ? <yangqilang at gmail.com> added the comment:

i use python to handle some string. 
here is my code:
# -*- coding: utf-8 -*- 
from lxml import etree
import collectcorpus
import re


doc = etree.parse("news1.xml")

root = doc.getroot()
children = root.getchildren()
flag = 1
for child in children:
    if flag == len(children):
        content = child.find("content").text
        pattern = re.compile('?')
        sentences = re.split(pattern, content)
        print "*********************"
        for s in sentences:
            print s
        print "**********************"
#        collectcorpus.collectCorpusFromString(content)
    flag = flag + 1
when i use re split it print that: *********************
???????????????????????????????????????????????????????????????????????????????????????????????4800??????????????????????????????????????????????????????????1???????????????????????????????????????(Adelaide)???????????????????????????????????????????????????????????????????????????????????160???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????Rundle         mall??????????????????????????????????????????????????Hindle         St,?????????????????????????????????????????????????????????????????????????????
**********************
done!

when i switch to use str split, it print that: *********************
?????????????????????????
?????????????????????????????????????????????????????????????????????4800???????????????????????????????????????????????
??????????1??????????????????????
????????????????(Adelaide)????????????
????????????????????????
???????????????????????????????????????
?????160??????????????????????????????????????
???????????????
????????????????????????
???????????????????????????????????????????????
?????????????????????????????????
?????????????????????????????????????????????????????????????????????????????
????????????????????????????
??????????????????????????????????
????????????????????????????????????
???????????????????????????????????????????????????
?????????????????????
????????????????????????Rundle         mall??????????????????????????????????????????????????Hindle         St,????????????????????????
???????????????????????????????????????????????????

**********************
done!

it means that re's split does not work!!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14068>
_______________________________________

From report at bugs.python.org  Tue Feb 21 04:00:21 2012
From: report at bugs.python.org (Tim McNamara)
Date: Tue, 21 Feb 2012 03:00:21 +0000
Subject: [issue14070] reload(module, ignore_pyc=True) flag
Message-ID: <1329793221.07.0.0985593378146.issue14070@psf.upfronthosting.co.za>


New submission from Tim McNamara <paperless at timmcnamara.co.nz>:

When developing Python code, I often find myself needing to run "rm *.pyc" so that the interpreter will ignore any new changes that I have made to source files. It's really frustrating when forgotten.

Adding a flag to the reload builtin would go a long way to simplify this process.

----------
components: IO
messages: 153839
nosy: timClicks
priority: normal
severity: normal
status: open
title: reload(module, ignore_pyc=True) flag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14070>
_______________________________________

From report at bugs.python.org  Tue Feb 21 04:06:14 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 21 Feb 2012 03:06:14 +0000
Subject: [issue14067] Avoid more stat() calls in importlib
In-Reply-To: <1329772687.53.0.782755770398.issue14067@psf.upfronthosting.co.za>
Message-ID: <1329793574.96.0.272112524101.issue14067@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

FWIW, I doubt you'd get many objections if you ended up wanting to make time a builtin module and inject it into the bootstrapping namespace.

While I don't think the delay in noticing filesystem changes is reasonable as the default behaviour, it might be interesting to see how tricky it would be to create a custom importer (for either meta_path or path_hooks) that did this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14067>
_______________________________________

From report at bugs.python.org  Tue Feb 21 04:14:46 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Feb 2012 03:14:46 +0000
Subject: [issue7813] Bug in command-line module launcher
In-Reply-To: <1264867154.39.0.207369600825.issue7813@psf.upfronthosting.co.za>
Message-ID: <1329794086.36.0.629440504447.issue7813@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Sorry, 2.6 only gets security fixes now, closing.  Thanks for the report anyway!

----------
nosy: +eric.araujo
resolution:  -> out of date
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7813>
_______________________________________

From report at bugs.python.org  Tue Feb 21 04:17:55 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Feb 2012 03:17:55 +0000
Subject: [issue7562] Custom order for the subcommands of build
In-Reply-To: <1261492513.72.0.435888181618.issue7562@psf.upfronthosting.co.za>
Message-ID: <1329794275.75.0.243612359285.issue7562@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/issue7562>
_______________________________________

From report at bugs.python.org  Tue Feb 21 04:19:49 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Feb 2012 03:19:49 +0000
Subject: [issue7438] Allow to use a part of subprocess module during building
	Python
In-Reply-To: <1259987684.71.0.162752431193.issue7438@psf.upfronthosting.co.za>
Message-ID: <1329794389.13.0.799764524129.issue7438@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> It is sometimes useful to call subprocess.Popen() in setup.py of Python.

What use cases do you have in mind?  Maybe you want to remove the half-dozen calls to os.system?

----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7438>
_______________________________________

From report at bugs.python.org  Tue Feb 21 04:26:05 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Feb 2012 03:26:05 +0000
Subject: [issue2661] Mapping tests cannot be passed by user implementations
In-Reply-To: <1208642973.7.0.825847798287.issue2661@psf.upfronthosting.co.za>
Message-ID: <1329794765.44.0.518172422121.issue2661@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I think it would be great to test the stdlib?s mapping classes against common tests
grep told me that most of them already do.  Sorry for the noise, it?s late/soon here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2661>
_______________________________________

From report at bugs.python.org  Tue Feb 21 04:52:42 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 21 Feb 2012 03:52:42 +0000
Subject: [issue14068] problem with re split
In-Reply-To: <1329792996.32.0.66370663671.issue14068@psf.upfronthosting.co.za>
Message-ID: <1329796362.83.0.966824993412.issue14068@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Can you paste (or upload) a minimal working example (with a short sample string) that uses re.split and str.split and shows how re.split is failing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14068>
_______________________________________

From report at bugs.python.org  Tue Feb 21 04:53:04 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Feb 2012 03:53:04 +0000
Subject: [issue7966] mhlib does not emit deprecation warning
In-Reply-To: <1266590877.1.0.984068009408.issue7966@psf.upfronthosting.co.za>
Message-ID: <1329796384.24.0.367144496901.issue7966@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This was fixed by r63030.

----------
nosy: +eric.araujo
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7966>
_______________________________________

From report at bugs.python.org  Tue Feb 21 05:07:15 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Feb 2012 04:07:15 +0000
Subject: [issue3213] "pydoc -p" should listen to [::] if IPv6 is supported
In-Reply-To: <1214525489.78.0.574038651579.issue3213@psf.upfronthosting.co.za>
Message-ID: <1329797235.17.0.964234096992.issue3213@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
type: behavior -> enhancement
versions: +Python 3.3 -Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3213>
_______________________________________

From report at bugs.python.org  Tue Feb 21 05:08:33 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Feb 2012 04:08:33 +0000
Subject: [issue8942] __path__ attribute of modules loaded by zipimporter is
	untested
In-Reply-To: <1276013732.57.0.515191754786.issue8942@psf.upfronthosting.co.za>
Message-ID: <1329797313.99.0.44446265497.issue8942@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy
nosy: +brett.cannon, eric.snow, ncoghlan
stage:  -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8942>
_______________________________________

From report at bugs.python.org  Tue Feb 21 05:15:56 2012
From: report at bugs.python.org (=?utf-8?b?5ZCv5pyXIOadqA==?=)
Date: Tue, 21 Feb 2012 04:15:56 +0000
Subject: [issue14068] problem with re split
In-Reply-To: <1329792996.32.0.66370663671.issue14068@psf.upfronthosting.co.za>
Message-ID: <1329797756.31.0.628697731832.issue14068@psf.upfronthosting.co.za>


?? ? <yangqilang at gmail.com> added the comment:

sure?here is an simple string from the news1.xml

----------
Added file: http://bugs.python.org/file24589/news1.xml

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14068>
_______________________________________

From report at bugs.python.org  Tue Feb 21 05:18:16 2012
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 21 Feb 2012 04:18:16 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <1324386392.48.0.968435833624.issue13641@psf.upfronthosting.co.za>
Message-ID: <1329797896.42.0.766721068075.issue13641@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Aside: I, too, at first thought this would be a bad idea because it brings back the Python 2 issue of accepting some but not all Unicode strings. But then I realized that by their nature these functions only accepts a very specific set of characters -- so the restriction to (a subset of) ASCII is intrinsic to the functionality, and there is no possibility of confusion. If anything, accepting bytes is more likely to be confusing (they could be EBCDIC! :-). So no objection here. And a slight preference for ValueError.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Tue Feb 21 07:01:57 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 21 Feb 2012 06:01:57 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1329804117.38.0.588871567658.issue13703@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Roundup Robot didn't seem to notice it, but this has also been committed in 2.7:

http://hg.python.org/cpython/rev/a0f43f4481e0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Tue Feb 21 07:03:39 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Feb 2012 06:03:39 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1329804219.18.0.080216763558.issue13703@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yep, the bot only looks at commit messages, it does not inspect merges or other topographical information.  That?s why some of us make sure to repeat bug numbers in our merge commit messages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Tue Feb 21 07:12:33 2012
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 21 Feb 2012 06:12:33 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1329804753.42.0.68608048783.issue13703@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

But since our workflow is such that commits in X.Y branches always show up in X.Y+1, it doesn't really matter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Tue Feb 21 07:17:30 2012
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 21 Feb 2012 06:17:30 +0000
Subject: [issue13605] document argparse's nargs=REMAINDER
In-Reply-To: <1323955710.42.0.753468095058.issue13605@psf.upfronthosting.co.za>
Message-ID: <1329805050.56.0.830857655323.issue13605@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, that's correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13605>
_______________________________________

From report at bugs.python.org  Tue Feb 21 07:35:48 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 21 Feb 2012 06:35:48 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1329806148.78.0.195196226905.issue13703@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

The bug report is the easiest thing to search for and follow when checking when something is resolved so it is nice to have a link to the relevant patch(es) for each branch.  I just wanted to note the major commit here so that all planned branches had a note recorded.  I don't care that it wasn't automatic. :)

For observers: There have been several more commits related to fixing this (test dict/set order fixes, bug/typo/merge oops fixes for the linked to patches, etc). Anyone interested in seeing the full list of diffs should look at their specific branch on our around the time of the linked to changelists.  Too many to list here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Tue Feb 21 07:40:31 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 21 Feb 2012 06:40:31 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1329806431.93.0.448943602188.issue13703@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Question: Should sys.flags.hash_randomization be True (1) when PYTHONHASHSEED=0?  It is now.

Saying yes "working as intended" is fine by me.

sys.flags.hash_randomization seems to simply indicate that doing something with the hash seed was explicitly specified as opposed to defaulting to off, not that the hash seed was actually chosen randomly.

What this implies for 3.3 after we make hash randomization default to on is that sys.flags.hash_randomization will always be 1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Tue Feb 21 07:47:35 2012
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 21 Feb 2012 06:47:35 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1329806855.92.0.0812627982675.issue13703@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That is a good question.  I don't really care either way, but let's say +0 for turning it off when seed == 0.

-R still needs to be made default in 3.3 - that's one reason this issue is still open.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Tue Feb 21 07:54:47 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 21 Feb 2012 06:54:47 +0000
Subject: [issue14071] allow more than one hash seed per process (move
	_Py_HashSecret into PyInterpreterState)
Message-ID: <1329807287.0.0.916593271901.issue14071@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

The newly added hash randomization seed (issue 13703) is a global defined in object/object.c that is initialized only once within a process by a call from Py_InitializeEx().

For applications embedding Python interpreters it may be useful for them to NOT share a hash randomization seed across all interpreter instances within that process.  That way long living processes or processes serving many independent tasks can avoid using the same hash seed for separate tasks.

----------
components: Interpreter Core
messages: 153855
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: allow more than one hash seed per process (move _Py_HashSecret into PyInterpreterState)
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14071>
_______________________________________

From report at bugs.python.org  Tue Feb 21 08:47:45 2012
From: report at bugs.python.org (Matt Joiner)
Date: Tue, 21 Feb 2012 07:47:45 +0000
Subject: [issue14060] Implement a CSP-style channel
In-Reply-To: <1329699366.61.0.518357475552.issue14060@psf.upfronthosting.co.za>
Message-ID: <1329810465.73.0.852669685101.issue14060@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

As I see it, here are the desirable features of CSP-style concurrency as it pertains to channels:

1) At least an unbuffered mode
2) Can be marked closed
3) Block on multiple send/receives until one can proceed

Specifically features 1 and 2 could be bolted onto queue.Queue with excellent backward compatibility with existing usage of Queue. As mentioned on the mailing list, maxsize=None would mean infinite queue, and maxsize=0 would become the unbuffered mode Currently maxsize<=0 means infinite. Existing code that assumed one or the other and explicitly created Queues this way would have to change (I'd suspect almost no code would be affected).

Feature 3 allows for all the awesomeness of CSP channels, but I think it requires a redesign under the covers of Queue to allow waiters to be woken from arbitrary Queues to which they are subscribed. The synchronization internals are quite complex.

There appears to be several ways to proceed:

1) Add unbuffered mode, closing, and other syntactical sugar to queue.Queue.
2) Do (1) and additionally rework the internals to allow blocking on on several Queue actions at once.
3) Add an unbuffered-only, closable threading.Channel for use with higher level primitives (as Guido suggested).
4) Make no changes to queue, and create a brand-new module with full blown CSP channels.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14060>
_______________________________________

From report at bugs.python.org  Tue Feb 21 08:50:50 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 21 Feb 2012 07:50:50 +0000
Subject: [issue14059] Implement multiprocessing.Barrier
In-Reply-To: <1329699138.74.0.937439869593.issue14059@psf.upfronthosting.co.za>
Message-ID: <1329810650.3.0.850538504724.issue14059@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Here is an initial implementation.

Wouldn't it be simpler with a mp.Condition?

Otherwise, this should be added to Lib/multiprocesing.synchronize.py, and the tests to test_multiprocessing.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14059>
_______________________________________

From report at bugs.python.org  Tue Feb 21 09:15:53 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 21 Feb 2012 08:15:53 +0000
Subject: [issue14053] Make patchcheck work with MQ
In-Reply-To: <1329661471.35.0.733956428931.issue14053@psf.upfronthosting.co.za>
Message-ID: <1329812153.57.0.374225732572.issue14053@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Patch looks good; I've just got one more small suggestion.

The variable 'some_applied' in mq_patches_applied isn't really necessary
- it would be clearer if you just said:

    return st.returncode == 0 and bstdout

after the call to st.communicate().


> Interesting: I saw that repetition but due ?[?] Ideally, it
> should distinguish between this and other errors by checking the
> subprocess's stderr, so that if a different error occurs, we can still
> print out the error message. [?]? I just wanted to keep cmd's separated > first :-)

When I said that, I was referring to the 'hg qapplied' command (not the
'hg status' one), but I can see how it might have been confusing ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14053>
_______________________________________

From report at bugs.python.org  Tue Feb 21 09:53:43 2012
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Tue, 21 Feb 2012 08:53:43 +0000
Subject: [issue13866] {urllib,
	urllib.parse}.urlencode should not use quote_plus
In-Reply-To: <1327529522.13.0.464287316871.issue13866@psf.upfronthosting.co.za>
Message-ID: <1329814423.53.0.197079782096.issue13866@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


----------
nosy: +maker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13866>
_______________________________________

From report at bugs.python.org  Tue Feb 21 10:43:52 2012
From: report at bugs.python.org (Ivan Herman)
Date: Tue, 21 Feb 2012 09:43:52 +0000
Subject: [issue14072] urlparse on tel: URI-s misses the scheme in some cases
Message-ID: <1329817432.49.0.397391260888.issue14072@psf.upfronthosting.co.za>


Changes by Ivan Herman <ivan.herman at cwi.nl>:


----------
components: None
nosy: ivan_herman
priority: normal
severity: normal
status: open
title: urlparse on tel: URI-s misses the scheme in some cases
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14072>
_______________________________________

From report at bugs.python.org  Tue Feb 21 10:45:24 2012
From: report at bugs.python.org (Ivan Herman)
Date: Tue, 21 Feb 2012 09:45:24 +0000
Subject: [issue14072] urlparse on tel: URI-s misses the scheme in some cases
Message-ID: <1329817524.78.0.223656665156.issue14072@psf.upfronthosting.co.za>


New submission from Ivan Herman <ivan.herman at cwi.nl>:

I think that the screen dump below is fairly clear:

10:41 Ivan> python
Python 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 15:22:34) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import urlparse
>>> x = "tel:+31-641044153"
>>> urlparse.urlparse(x)
ParseResult(scheme='tel', netloc='', path='+31-641044153', params='', query='', fragment='')
>>> y = "tel:+31641044153"
>>> urlparse.urlparse(y)
ParseResult(scheme='', netloc='', path='tel:+31641044153', params='', query='', fragment='')
>>> 

It seems that, when the phone number does not have any separator character, the parsing goes wrong (separators are not required per RFC 3966)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14072>
_______________________________________

From report at bugs.python.org  Tue Feb 21 10:47:32 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Feb 2012 09:47:32 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1329806431.93.0.448943602188.issue13703@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYwYv+T_uNF1DeOSRttqrjGowKiFP5_kCBrUY9S3EKp+g@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Question: Should sys.flags.hash_randomization be True (1) when PYTHONHASHSEED=0? ?It is now.
>
> Saying yes "working as intended" is fine by me.

It is documented that PYTHONHASHSEED=0 disables the randomization, so
sys.flags.hash_randomization must be False (0).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Tue Feb 21 10:48:44 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 21 Feb 2012 09:48:44 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1329806431.93.0.448943602188.issue13703@psf.upfronthosting.co.za>
Message-ID: <4F436875.6070506@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Gregory P. Smith wrote:
> 
> Gregory P. Smith <greg at krypto.org> added the comment:
> 
> Question: Should sys.flags.hash_randomization be True (1) when PYTHONHASHSEED=0?  It is now.

The flag should probably be removed - simply because
the env var is not a flag, it's a configuration parameter.

Exposing the seed value as sys.hashseed would be better and more useful
to applications.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Tue Feb 21 10:49:48 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 21 Feb 2012 09:49:48 +0000
Subject: [issue14072] urlparse on tel: URI-s misses the scheme in some cases
In-Reply-To: <1329817524.78.0.223656665156.issue14072@psf.upfronthosting.co.za>
Message-ID: <1329817788.77.0.994888777574.issue14072@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14072>
_______________________________________

From report at bugs.python.org  Tue Feb 21 10:50:25 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 21 Feb 2012 09:50:25 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <CAMpsgwYwYv+T_uNF1DeOSRttqrjGowKiFP5_kCBrUY9S3EKp+g@mail.gmail.com>
Message-ID: <4F4368DB.80706@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at gmail.com> added the comment:
> 
>> Question: Should sys.flags.hash_randomization be True (1) when PYTHONHASHSEED=0?  It is now.
>>
>> Saying yes "working as intended" is fine by me.
> 
> It is documented that PYTHONHASHSEED=0 disables the randomization, so
> sys.flags.hash_randomization must be False (0).

PYTHONHASHSEED=1 will disable randomization as well :-)

Only setting PYTHONHASHSEED=random actually enables randomization.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Tue Feb 21 11:11:34 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 21 Feb 2012 10:11:34 +0000
Subject: [issue14068] problem with re split
In-Reply-To: <1329792996.32.0.66370663671.issue14068@psf.upfronthosting.co.za>
Message-ID: <1329819094.31.0.224895746647.issue14068@psf.upfronthosting.co.za>


Ramchandra Apte <maniandram01 at gmail.com> added the comment:

??.?, are you using text.split() in the second case?
text.split() splits on any whitespace character including newlines while re.split(text," ") splits on a space.

----------
nosy: +ramchandra.apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14068>
_______________________________________

From report at bugs.python.org  Tue Feb 21 11:18:27 2012
From: report at bugs.python.org (harvey yang)
Date: Tue, 21 Feb 2012 10:18:27 +0000
Subject: [issue14068] problem with re split
In-Reply-To: <1329792996.32.0.66370663671.issue14068@psf.upfronthosting.co.za>
Message-ID: <1329819507.33.0.33956044338.issue14068@psf.upfronthosting.co.za>


harvey yang <yangqilang at gmail.com> added the comment:

i am not use it to split whitespace or newline. i use it to split Chinese full stop. and the result is showed at the earlier message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14068>
_______________________________________

From report at bugs.python.org  Tue Feb 21 11:28:08 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 21 Feb 2012 10:28:08 +0000
Subject: [issue14068] problem with re split
In-Reply-To: <1329792996.32.0.66370663671.issue14068@psf.upfronthosting.co.za>
Message-ID: <1329820088.69.0.777573084557.issue14068@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

When you used str split, you had to use a unicode string:
  content.split(u'?')
It's the same with re.split: when I use
  pattern = re.compile('?')
nothing is split, it works much better with:
  pattern = re.compile(u'?')

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14068>
_______________________________________

From report at bugs.python.org  Tue Feb 21 11:29:39 2012
From: report at bugs.python.org (Tim McNamara)
Date: Tue, 21 Feb 2012 10:29:39 +0000
Subject: [issue14070] Idea: Add a flag to reload from source,
	e.g. reload(module, ignore_pyc=True)
In-Reply-To: <1329793221.07.0.0985593378146.issue14070@psf.upfronthosting.co.za>
Message-ID: <1329820179.99.0.959109752896.issue14070@psf.upfronthosting.co.za>


Changes by Tim McNamara <paperless at timmcnamara.co.nz>:


----------
title: reload(module, ignore_pyc=True) flag -> Idea: Add a flag to reload from source, e.g. reload(module, ignore_pyc=True)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14070>
_______________________________________

From report at bugs.python.org  Tue Feb 21 11:35:03 2012
From: report at bugs.python.org (Steven Bethard)
Date: Tue, 21 Feb 2012 10:35:03 +0000
Subject: [issue14034] Add argparse howto
In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za>
Message-ID: <1329820503.83.0.166066116123.issue14034@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I have no objections on adding a howto, and something like the attached patch would be fine with me (though I don't have time to review it in full and trust you to).

You might want to coordinate with Issue 13850 a bit - they want a quick reference table before the first example (which would therefore mean before this howto which is replacing the first example).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14034>
_______________________________________

From report at bugs.python.org  Tue Feb 21 11:50:35 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 21 Feb 2012 10:50:35 +0000
Subject: [issue14068] problem with re split
In-Reply-To: <1329792996.32.0.66370663671.issue14068@psf.upfronthosting.co.za>
Message-ID: <1329821435.87.0.185174643316.issue14068@psf.upfronthosting.co.za>


Ramchandra Apte <maniandram01 at gmail.com> added the comment:

The problem is not in re, it is because you are passing '?' to re.split which in Python 2.x is actually passed as '\xe3\x80\x82'.
You should pass u'?' to re.compile.
Could we raise a SyntaxError when in a progam a unicode character is in a bytes string?
Python 3 does so; it raises "SyntaxError: bytes can only contain ASCII literal characters." when you execute b'?'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14068>
_______________________________________

From report at bugs.python.org  Tue Feb 21 12:37:41 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Feb 2012 11:37:41 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1329806855.92.0.0812627982675.issue13703@psf.upfronthosting.co.za>
Message-ID: <1329824057.3401.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> That is a good question.  I don't really care either way, but let's
> say +0 for turning it off when seed == 0.

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Tue Feb 21 13:11:46 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 21 Feb 2012 12:11:46 +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: <E1RzoZM-0001wq-RI@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e67715b87131 by Petri Lehtinen in branch '3.2':
sqlite3: Fix 64-bit integer handling in user functions on 32-bit architectures
http://hg.python.org/cpython/rev/e67715b87131

New changeset cf12fe9ce2b0 by Petri Lehtinen in branch 'default':
Merge branch '3.2'
http://hg.python.org/cpython/rev/cf12fe9ce2b0

New changeset 789a3ea97083 by Petri Lehtinen in branch '2.7':
sqlite3: Fix 64-bit integer handling in user functions on 32-bit architectures
http://hg.python.org/cpython/rev/789a3ea97083

----------
nosy: +python-dev
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8033>
_______________________________________

From report at bugs.python.org  Tue Feb 21 13:53:04 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Feb 2012 12:53:04 +0000
Subject: [issue14071] allow more than one hash seed per process (move
	_Py_HashSecret into PyInterpreterState)
In-Reply-To: <1329807287.0.0.916593271901.issue14071@psf.upfronthosting.co.za>
Message-ID: <1329828784.89.0.725188580752.issue14071@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +grahamd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14071>
_______________________________________

From report at bugs.python.org  Tue Feb 21 14:16:02 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 21 Feb 2012 13:16: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: <1329830162.35.0.0128452420897.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Latest version looks good to me - I vote for landing it whenever you're ready :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Tue Feb 21 15:12:08 2012
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 21 Feb 2012 14:12:08 +0000
Subject: [issue14073] allow per-thread atexit()
Message-ID: <1329833528.5.0.177059033602.issue14073@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

If you try to run the code below and stop it with ctrl+C, it will lock because atexit is never reached.

Antoine proposed to add a way to have one atexit() per thread, so we can call some cleanup code when the app shuts down and there are running threads.


{{{
from wsgiref.simple_server import make_server
import threading
import time
import atexit


class Work(threading.Thread):
    def __init__(self):
        threading.Thread.__init__(self)
        self.running = False

    def run(self):
        self.running = True
        while self.running:
            time.sleep(.2)

    def stop(self):
        self.running = False
        self.join()

worker = Work()


def shutdown():
    # bye-bye
    print 'bye bye'
    worker.stop()


atexit.register(shutdown)


def hello_world_app(environ, start_response):
    status = '200 OK' # HTTP Status
    headers = [('Content-type', 'text/plain')]
    start_response(status, headers)
    return ["Hello World"]

def main():
    worker.start()
    return make_server('', 8000, hello_world_app)

if __name__ == '__main__':
    server = main()
    server.serve_forever()
}}}

----------
messages: 153871
nosy: tarek
priority: normal
severity: normal
status: open
title: allow per-thread atexit()
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14073>
_______________________________________

From report at bugs.python.org  Tue Feb 21 15:12:59 2012
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 21 Feb 2012 14:12:59 +0000
Subject: [issue14073] allow per-thread atexit()
In-Reply-To: <1329833528.5.0.177059033602.issue14073@psf.upfronthosting.co.za>
Message-ID: <1329833579.8.0.737219435987.issue14073@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14073>
_______________________________________

From report at bugs.python.org  Tue Feb 21 15:18:14 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Feb 2012 14:18:14 +0000
Subject: [issue14073] allow per-thread atexit()
In-Reply-To: <1329833528.5.0.177059033602.issue14073@psf.upfronthosting.co.za>
Message-ID: <1329833894.88.0.161347446872.issue14073@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Interpreter Core, Library (Lib)
nosy: +neologix
type: behavior -> enhancement
versions:  -Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14073>
_______________________________________

From report at bugs.python.org  Tue Feb 21 16:33:38 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 21 Feb 2012 15:33:38 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <4F436875.6070506@egenix.com>
Message-ID: <20120220231126.66b3d2f5@resist.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Feb 21, 2012, at 09:48 AM, Marc-Andre Lemburg wrote:

>Exposing the seed value as sys.hashseed would be better and more useful
>to applications.

That makes the most sense to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Tue Feb 21 16:42:34 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 21 Feb 2012 15:42:34 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <4F436875.6070506@egenix.com>
Message-ID: <20120220232024.302d3221@resist.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Feb 21, 2012, at 09:48 AM, Marc-Andre Lemburg wrote:

>The flag should probably be removed - simply because
>the env var is not a flag, it's a configuration parameter.
>
>Exposing the seed value as sys.hashseed would be better and more useful
>to applications.

Okay, after chatting with __ap__ on irc, here's what I think the behavior
should be:

sys.flags.hash_randomization should contain just the value given by the -R
flag.  It should only be True if the flag is present, False otherwise.

sys.hash_seed contains the hash seed, set by virtue of the flag or envar.  It
should contain the *actual* seed value used.  E.g. it might be zero, the
explicitly set integer, or the randomly selected seed value in use during this
Python execution if a random seed was requested.

If you really need the envar value, getenv('PYTHONHASHSEED') is good enough
for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Tue Feb 21 17:07:39 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 21 Feb 2012 16:07:39 +0000
Subject: =?utf-8?q?=5Bissue10580=5D_Minor_grammar_change_in_Python=E2=80=99s_MSI_i?=
	=?utf-8?q?nstaller?=
In-Reply-To: <1291053115.29.0.21132112584.issue10580@psf.upfronthosting.co.za>
Message-ID: <E1RzsFe-0002XY-2J@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d9e895d07396 by Martin v. L?wis in branch '2.7':
Issue #10580: Minor grammar change in Windows installer.
http://hg.python.org/cpython/rev/d9e895d07396

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10580>
_______________________________________

From report at bugs.python.org  Tue Feb 21 17:26:31 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 21 Feb 2012 16:26:31 +0000
Subject: =?utf-8?q?=5Bissue10580=5D_Minor_grammar_change_in_Python=E2=80=99s_MSI_i?=
	=?utf-8?q?nstaller?=
In-Reply-To: <1291053115.29.0.21132112584.issue10580@psf.upfronthosting.co.za>
Message-ID: <E1RzsXo-0004vm-M5@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b349c932765a by Martin v. L?wis in branch '3.2':
Issue #10580: Minor grammar change in Windows installer.
http://hg.python.org/cpython/rev/b349c932765a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10580>
_______________________________________

From report at bugs.python.org  Tue Feb 21 17:26:59 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 21 Feb 2012 16:26:59 +0000
Subject: =?utf-8?q?=5Bissue10580=5D_Minor_grammar_change_in_Python=E2=80=99s_MSI_i?=
	=?utf-8?q?nstaller?=
In-Reply-To: <1291053115.29.0.21132112584.issue10580@psf.upfronthosting.co.za>
Message-ID: <1329841619.21.0.576026510532.issue10580@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is now fixed in all relevant branches.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10580>
_______________________________________

From report at bugs.python.org  Tue Feb 21 17:28:11 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 21 Feb 2012 16:28:11 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <20120220232024.302d3221@resist.wooz.org>
Message-ID: <CAGE7PN+SFT85_mn_vRe+_T=zcXEUorCj304f5tnobQiPMGq_Jg@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

+1 to what barry and __ap__ discussed and settled on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Tue Feb 21 17:44:40 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 21 Feb 2012 16:44:40 +0000
Subject: [issue13863] import.c sometimes generates incorrect timestamps on
	Windows + NTFS
In-Reply-To: <1327519681.79.0.252690630069.issue13863@psf.upfronthosting.co.za>
Message-ID: <1329842680.9.0.903933171971.issue13863@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

For some reason that I'm unable to follow right now, fstat in the crt does this dance to obtain st_mtime:
- obtain time stamps using GetFileInformationByHandle
- convert ftLastWriteTime using FileTimeToLocalFileTime to LocalFTime
- convert LocalFTime using FileTimeToSystemTime to SystemTime
- convert SystemTime using __loctotime32_t to st_mtime

Now, SystemTime is broken-down local time, and loctotime32 converts that to "UTC" using an explicit formula taking the *current* time zone into account. This should work correctly, though, as FileTimeToLocalFileTime also takes into account the current time zone.

Anybody analysing this further might want to write a C program that passes explicit time values into this procedure (see Vc/crt/src/fstat.c and dtoxtime.c for the exact source code), to find out what step exactly goes wrong.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13863>
_______________________________________

From report at bugs.python.org  Tue Feb 21 18:08:21 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 21 Feb 2012 17:08:21 +0000
Subject: [issue6807] No such file or directory: 'msisupport.dll' in msi.py
In-Reply-To: <1251629956.22.0.252677555531.issue6807@psf.upfronthosting.co.za>
Message-ID: <E1RztCN-0001LB-HQ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset bc66484b0d73 by Martin v. L?wis in branch '3.2':
Issue #6807: Run msisupport.mak earlier.
http://hg.python.org/cpython/rev/bc66484b0d73

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6807>
_______________________________________

From report at bugs.python.org  Tue Feb 21 18:12:09 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 21 Feb 2012 17:12:09 +0000
Subject: [issue6807] No such file or directory: 'msisupport.dll' in msi.py
In-Reply-To: <1251629956.22.0.252677555531.issue6807@psf.upfronthosting.co.za>
Message-ID: <E1RztG4-0001q0-0S@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e78acdb54841 by Martin v. L?wis in branch '2.7':
Issue #6807: Run msisupport.mak earlier.
http://hg.python.org/cpython/rev/e78acdb54841

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6807>
_______________________________________

From report at bugs.python.org  Tue Feb 21 18:12:38 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 21 Feb 2012 17:12:38 +0000
Subject: [issue6807] No such file or directory: 'msisupport.dll' in msi.py
In-Reply-To: <1251629956.22.0.252677555531.issue6807@psf.upfronthosting.co.za>
Message-ID: <1329844358.41.0.665066557481.issue6807@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is now fixed, though in a different way.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6807>
_______________________________________

From report at bugs.python.org  Tue Feb 21 18:16:55 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 21 Feb 2012 17:16:55 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
Message-ID: <1329844615.76.0.653445068505.issue1521950@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


Added file: http://bugs.python.org/file24590/079ab75d29a4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521950>
_______________________________________

From report at bugs.python.org  Tue Feb 21 18:27:36 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 21 Feb 2012 17:27:36 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
Message-ID: <1329845256.46.0.643149543593.issue1521950@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I updated the patch to reflect ?ric's comments on Rietveld, but there are also some other changes:

Previously when punctuation chars were set, wordchars was being augmented by '-'. This was incomplete, so the augmentation is now with '~-./*?=' which allows for wildcards, filename chars and argument flags.

I added a token_type attribute whose value is 'a' for alphanumeric tokens and 'c' for punctuation tokens. This token type is internally tracked anyway - we just expose it now. It is needed for when multiple punctuation tokens need to be disambiguated, because we might return two logically separate punctuation tokens as one if they are not separated by whitespace in the source being tokenised.

New attributes and the changes to wordchars have been documented, and a test added for token_type return values.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521950>
_______________________________________

From report at bugs.python.org  Tue Feb 21 18:37:04 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 21 Feb 2012 17:37:04 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
Message-ID: <1329845824.5.0.0907295943952.issue1521950@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Plus I also changed a few instances of the anachronism

a = a + b

to

a += b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521950>
_______________________________________

From report at bugs.python.org  Tue Feb 21 18:38:38 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Tue, 21 Feb 2012 17:38:38 +0000
Subject: [issue14074] argparse does not allow nargs>1 for positional arguments
	but doesn't allow metavar to be a tuple
Message-ID: <1329845918.75.0.31962840333.issue14074@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

Here's four commands to demonstrate my problem:

My sample code:
$ cat prog.py 
import argparse
parse = argparse.ArgumentParser()
parse.add_argument("foo", nargs=2, metavar=("foo", "bar"))
args = parse.parse_args()
print(args)

This output could be friendlier:
$ python3 prog.py --help
Traceback (most recent call last):
  File "prog.py", line 4, in <module>
    args = parse.parse_args()
  File "/home/wena/cpython/Lib/argparse.py", line 1722, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/home/wena/cpython/Lib/argparse.py", line 1754, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/home/wena/cpython/Lib/argparse.py", line 1960, in _parse_known_args
    start_index = consume_optional(start_index)
  File "/home/wena/cpython/Lib/argparse.py", line 1900, in consume_optional
    take_action(action, args, option_string)
  File "/home/wena/cpython/Lib/argparse.py", line 1828, in take_action
    action(self, namespace, argument_values, option_string)
  File "/home/wena/cpython/Lib/argparse.py", line 1015, in __call__
    parser.print_help()
  File "/home/wena/cpython/Lib/argparse.py", line 2347, in print_help
    self._print_message(self.format_help(), file)
  File "/home/wena/cpython/Lib/argparse.py", line 2314, in format_help
    formatter.add_arguments(action_group._group_actions)
  File "/home/wena/cpython/Lib/argparse.py", line 270, in add_arguments
    self.add_argument(action)
  File "/home/wena/cpython/Lib/argparse.py", line 255, in add_argument
    invocations = [get_invocation(action)]
  File "/home/wena/cpython/Lib/argparse.py", line 533, in _format_action_invocation
    metavar, = self._metavar_formatter(action, default)(1)
ValueError: too many values to unpack (expected 1)

On Python 3.2 (from Debian), I get "error: too few arguments". But with latest mercurial I get:
$ python3 prog.py
Traceback (most recent call last):
  File "prog.py", line 4, in <module>
    args = parse.parse_args()
  File "/home/wena/cpython/Lib/argparse.py", line 1722, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/home/wena/cpython/Lib/argparse.py", line 1754, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/home/wena/cpython/Lib/argparse.py", line 1973, in _parse_known_args
    ', '.join(required_actions))
TypeError: sequence item 0: expected str instance, tuple found

But this looks okay:
$ python3 prog.py a b
Namespace(foo=['a', 'b'])

----------
components: Library (Lib)
messages: 153884
nosy: tshepang
priority: normal
severity: normal
status: open
title: argparse does not allow nargs>1 for positional arguments but doesn't allow metavar to be a tuple
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14074>
_______________________________________

From report at bugs.python.org  Tue Feb 21 18:49:50 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 21 Feb 2012 17:49:50 +0000
Subject: [issue12406] msi.py needs updating for Python 3.3
In-Reply-To: <1308995950.75.0.288905614048.issue12406@psf.upfronthosting.co.za>
Message-ID: <E1RztqW-0005qY-In@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2fed68cf102a by Martin v. L?wis in branch 'default':
Issue #12406: prevent case where shortened name could conflict with short name.
http://hg.python.org/cpython/rev/2fed68cf102a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12406>
_______________________________________

From report at bugs.python.org  Tue Feb 21 18:55:02 2012
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 21 Feb 2012 17:55:02 +0000
Subject: [issue14060] Implement a CSP-style channel
In-Reply-To: <1329699366.61.0.518357475552.issue14060@psf.upfronthosting.co.za>
Message-ID: <1329846902.22.0.90361193148.issue14060@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I'd like to veto changing the meaning of 0, it's going to break somebody's code. It's easy enough to add some other keyword argument to request an unbuffered queue.  Other than that, (1) and (2) seem fine to me.  Please consider making these changes for multiprocessing as well.

For (3) I like the idea, but I think we should be more ambitious and instead add a way to wait for multiple locks (or other things) across the board, not just in the queue module.  (Maybe integrating with I/O waits as well, though that feels too ambitious, and is likely to stifle any attempts at a cross-platform implementation.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14060>
_______________________________________

From report at bugs.python.org  Tue Feb 21 19:01:39 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 21 Feb 2012 18:01:39 +0000
Subject: [issue8942] __path__ attribute of modules loaded by zipimporter is
	untested
In-Reply-To: <1276013732.57.0.515191754786.issue8942@psf.upfronthosting.co.za>
Message-ID: <1329847299.4.0.844954498891.issue8942@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/issue8942>
_______________________________________

From report at bugs.python.org  Tue Feb 21 19:10:04 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 21 Feb 2012 18:10:04 +0000
Subject: [issue14070] Idea: Add a flag to reload from source,
	e.g. reload(module, ignore_pyc=True)
In-Reply-To: <1329793221.07.0.0985593378146.issue14070@psf.upfronthosting.co.za>
Message-ID: <1329847804.99.0.155379307079.issue14070@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I don't quite follow what you want. You say you want to *ignore* changes to source files, but that's the whole point of a reload. And I don't see how ignoring bytecode changes anything unless you are mucking with bytecode formats and don't want to have to continuously change the magic number.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14070>
_______________________________________

From report at bugs.python.org  Tue Feb 21 19:14:25 2012
From: report at bugs.python.org (Tim McNamara)
Date: Tue, 21 Feb 2012 18:14:25 +0000
Subject: [issue14070] Idea: Add a flag to reload from source,
	e.g. reload(module, ignore_pyc=True)
In-Reply-To: <1329793221.07.0.0985593378146.issue14070@psf.upfronthosting.co.za>
Message-ID: <1329848065.95.0.673251654687.issue14070@psf.upfronthosting.co.za>


Tim McNamara <paperless at timmcnamara.co.nz> added the comment:

No no, I don't want to ignore source files. I want to be able to change a .py file, then reload in the Python shell and for the changes to be applied.

At the moment, .pyc files within a project complicate this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14070>
_______________________________________

From report at bugs.python.org  Tue Feb 21 19:16:39 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Tue, 21 Feb 2012 18:16:39 +0000
Subject: [issue14075] argparse: unused method?
Message-ID: <1329848199.77.0.390599674253.issue14075@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

It appears to me that the function I removed (see attached patch) is unused. Since I wasn't sure, I ran the entire test suite, and there wasn't a regression.

----------
components: Library (Lib)
files: rm-unused-function.patch
keywords: patch
messages: 153889
nosy: tshepang
priority: normal
severity: normal
status: open
title: argparse: unused method?
versions: Python 3.3
Added file: http://bugs.python.org/file24591/rm-unused-function.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14075>
_______________________________________

From report at bugs.python.org  Tue Feb 21 19:26:51 2012
From: report at bugs.python.org (mewalig)
Date: Tue, 21 Feb 2012 18:26:51 +0000
Subject: [issue9098] MSYS build fails with `S_IXGRP' undeclared
In-Reply-To: <1277729031.36.0.263470334817.issue9098@psf.upfronthosting.co.za>
Message-ID: <1329848811.95.0.130613269912.issue9098@psf.upfronthosting.co.za>


mewalig <mewalig at gmail.com> added the comment:

If I am reading this right, then in the below part of the patch, slave_name does not get set before it is used if __MINGW32__ is not defined. this can be fixed by moving the "#endif" up to the line before
    slave_name = ptsname(master_fd); /* get name of slave */



-------

+#if !defined(__MINGW32__)
     sig_saved = PyOS_setsig(SIGCHLD, SIG_DFL);
     /* change permission of slave */
     if (grantpt(master_fd) < 0) {
@@ -4143,10 +4156,15 @@
     slave_name = ptsname(master_fd); /* get name of slave */
     if (slave_name == NULL)
         return posix_error();
+#endif
+#if !defined(__MINGW32__)
     slave_fd = open(slave_name, O_RDWR | O_NOCTTY); /* open slave */
+#else
+    slave_fd = open(slave_name, O_RDWR); /* open slave */
+#endif

----------
nosy: +mewalig

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9098>
_______________________________________

From report at bugs.python.org  Tue Feb 21 19:33:46 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Feb 2012 18:33:46 +0000
Subject: [issue14067] Avoid more stat() calls in importlib
In-Reply-To: <1329772687.53.0.782755770398.issue14067@psf.upfronthosting.co.za>
Message-ID: <1329849226.86.0.569332604586.issue14067@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> While I don't think the delay in noticing filesystem changes is
> reasonable as the default behaviour, it might be interesting to see how 
> tricky it would be to create a custom importer (for either meta_path or 
> path_hooks) that did this.

Mmmh. Then I think it would be simpler to expose a global option to disable freshness checks. That said, it has to be activated as early as possible to be effective, which doesn't make it very practical as an opt-in setting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14067>
_______________________________________

From report at bugs.python.org  Tue Feb 21 19:54:26 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 21 Feb 2012 18:54:26 +0000
Subject: [issue14070] Idea: Add a flag to reload from source,
	e.g. reload(module, ignore_pyc=True)
In-Reply-To: <1329793221.07.0.0985593378146.issue14070@psf.upfronthosting.co.za>
Message-ID: <1329850466.87.0.596439138185.issue14070@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Then I'm not understanding the problem as changes to source trump .pyc files in a reload(). It should make no difference that .pyc files even exist to a reload() as long as source is around.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14070>
_______________________________________

From report at bugs.python.org  Tue Feb 21 19:55:06 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 21 Feb 2012 18:55:06 +0000
Subject: [issue12406] msi.py needs updating for Python 3.3
In-Reply-To: <1308995950.75.0.288905614048.issue12406@psf.upfronthosting.co.za>
Message-ID: <E1Rzure-0004u4-SM@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 75990a013d4d by Martin v. L?wis in branch 'default':
Issue #12406: Update list of files.
http://hg.python.org/cpython/rev/75990a013d4d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12406>
_______________________________________

From report at bugs.python.org  Tue Feb 21 19:56:18 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 21 Feb 2012 18:56:18 +0000
Subject: [issue12406] msi.py needs updating for Python 3.3
In-Reply-To: <1308995950.75.0.288905614048.issue12406@psf.upfronthosting.co.za>
Message-ID: <1329850578.14.0.397433248783.issue12406@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

msi.py is now up-to-date as of 75990a013d4d. If further changes are made to the tree that require further changes to msi.py, a new issue should be opened.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12406>
_______________________________________

From report at bugs.python.org  Tue Feb 21 20:04:02 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 21 Feb 2012 19:04:02 +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: <1329851042.32.0.481371169049.issue8033@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Thanks for the patches, Philippe! I committed the latest one after some modifications.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8033>
_______________________________________

From report at bugs.python.org  Tue Feb 21 20:27:03 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 21 Feb 2012 19:27:03 +0000
Subject: [issue14075] argparse: unused method?
In-Reply-To: <1329848199.77.0.390599674253.issue14075@psf.upfronthosting.co.za>
Message-ID: <1329852423.71.0.825124099621.issue14075@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14075>
_______________________________________

From report at bugs.python.org  Tue Feb 21 20:39:32 2012
From: report at bugs.python.org (GuGu)
Date: Tue, 21 Feb 2012 19:39:32 +0000
Subject: [issue14076] sqlite3 module ignores placeholers in CREATE TRIGGER code
Message-ID: <1329853172.58.0.728674289337.issue14076@psf.upfronthosting.co.za>


New submission from GuGu <andrey at kostenko.name>:

When I try to use placeholders in CREATE TRIGGER (for django-denorm module) SQLite module just ignores placeholders and sends `None` to it.

For example:

  In [11]: c.cursor().execute('CREATE TRIGGER test1 after insert on a for each row begin UPDATE a SET b=?; END', '1').fetchone()

  In [12]: c.cursor().execute('INSERT INTO a values (100)')
  Out[12]: <pysqlite2.dbapi2.Cursor at 0x101d77e30>

  In [13]: c.cursor().execute('SELECT * FROM a').fetchall()
  Out[13]: [(None,), (None,), (None,)]

  In [14]: c.cursor().execute('DROP TRIGGER test1')
  Out[14]: <pysqlite2.dbapi2.Cursor at 0x101d77f10>

  In [15]: c.cursor().execute('CREATE TRIGGER test1 after insert on a for each row begin UPDATE a SET b=1; END').fetchone()

  In [16]: c.cursor().execute('INSERT INTO a values (100)')
  Out[16]: <pysqlite2.dbapi2.Cursor at 0x101d77f80>

  In [17]: c.cursor().execute('SELECT * FROM a').fetchall()
  Out[17]: [(u'1',), (u'1',), (u'1',), (u'1',)]

In MySQLdb and psycopg2 creating triggers with a placeholder works.

----------
components: Library (Lib)
messages: 153896
nosy: GuGu
priority: normal
severity: normal
status: open
title: sqlite3 module ignores placeholers in CREATE TRIGGER code
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14076>
_______________________________________

From report at bugs.python.org  Tue Feb 21 21:24:59 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 21 Feb 2012 20:24:59 +0000
Subject: [issue14075] argparse: unused method?
In-Reply-To: <1329848199.77.0.390599674253.issue14075@psf.upfronthosting.co.za>
Message-ID: <1329855899.35.0.106694930668.issue14075@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

The _get_args() looks like an obsolete function indeed. However, _AttributeHolder is a base class for other classes, so the function was probably meant to be overridden by a subclass.

Steven probably knows the best whether it should be kept or not.

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14075>
_______________________________________

From report at bugs.python.org  Tue Feb 21 21:32:15 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Feb 2012 20:32:15 +0000
Subject: [issue14077] sporadic test_multiprocessing failure
Message-ID: <1329856335.15.0.565948372805.issue14077@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Just saw this on a buildbot:

======================================================================
ERROR: test_rapid_restart (test.test_multiprocessing.WithProcessesTestManagerRestart)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/test/test_multiprocessing.py", line 1513, in test_rapid_restart
    queue = manager.get_queue()
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/multiprocessing/managers.py", line 666, in temp
    token, exp = self._create(typeid, *args, **kwds)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/multiprocessing/managers.py", line 564, in _create
    conn = self._Client(self._address, authkey=self._authkey)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/multiprocessing/connection.py", line 773, in XmlClient
    import xmlrpc.client as xmlrpclib
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/importlib/_bootstrap.py", line 542, in load_module
    return self._load_module(fullname)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/importlib/_bootstrap.py", line 220, in module_for_loader_wrapper
    return fxn(self, module, *args, **kwargs)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/importlib/_bootstrap.py", line 424, in _load_module
    code_object = self.get_code(name)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/importlib/_bootstrap.py", line 529, in get_code
    self.set_data(bytecode_path, data)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/importlib/_bootstrap.py", line 597, in set_data
    _write_atomic(path, data)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/importlib/_bootstrap.py", line 134, in _write_atomic
    fd = _os.open(path_tmp, _os.O_EXCL | _os.O_CREAT | _os.O_WRONLY, 0o666)
FileExistsError: [Errno 17] File exists: '/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/xmlrpc/__pycache__/__init__.cpython-33.pyc.140684930127088'

(http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/3288 )

----------
components: Library (Lib)
messages: 153898
nosy: brett.cannon, neologix, pitrou
priority: normal
severity: normal
status: open
title: sporadic test_multiprocessing failure
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14077>
_______________________________________

From report at bugs.python.org  Tue Feb 21 21:33:11 2012
From: report at bugs.python.org (Leon Matthews)
Date: Tue, 21 Feb 2012 20:33:11 +0000
Subject: [issue14006] Improve the documentation of xml.etree.ElementTree
In-Reply-To: <1329190125.69.0.69162565954.issue14006@psf.upfronthosting.co.za>
Message-ID: <1329856391.1.0.956791562549.issue14006@psf.upfronthosting.co.za>


Leon Matthews <leon at lost.co.nz> added the comment:

The ElementTree.py module has good JavaDoc-style function-level documentation, but as it's not in docstring format, it can't be seen from the interactive help.

I'd be willing to convert the current comments into docstrings, as long as I wouldn't be stepping on anybody's toes, and somebody could give me some guidance as to how to convert the @return and @param declarations, and how to handle the C version of the module.  

Any volunteers?

----------
nosy: +leonov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14006>
_______________________________________

From report at bugs.python.org  Tue Feb 21 21:37:49 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Feb 2012 20:37:49 +0000
Subject: [issue14077] sporadic test_multiprocessing failure
In-Reply-To: <1329856335.15.0.565948372805.issue14077@psf.upfronthosting.co.za>
Message-ID: <1329856669.7.0.228910710943.issue14077@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I am proposing the following patch to have a better unique filename:

diff --git a/Lib/importlib/_bootstrap.py b/Lib/importlib/_bootstrap.py
--- a/Lib/importlib/_bootstrap.py
+++ b/Lib/importlib/_bootstrap.py
@@ -129,8 +129,8 @@ def _path_absolute(path):
 
 def _write_atomic(path, data):
     """Function to write data to a path atomically."""
-    # id() is used to generate a pseudo-random filename.
-    path_tmp = '{}.{}'.format(path, id(path))
+    # getpid() and id() are used to generate a pseudo-random filename.
+    path_tmp = '{}.{}-{}'.format(path, _os.getpid(), id(path))
     fd = _os.open(path_tmp, _os.O_EXCL | _os.O_CREAT | _os.O_WRONLY, 0o666)
     try:
         # We first write data to a temporary file, and then use os.replace() to

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14077>
_______________________________________

From report at bugs.python.org  Tue Feb 21 21:55:21 2012
From: report at bugs.python.org (Geoffrey Spear)
Date: Tue, 21 Feb 2012 20:55:21 +0000
Subject: [issue14075] argparse: unused method?
In-Reply-To: <1329848199.77.0.390599674253.issue14075@psf.upfronthosting.co.za>
Message-ID: <1329857721.56.0.155382653227.issue14075@psf.upfronthosting.co.za>


Changes by Geoffrey Spear <geoffspear at gmail.com>:


----------
nosy: +geoffreyspear

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14075>
_______________________________________

From report at bugs.python.org  Tue Feb 21 22:34:42 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 21 Feb 2012 21:34:42 +0000
Subject: [issue14077] sporadic test_multiprocessing failure
In-Reply-To: <1329856335.15.0.565948372805.issue14077@psf.upfronthosting.co.za>
Message-ID: <1329860082.1.0.387606033385.issue14077@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

LGTM

----------
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14077>
_______________________________________

From report at bugs.python.org  Tue Feb 21 22:44:16 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Feb 2012 21:44:16 +0000
Subject: [issue14071] allow more than one hash seed per process (move
	_Py_HashSecret into PyInterpreterState)
In-Reply-To: <1329807287.0.0.916593271901.issue14071@psf.upfronthosting.co.za>
Message-ID: <1329860656.17.0.646708603088.issue14071@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I'm not sure that it could work because many C functions use caches using static variables.

Just a random example:
int
_PyUnicode_HasNULChars(PyObject* s)
{
    static PyObject *nul = NULL;

    if (nul == NULL)
        nul = PyUnicode_FromStringAndSize("\0", 1);
    if (nul == NULL)
        return -1;
    return PyUnicode_Contains(s, nul);
}

If hash(nul) is computed in an interpreter, the same hash value will be used by all interpreters. If interpreters use a different hash secret, you will have a problem.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14071>
_______________________________________

From report at bugs.python.org  Tue Feb 21 22:50:16 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Tue, 21 Feb 2012 21:50:16 +0000
Subject: [issue14053] Make patchcheck work with MQ
In-Reply-To: <1329661471.35.0.733956428931.issue14053@psf.upfronthosting.co.za>
Message-ID: <1329861016.35.0.0857982679154.issue14053@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

Ok! I haven't added NEWS as I thing is easier for the person that applies the patch to simply write the line directly there instead of merging. Is that ok? let me know if something has to be improved. 

Thanks again for your mentoring this!

----------
Added file: http://bugs.python.org/file24592/issue14053_2cceb4d3079a.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14053>
_______________________________________

From report at bugs.python.org  Tue Feb 21 23:02:43 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 21 Feb 2012 22:02:43 +0000
Subject: [issue14077] sporadic test_multiprocessing failure
In-Reply-To: <1329856335.15.0.565948372805.issue14077@psf.upfronthosting.co.za>
Message-ID: <1329861763.14.0.38371912721.issue14077@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I am proposing the following patch to have a better unique
> filename:

It's unneeded, O_EXCL ensures the file won't be corrupted.
It's actually a regression introduced by de6703671386. My bad.
Here's a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file24593/atomic_exists.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14077>
_______________________________________

From report at bugs.python.org  Tue Feb 21 23:11:04 2012
From: report at bugs.python.org (Graham Dumpleton)
Date: Tue, 21 Feb 2012 22:11:04 +0000
Subject: [issue14073] allow per-thread atexit()
In-Reply-To: <1329833528.5.0.177059033602.issue14073@psf.upfronthosting.co.za>
Message-ID: <1329862264.45.0.72201288046.issue14073@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

My take on this is that if wanting to interact with a thread from an atexit callback, you are supposed to call setDaemon(True) on the thread. This is to ensure that on interpreter shutdown it doesn't try and wait on the thread completing before getting to atexit callbacks.

----------
nosy: +grahamd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14073>
_______________________________________

From report at bugs.python.org  Tue Feb 21 23:11:55 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Feb 2012 22:11:55 +0000
Subject: [issue14077] sporadic test_multiprocessing failure
In-Reply-To: <1329861763.14.0.38371912721.issue14077@psf.upfronthosting.co.za>
Message-ID: <1329862109.3401.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > I am proposing the following patch to have a better unique
> > filename:
> 
> It's unneeded, O_EXCL ensures the file won't be corrupted.
> It's actually a regression introduced by de6703671386. My bad.
> Here's a patch.

But is there still a reason to use id(path) then?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14077>
_______________________________________

From report at bugs.python.org  Tue Feb 21 23:25:34 2012
From: report at bugs.python.org (Leon Matthews)
Date: Tue, 21 Feb 2012 22:25:34 +0000
Subject: [issue14078] Add 'sourceline' property to xml.etree Elements
Message-ID: <1329863134.79.0.699697784351.issue14078@psf.upfronthosting.co.za>


New submission from Leon Matthews <leon at lost.co.nz>:

The lxml implementation of the ElementTree API puts a `sourceline` property onto every Element object, which I recently found useful when producing diagnostic messages.  I think it would be a useful improvement to make the standard library's ElementTree implementation.

The attached patch works by copying the current line number from the Expat parser into the Element object after the Element object is created (so as to minimise its intrusiveness for now).

The patch is just a proof of concept, and although all tests pass, the patch currently smells a little hacky and fragile to me.  Hopefully though, it will start a discussion with somebody more experienced.

PS. So as not to create a hard dependency on lxml.etree, in my project I worked around the issue as follows.  While this works in my case, the standard library seems a more logical place for this change::

    class XMLParserWithLines(XMLParser):
        """
        Add a `sourceline` attribute to element, like lxml.etree
        """
        def _start_list(self, *args, **kwargs):
            element = super(self.__class__, self)._start_list(*args, **kwargs)
        element.sourceline = self._parser.CurrentLineNumber
        return element

    
    >>> tree = ElementTree()
    >>> tree.parse(path, parser=XMLParserWithLines())
    >>> ...

----------
components: Library (Lib)
files: elementtree-sourceline.diff
keywords: patch
messages: 153907
nosy: leonov
priority: normal
severity: normal
status: open
title: Add 'sourceline' property to xml.etree Elements
versions: Python 3.3
Added file: http://bugs.python.org/file24594/elementtree-sourceline.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14078>
_______________________________________

From report at bugs.python.org  Tue Feb 21 23:26:15 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 21 Feb 2012 22:26:15 +0000
Subject: [issue14077] sporadic test_multiprocessing failure
In-Reply-To: <1329862109.3401.4.camel@localhost.localdomain>
Message-ID: <CAH_1eM0PGT4LoXAvfL+dmFcRhR_3FzJ4YeJy2SEAKGF1H=AB6w@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> But is there still a reason to use id(path) then?

IIRC, the reason is to avoid having a stale pyc file indefinitely in
case of crash:
if we always used, let's say, path + '.tmp', if the process crashes
before the rename, then all subsequent attempts to write the bytecode
will fail because of the stale temporary file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14077>
_______________________________________

From report at bugs.python.org  Tue Feb 21 23:35:25 2012
From: report at bugs.python.org (Steven Bethard)
Date: Tue, 21 Feb 2012 22:35:25 +0000
Subject: [issue14075] argparse: unused method?
In-Reply-To: <1329848199.77.0.390599674253.issue14075@psf.upfronthosting.co.za>
Message-ID: <1329863725.26.0.535063057487.issue14075@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Yeah, the intention was that you could just override _get_args in a subclass to get a better __repr__. I think these days all the argparse classes only have keyword arguments, so _get_args probably isn't necessary anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14075>
_______________________________________

From report at bugs.python.org  Tue Feb 21 23:36:07 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Feb 2012 22:36:07 +0000
Subject: [issue14077] sporadic test_multiprocessing failure
In-Reply-To: <CAH_1eM0PGT4LoXAvfL+dmFcRhR_3FzJ4YeJy2SEAKGF1H=AB6w@mail.gmail.com>
Message-ID: <1329863561.3401.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> IIRC, the reason is to avoid having a stale pyc file indefinitely in
> case of crash:
> if we always used, let's say, path + '.tmp', if the process crashes
> before the rename, then all subsequent attempts to write the bytecode
> will fail because of the stale temporary file.

But that will also fail if id(path) happens to be fairly
deterministic :) I don't know how much deterministic it can be in
practice, that probably depends on the OS and on the code path?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14077>
_______________________________________

From report at bugs.python.org  Tue Feb 21 23:51:33 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 21 Feb 2012 22:51:33 +0000
Subject: [issue14077] sporadic test_multiprocessing failure
In-Reply-To: <1329856335.15.0.565948372805.issue14077@psf.upfronthosting.co.za>
Message-ID: <1329864693.77.0.0470189552052.issue14077@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> But that will also fail if id(path) happens to be fairly
> deterministic

Well, if you always get the same id(path), then yes, but I really doubt it, especially with CPython where it's the object's address (I guess there's the same chance of having varying IDs in other implementations):
"""
$ ./python -c "import io; print(id(io.__file__))"
3073909832
$ ./python -c "import io; print(id(io.__file__))"
3073963080
"""

In case of multiprocessing there was a collision because the import is done just after fork(), but the id() will likely change eventually.

If we wanted to be 100% bullet-proof, then we'll need something like mkstemp()/NamedTemporaryFile(), which we can't use because of bootstraping issues.
Of course, adding the PID won't hurt (except that it's a syscall, and will pollute strace's output ;-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14077>
_______________________________________

From report at bugs.python.org  Tue Feb 21 23:56:51 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 21 Feb 2012 22:56:51 +0000
Subject: [issue14079] Problems with recent test_subprocess changes
Message-ID: <1329865011.81.0.762834414848.issue14079@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

There appears to be a problem with a recent change made to test_subprocess to try and speed it up a bit. The commit with a problem seems to be 834650d63130 by Ross Lagerwall on 12 Feb 2012, and the problem is in test_poll(), which now looks like this:

    def test_poll(self):
        p = subprocess.Popen([sys.executable, "-c",
                              "import os",
                              "os.read(1)"], stdin=subprocess.PIPE)
        self.addCleanup(p.stdin.close)
        self.assertIsNone(p.poll())
        os.write(p.stdin.fileno(), b'A')
        p.wait()
        # Subsequent invocations should just return the returncode
        self.assertEqual(p.poll(), 0)

A number of problems here: -c only takes one parameter, so for example

./python -c "import os" "os.read(1)"

never does anything with the "os.read(1)". Possibly

"import os; os.read(1)"

was meant, but that doesn't work either: os.read takes two parameters, fd and n, so it seems that what is wanted is

"import os; os.read(0, 1)"

which appears to fulfill the intent to read a byte from stdin.

Because the command being run is effectively

python -c "import os"

the spawned command returns immediately. This (it would appear) leads to a race between the test process and the spawned process, such that sometimes the poll() returns None and sometimes it returns 0, due to the vagaries of the exact circumstances when the test is run. So the test passes on some machines but not on others.

It looks like it would be good to change the Popen call to use "import os; os.read(0, 1)" as the "-c" parameter value.

----------
messages: 153912
nosy: rosslagerwall, vinay.sajip
priority: normal
severity: normal
status: open
title: Problems with recent test_subprocess changes
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14079>
_______________________________________

From report at bugs.python.org  Wed Feb 22 00:15:23 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 21 Feb 2012 23:15:23 +0000
Subject: [issue14052] importlib mixes up '.' and os.getcwd()
In-Reply-To: <1329597527.35.0.680600221226.issue14052@psf.upfronthosting.co.za>
Message-ID: <1329866123.55.0.129213410838.issue14052@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

It just happened again on the new FreeBSD-9.0 bot:

http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/1845/steps/test/logs/stdio

======================================================================
FAIL: test_package___file__ (test.test_imp.PEP3147Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_imp.py", line 333, in test_package___file__
    os.sep.join(('.', 'pep3147', '__init__.py')))
AssertionError: 'pep3147/__init__.py' != './pep3147/__init__.py'
- pep3147/__init__.py
+ ./pep3147/__init__.py
? ++

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14052>
_______________________________________

From report at bugs.python.org  Wed Feb 22 00:21:06 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Feb 2012 23:21:06 +0000
Subject: [issue14057] Speedup sysconfig startup
In-Reply-To: <1329695235.07.0.0035365594313.issue14057@psf.upfronthosting.co.za>
Message-ID: <1329866466.45.0.419917455665.issue14057@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Updated patch: continue to simplify the config parser. Using this patch, Python startup is ~20% faster on my computer.

Use http://bugs.python.org/file24447/bench_startup.py to measure startup time.

----------
Added file: http://bugs.python.org/file24595/sysconfig_parser-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14057>
_______________________________________

From report at bugs.python.org  Wed Feb 22 00:21:12 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Feb 2012 23:21:12 +0000
Subject: [issue14057] Speedup sysconfig startup
In-Reply-To: <1329695235.07.0.0035365594313.issue14057@psf.upfronthosting.co.za>
Message-ID: <1329866472.01.0.857052765383.issue14057@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file24572/sysconfig_parser.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14057>
_______________________________________

From report at bugs.python.org  Wed Feb 22 00:48:01 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 21 Feb 2012 23:48:01 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1329868081.87.0.920127005553.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Dave, I am in Europe (Spain), and I can't afford (money and time) to go to PyCon. If you are going and are interested in pushing this, we can talk about our respectives ideas and plans, to present a consensus plan.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Wed Feb 22 00:51:29 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Feb 2012 23:51:29 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
In-Reply-To: <1313884051.29.0.336736419117.issue12801@psf.upfronthosting.co.za>
Message-ID: <1329868289.43.0.901396663923.issue12801@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

realpath.patch:

 - Add os.realpath()
 - posixpath.realpath() uses os.realpath(), or os.getcwd() if the path is an empty string
 - os.realpath() uses canonicalize_file_name() if available, or use realpath() with a buffer of MAXPATHLEN bytes

Don't use realpath(path, NULL) because it is not possible to test if realpath() supports NULL: OpenBSD did segfault if the buffer was NULL. Testing the support in configure is not a good idea because it depends on the version of the C library. You may use a more recent C library to compile Python for example.

genericpath, macpath and os2emxpath are not patched to use os.realpath(), even if it is available. I don't know if these modules should be patched. ntpath uses the native Windows function (if available): GetFullPathNameW().

----------
Added file: http://bugs.python.org/file24596/realpath.path

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12801>
_______________________________________

From report at bugs.python.org  Wed Feb 22 02:36:02 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Feb 2012 01:36:02 +0000
Subject: [issue14080] Sporadic test_imp failure
Message-ID: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/1845/steps/test/logs/stdio

======================================================================
FAIL: test_package___file__ (test.test_imp.PEP3147Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_imp.py", line 333, in test_package___file__
    os.sep.join(('.', 'pep3147', '__init__.py')))
AssertionError: 'pep3147/__init__.py' != './pep3147/__init__.py'
- pep3147/__init__.py
+ ./pep3147/__init__.py
? ++

----------
components: Library (Lib), Tests
messages: 153917
nosy: brett.cannon, ncoghlan, pitrou, skrah
priority: normal
severity: normal
status: open
title: Sporadic test_imp failure
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Wed Feb 22 02:45:29 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Feb 2012 01:45:29 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1329875129.22.0.389218415542.issue14080@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated build URL (the buildbot changed name):
http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/1845/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Wed Feb 22 02:51:35 2012
From: report at bugs.python.org (harvey yang)
Date: Wed, 22 Feb 2012 01:51:35 +0000
Subject: [issue14068] problem with re split
In-Reply-To: <1329792996.32.0.66370663671.issue14068@psf.upfronthosting.co.za>
Message-ID: <1329875495.37.0.869066106308.issue14068@psf.upfronthosting.co.za>


harvey yang <yangqilang at gmail.com> added the comment:

i see. thanks :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14068>
_______________________________________

From report at bugs.python.org  Wed Feb 22 02:54:10 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 22 Feb 2012 01:54:10 +0000
Subject: [issue14081] Allow "maxsplit" argument to str.split() to be passed as
	a keyword argument
Message-ID: <1329875650.41.0.375574316124.issue14081@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Currently, setting maxsplit for the default "any whitespace" behaviour requires the following cryptic incantation:

    'do re mi fa'.split(None, 1)

That would be significantly more comprehensible as:

    'do re mi fa'.split(maxsplit=1)

(I noticed this when trying to figure out why http://hyperpolyglot.org/scripting#split-notes resorted to using the re module to achieve this)

----------
components: Interpreter Core
messages: 153920
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Allow "maxsplit" argument to str.split() to be passed as a keyword argument
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14081>
_______________________________________

From report at bugs.python.org  Wed Feb 22 03:01:12 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 22 Feb 2012 02:01:12 +0000
Subject: [issue14068] problem with re split
In-Reply-To: <1329792996.32.0.66370663671.issue14068@psf.upfronthosting.co.za>
Message-ID: <1329876072.69.0.349013967937.issue14068@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

As long as you don't mix str and unicode everything works.

With strings:
>>> s = '???????'
>>> re.split('?', s)
['\xe4\xb8\x8e\xe6\xb8\x85\xe6\x96\xb0', '\xe9\x98\xbf\xe5\xbe\xb7\xe8\x8e\xb1']
>>> s.split('?')
['\xe4\xb8\x8e\xe6\xb8\x85\xe6\x96\xb0', '\xe9\x98\xbf\xe5\xbe\xb7\xe8\x8e\xb1']

With unicode:
>>> u = u'???????'
>>> re.split(u'?', u)
[u'\u4e0e\u6e05\u65b0', u'\u963f\u5fb7\u83b1']
>>> u.split(u'?')
[u'\u4e0e\u6e05\u65b0', u'\u963f\u5fb7\u83b1']

Mixing str and unicode:
>>> re.split(u'?', s)
['\xe4\xb8\x8e\xe6\xb8\x85\xe6\x96\xb0\xe3\x80\x82\xe9\x98\xbf\xe5\xbe\xb7\xe8\x8e\xb1']
>>> re.split('?', u)
[u'\u4e0e\u6e05\u65b0\u3002\u963f\u5fb7\u83b1']
>>>
>>> s.split(u'?')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 0: ordinal not in range(128)
>>> u.split('?')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 0: ordinal not in range(128)


The syntax error is raised for byte literals and can't be backported to 2.7.  Raising an error when str and unicode are mixed in re is not backward compatible, and re does work as long as both are ASCII only.  I'm therefore closing this as invalid.

----------
nosy: +mrabarnett
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14068>
_______________________________________

From report at bugs.python.org  Wed Feb 22 03:14:03 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Feb 2012 02:14:03 +0000
Subject: [issue5411] Add xz support to shutil
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1329876843.24.0.902622038635.issue5411@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +hynek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5411>
_______________________________________

From report at bugs.python.org  Wed Feb 22 03:17:33 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Feb 2012 02:17:33 +0000
Subject: [issue14082] shutil doesn't support extended attributes
Message-ID: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

shutil doesn't provide any function which copies extended attributes on files. Note that "cp -a" does copy xattrs, but "cp -p" doesn't (and copy2() claims to work like "cp -p").

----------
components: Library (Lib)
messages: 153922
nosy: benjamin.peterson, hynek, neologix, pitrou
priority: low
severity: normal
status: open
title: shutil doesn't support extended attributes
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14082>
_______________________________________

From report at bugs.python.org  Wed Feb 22 03:27:40 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 22 Feb 2012 02:27:40 +0000
Subject: [issue14083] Use local timezone offset by default in datetime.timezone
Message-ID: <1329877660.24.0.480060426072.issue14083@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Currently, datetime.timezone requires that the offset be specified explicitly.

It would be more convenient if the local offset was used by default.

Since the time module already exposes the offset details for the local timezone, this would just make:

  local_tz = datetime.timezone()

equivalent to the current complex incantation:

  local_tz = datetime.timezone(datetime.timedelta(hours=(time.timezone / -3600 + tm.tm_isdst)))

Then getting a timezone aware version of the local time would just be:

  now = datetime.datetime.now(datetime.timezone())

Similar to the existing spelling for UTC:

  now = datetime.datetime.now(datetime.timezone.utc)

(Inspired by http://hyperpolyglot.org/scripting#timezone-offset-notes)

----------
components: Library (Lib)
messages: 153923
nosy: belopolsky, lemburg, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Use local timezone offset by default in datetime.timezone
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14083>
_______________________________________

From report at bugs.python.org  Wed Feb 22 04:16:52 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 22 Feb 2012 03:16:52 +0000
Subject: [issue14081] Allow "maxsplit" argument to str.split() to be passed as
	a keyword argument
In-Reply-To: <1329875650.41.0.375574316124.issue14081@psf.upfronthosting.co.za>
Message-ID: <1329880612.63.0.962412894708.issue14081@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

+1
Patch attached.

----------
assignee:  -> ezio.melotti
keywords: +patch
nosy: +ezio.melotti
stage: needs patch -> commit review
Added file: http://bugs.python.org/file24597/issue14081.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14081>
_______________________________________

From report at bugs.python.org  Wed Feb 22 04:25:19 2012
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 22 Feb 2012 03:25:19 +0000
Subject: [issue14083] Use local timezone offset by default in datetime.timezone
In-Reply-To: <1329877660.24.0.480060426072.issue14083@psf.upfronthosting.co.za>
Message-ID: <1329881119.11.0.292426322817.issue14083@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

The problem with this idea is that while evaluating datetime.datetime.now(datetime.timezone()), python will have to query the real time clock twice (first in timezone() and then in now()).  At a particularly unfortunate time this may result in an error.  Unlikely? Yes, but I would not board a python powered airplane if this problem was in the standard library.

I gave a lot of thought to the problem of supporting timezone aware local time and issue9527 was the best solution I was able to come up with.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14083>
_______________________________________

From report at bugs.python.org  Wed Feb 22 05:03:53 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 22 Feb 2012 04:03:53 +0000
Subject: [issue14079] Problems with recent test_subprocess changes
In-Reply-To: <1329865011.81.0.762834414848.issue14079@psf.upfronthosting.co.za>
Message-ID: <1329883433.32.0.563953946772.issue14079@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

This was hopefully fixed in e5a94b56d6bc.

Was it one of the buildbots that was failing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14079>
_______________________________________

From report at bugs.python.org  Wed Feb 22 05:23:56 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 22 Feb 2012 04:23:56 +0000
Subject: [issue14083] Use local timezone offset by default in datetime.timezone
In-Reply-To: <1329877660.24.0.480060426072.issue14083@psf.upfronthosting.co.za>
Message-ID: <1329884636.53.0.21787334588.issue14083@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Marking as a duplicate of #9527.

If that API is added, the local fixed offset timezone will be accessible as datetime.datetime.localtime().tzinfo which would be simple enough.

----------
resolution:  -> duplicate
superseder:  -> Add aware local time support to datetime module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14083>
_______________________________________

From report at bugs.python.org  Wed Feb 22 05:24:18 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 22 Feb 2012 04:24:18 +0000
Subject: [issue14083] Use local timezone offset by default in datetime.timezone
In-Reply-To: <1329877660.24.0.480060426072.issue14083@psf.upfronthosting.co.za>
Message-ID: <1329884658.39.0.973265226214.issue14083@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14083>
_______________________________________

From report at bugs.python.org  Wed Feb 22 05:36:03 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 22 Feb 2012 04:36:03 +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: <1329885363.04.0.682987816188.issue9527@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

One important thing to remember is that once a time is in the past, whether or not DST was in effect for that time *is never going to change*. That means converting a DST aware timezone to a fixed offset timezone will work just fine for historical times.

It's mainly applications that need to handle times in the *future* (where the DST dates are still subject to change) that have to be aware of the problems when trying to handle DST with fixed offset timezone objects.

I think it's sufficient if the documentation pushes developers of such applications towards modules like pytz and dateutil to get access to variable offset tzinfo implementations.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9527>
_______________________________________

From report at bugs.python.org  Wed Feb 22 08:28:28 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Wed, 22 Feb 2012 07:28:28 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1329895708.08.0.731154340525.issue13405@psf.upfronthosting.co.za>


Marc Abramowitz <msabramo at gmail.com> added the comment:

Jes?s said he was focusing on Solaris and couldn't help with OS X. Not sure if anyone else was going to try tackling that...

Just tried the patch `issue13405_4027.diff` on OS X 10.6.8.

First problem I ran into was:

gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes    -I. -I./Include    -DPy_BUILD_CORE -o ./Include/phelper_offsets \
		./Include/phelper_offsets.c
./Include/phelper_offsets.c: In function 'main':
./Include/phelper_offsets.c:23: warning: format '%d' expects type 'int', but argument 2 has type 'long int'
./Include/phelper_offsets.c:26: warning: format '%d' expects type 'int', but argument 2 has type 'long unsigned int'
./Include/phelper_offsets.c:28: warning: implicit declaration of function 'offsetof'
./Include/phelper_offsets.c:28: error: expected expression before 'PyCompactUnicodeObject'
./Include/phelper_offsets.c:30: error: expected expression before 'PyCompactUnicodeObject'
make: *** [Include/phelper_offsets.h] Error 1

OS X seems to have `offsetof` defined in `stddef.h` -- adding `#include <stddef.h>` got this to compile.

The next problem was with: 

```
if test "dtrace" != "" ; then \
		dtrace -o Python/phelper.o -DPHELPER -64 \
			-I. -I./Include   -C -G -s ./Include/phelper.d ; \
	else	touch Python/phelper.o ; \
	fi;
```

This fails because DTrace on OS X doesn't have the -G option. Removing the `-G` (total hack since it seems like `-G` is not at all a trivial option) results in:

```
dtrace: failed to initialize dtrace: DTrace requires additional privileges
```

Adding `sudo` isn't a practical solution, but I tried it to see if it would help or if there would be other errors and there was another error:

```
dtrace: ignored option -- 64
/dev/fd/5:42:8: warning: undefining "__STDC__"
dtrace: failed to compile script ./Include/phelper.d: "/usr/include/libkern/_OSByteOrder.h", line 98: specified storage class not appropriate in D
make: *** [Python/phelper.o] Error 1
```

----------
nosy: +Marc.Abramowitz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Wed Feb 22 09:00:18 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Wed, 22 Feb 2012 08:00:18 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1329897618.33.0.243620355468.issue13405@psf.upfronthosting.co.za>


Marc Abramowitz <msabramo at gmail.com> added the comment:

With an hg checkout, I don't run into the `offsetof` problem - it fails when it gets to calling dtrace to generate Python/dtrace.o (again -G is the culprit).

```
$ hg clone https://hg.jcea.es/cpython-2011/
$ cd cpython-2011
$ hg update dtrace-issue13405_2.7
$ ./configure --prefix=/Users/marca/custom --enable-shared --with-dtrace
...
$ make
...
$ make
if test "dtrace" != "" ; then \
		dtrace -o Python/dtrace.o -64 \
			-C -G -s ./Include/pydtrace.d \
				Python/ceval.o Modules/gcmodule.o \
				Objects/classobject.o Objects/typeobject.o; \
	else    touch Python/dtrace.o ; \
	fi;
dtrace: ignored option -- 64
Usage: dtrace [-aACeFHlqSvVwZ] [-arch i386|x86_64] [-b bufsz] [-c cmd] [-D name[=def]]
	[-I path] [-L path] [-o output] [-p pid] [-s script] [-U name]
	[-x opt[=val]]
...
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Wed Feb 22 09:09:55 2012
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 22 Feb 2012 08:09:55 +0000
Subject: [issue14073] allow per-thread atexit()
In-Reply-To: <1329833528.5.0.177059033602.issue14073@psf.upfronthosting.co.za>
Message-ID: <1329898195.89.0.386458141866.issue14073@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

@grahamd : sometimes you don't own the code that contains the thread, so I think it's better to be able to shutdown properly all flavors of threads.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14073>
_______________________________________

From report at bugs.python.org  Wed Feb 22 09:16:59 2012
From: report at bugs.python.org (Graham Dumpleton)
Date: Wed, 22 Feb 2012 08:16:59 +0000
Subject: [issue14073] allow per-thread atexit()
In-Reply-To: <1329833528.5.0.177059033602.issue14073@psf.upfronthosting.co.za>
Message-ID: <1329898619.55.0.308636036965.issue14073@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

Reality is that the way Python behaviour is defined/implemented means that it will wait for non daemonised threads to complete before exiting.

Sounds like the original code is wrong in not setting it to be daemonised in the first place and should be reported as a bug in that code rather than fiddling with the interpreter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14073>
_______________________________________

From report at bugs.python.org  Wed Feb 22 09:24:08 2012
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 22 Feb 2012 08:24:08 +0000
Subject: [issue14073] allow per-thread atexit()
In-Reply-To: <1329833528.5.0.177059033602.issue14073@psf.upfronthosting.co.za>
Message-ID: <1329899048.1.0.526933329779.issue14073@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Is there any good reason not to add this feature ? what would be the problem ?  It does seem to be for the best, I don't see any drawbacks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14073>
_______________________________________

From report at bugs.python.org  Wed Feb 22 09:28:19 2012
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 22 Feb 2012 08:28:19 +0000
Subject: [issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's
	doctype() method missing
In-Reply-To: <1329193190.72.0.667201124226.issue14007@psf.upfronthosting.co.za>
Message-ID: <1329899299.73.0.344774866289.issue14007@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It doesn't really matter if something was *meant* to be subclassed.  If it can be in 3.x, and can't be in 3.x+1, that's a sort of backwards compatibility bug we want to avoid pretty strongly because it's gratuitous breakage.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14007>
_______________________________________

From report at bugs.python.org  Wed Feb 22 09:37:48 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 22 Feb 2012 08:37:48 +0000
Subject: [issue14084] test_imp resource leak
Message-ID: <1329899868.11.0.386279986218.issue14084@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

I tried to reproduce the failure from #14080 using this:

./python -m test -uall -v -F test_imp


After around 500 iterations the test fails:


======================================================================
ERROR: test_find_module_encoding (test.test_imp.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stefan/pydev/cpython/Lib/test/test_imp.py", line 58, in test_find_module_encoding
    with imp.find_module('module_' + mod, self.test_path)[0] as fd:
OSError: [Errno 24] Too many open files

======================================================================
ERROR: test_issue1267 (test.test_imp.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stefan/pydev/cpython/Lib/test/test_imp.py", line 70, in test_issue1267
    self.test_path)
OSError: [Errno 24] Too many open files

======================================================================
ERROR: test_issue3594 (test.test_imp.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stefan/pydev/cpython/Lib/test/test_imp.py", line 92, in test_issue3594
    file, filename, info = imp.find_module(temp_mod_name)
OSError: [Errno 24] Too many open files

======================================================================
ERROR: test_issue9319 (test.test_imp.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stefan/pydev/cpython/Lib/test/test_imp.py", line 182, in test_issue9319
    imp.find_module, "badsyntax_pep3120", [path])
  File "/home/stefan/pydev/cpython/Lib/unittest/case.py", line 571, in assertRaises
    return context.handle('assertRaises', callableObj, args, kwargs)
  File "/home/stefan/pydev/cpython/Lib/unittest/case.py", line 135, in handle
    callable_obj(*args, **kwargs)
OSError: [Errno 24] Too many open files

----------
components: Interpreter Core
messages: 153935
nosy: brett.cannon, pitrou, skrah
priority: normal
severity: normal
status: open
title: test_imp resource leak
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14084>
_______________________________________

From report at bugs.python.org  Wed Feb 22 09:38:19 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 22 Feb 2012 08:38:19 +0000
Subject: [issue14084] test_imp resource leak
In-Reply-To: <1329899868.11.0.386279986218.issue14084@psf.upfronthosting.co.za>
Message-ID: <1329899899.26.0.559642882968.issue14084@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
type: behavior -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14084>
_______________________________________

From report at bugs.python.org  Wed Feb 22 09:51:32 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 22 Feb 2012 08:51:32 +0000
Subject: [issue14085] PyUnicode_WRITE: "comparison is always true" warnings
Message-ID: <1329900692.24.0.951186261982.issue14085@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

The FreeBSD-9.0 bot shows a couple of warnings because some comparisons
in PyUnicode_WRITE are always true:

Objects/unicodeobject.c:2598: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:2598: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:2598: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:2671: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:2671: warning: comparison is always true due to limited range of data type

[...]

----------
components: Interpreter Core
messages: 153936
nosy: haypo, skrah
priority: normal
severity: normal
status: open
title: PyUnicode_WRITE: "comparison is always true" warnings
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14085>
_______________________________________

From report at bugs.python.org  Wed Feb 22 10:04:13 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 22 Feb 2012 09:04:13 +0000
Subject: [issue5411] Add xz support to shutil
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1329901453.55.0.477493086331.issue5411@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> So, do you agree that ?not automated but not ugly? is better than ?automated with ugly klutches??

Definitely. If we have to add special cases that are almost as long as
the original code, the "automation" seems pointless.

> Note that there is a way to get fully automated support for tar formats: tarfile could expose, in addition to the list compression_formats, another structure with the descriptions (e.g. ?gzip?ed tar file?) and file extensions (e.g. ['.gz', '.tgz'] ?no, it?s not '.tar.gz', which is unfortunate, and could cause Lars to reject that idea).  I?m just putting this here for reference, but my preference is still for the second idea I talk about in my precedent message.

As much as it would be nice to have all of the information centralized in
one place, I don't think this is practical - some of the data that would
be stored in this structure really is specific to shutil, so I agree that
your second option is better.

I think we can restructure the code a bit to reduce the work involved in
adding a new format, though. Maybe something like this:

    _ARCHIVE_FORMATS = {}
    _UNPACK_FORMATS = {}

    for name, tarname, progname, extensions, desc in [
            ("xz", "xztar", "xz", [".xz"], "xz'ed tar file"),
            ("bz2", "bztar", "bzip2", [".bz2"], "bzip2'ed tar file"),
            ("gz", "gztar", "gzip", [".gz", ".tgz"], "gzip'ed tar file")]:
        if name in tarfile.compression_formats:
            _ARCHIVE_FORMATS[tarname] = _make_tarball, [("compress", progname)], desc
            _UNPACK_FORMATS[tarname] = extensions, _unpack_tarfile, [], desc

By the way, is there any reason why you've used ".gz" instead of
".tar.gz" as the extension for "gztar" in your proposed change? The
current version of shutil.py uses ".tar.gz", but has ".bz2" for "bztar".


Also, I notice that _make_tarball() will need to be updated to add the
info for xz to the tar_compression and compress_ext dictionaries. It
seems a bit ugly to duplicate this information when it's already present
in the format dicts, so maybe it would be better to pass the file
extension in directly instead? I assume that _make_tarball() is not part
of shutil's public API.

If we did this, there would be no need for a separate "progname" field
in the initialization code I suggested above:

    for name, tarname, extensions, desc in [
            ("xz", "xztar", [".xz"], "xz'ed tar file"),
            ("bz2", "bztar", [".bz2"], "bzip2'ed tar file"),
            ("gz", "gztar", [".gz", ".tgz"], "gzip'ed tar file")]:
        if name in tarfile.compression_formats:
            _ARCHIVE_FORMATS[tarname] = _make_tarball, [("compress", name)], desc
            _UNPACK_FORMATS[tarname] = extensions, _unpack_tarfile, [], desc

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5411>
_______________________________________

From report at bugs.python.org  Wed Feb 22 10:10:13 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 22 Feb 2012 09:10:13 +0000
Subject: [issue5411] Add xz support to shutil
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1329901813.9.0.214749620172.issue5411@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

For the "xztar" format, you should also perhaps recognize the ".txz"
extension - I've seen this used by FreeBSD.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5411>
_______________________________________

From report at bugs.python.org  Wed Feb 22 10:11:38 2012
From: report at bugs.python.org (Graham Dumpleton)
Date: Wed, 22 Feb 2012 09:11:38 +0000
Subject: [issue14073] allow per-thread atexit()
In-Reply-To: <1329833528.5.0.177059033602.issue14073@psf.upfronthosting.co.za>
Message-ID: <1329901898.88.0.11605235032.issue14073@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

At the moment you have showed some code which is causing you problems and a vague idea. Until you show how that idea may work in practice it is a bit hard to judge whether what it does and how it does it is reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14073>
_______________________________________

From report at bugs.python.org  Wed Feb 22 10:20:28 2012
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 22 Feb 2012 09:20:28 +0000
Subject: [issue14073] allow per-thread atexit()
In-Reply-To: <1329833528.5.0.177059033602.issue14073@psf.upfronthosting.co.za>
Message-ID: <1329902428.03.0.644805847911.issue14073@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Mmm.. you did not say yet why you are against this feature, other than "the lib *should not* use non-daemonized threads"

This sounds like "the lib should not use feature X in Python because it will block everything"

And now we're proposing to remove the limitation and you are telling me I am vague and unreasonable.

Let me try differently then.

Consider this script to be a library I don't control. I need to call the .stop() function when my main application shuts down. 

I can't use signals because you forbid it in mod_wsgi

How do I do, since asking the person to daemonize his thread is not an option ?

I see several options:
1 - monkey patch the lib
2 - remove regular threads from Python, or making them always daemonized
3 - add an atexit() option in threads in Python
4 - use signals and drop the usage of mod_wsgi

I think 3- is the cleanest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14073>
_______________________________________

From report at bugs.python.org  Wed Feb 22 10:25:56 2012
From: report at bugs.python.org (David)
Date: Wed, 22 Feb 2012 09:25:56 +0000
Subject: [issue14086] str(KeyError("Foo")) Unexpected Result
Message-ID: <1329902756.66.0.575500165148.issue14086@psf.upfronthosting.co.za>


New submission from David <vencabot_teppoo at hotmail.com>:

The __str__() method of the KeyError class seems to put quotes around the argument given to the class. This was causing bizarre, escaped quotation marks to appear in my code (where the result of str(e) is often passed as the argument of another Exception), and it took me a while to figure out where the problem lies, which says to me that the behavior is obscure and unexpected-enough to not be Python-like.

I appreciate that the quotation marks are put around the erroneous key:
>>> my_dict = {"foo": 1}
>>> my_dict["bar"]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'bar'

The quotation marks should be added to the argument as or before being passed -- not when the KeyError is converted to a str. Consider the following example, where a server is informing the client of invalid input:
>>> def validate_parameters(parameters_dict):
....    try:
....        validate(parameters_dict["foo"])
....        validate(parameters_dict["bar"])
....    except KeyError as e:
....        raise KeyError("Missing parameter {}.".format(e))
....
>>> def handle(parameters_dict):
....    # Validate the parameters before we do anything with them.
....    try:
....        validate_parameters(parameters_dict)
....    except Exception as e:
....        send_to_client("ERR: {}".format(e))
....

In this example, the client receives a string that looks like this:
\"Missing parameter 'foo'.\"
just because I wanted to re-raise a KeyError with a little bit of clarification. I've been doing this sort of re-raising a lot in this project and I don't see anything wrong with it, and I haven't had this kind of problem with any other Exception, which is why the bug took me a while to track down.

Consider these snippets from the Python Tutorial:
"For convenience, the exception instance defines __str__() so the arguments can be printed directly without having to reference .args."

"If an exception has arguments, they are printed as the last part (?detail?) of the message for unhandled exceptions."

Clearly, KeyError.__str__() is not printing my arguments directly. Also, the 'detail' of an unhandled KeyError exception, because of this behavior, is also != to its argument.

I believe that Python should preserve consistency by fixing this behavior. If the default KeyError arguments would look nicer with quotation marks, pass them with quotation marks, but maintain the sanctity and simplicity of Exception.__str__() as described in the tutorial. It makes more sense.

PS: My current project involves a lot of validation not because I don't usually believe that it's "easier to ask forgiveness," but because it's a scheduler for TV recordings, and, in that case, the client will want to know when there's a problem with their input BEFORE their recording of Survivor fails while they're at work and can't do anything about it.

----------
messages: 153941
nosy: vencabot_teppoo
priority: normal
severity: normal
status: open
title: str(KeyError("Foo")) Unexpected Result
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14086>
_______________________________________

From report at bugs.python.org  Wed Feb 22 10:31:34 2012
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Wed, 22 Feb 2012 09:31:34 +0000
Subject: [issue14056] Misc doc changes for tarfile
In-Reply-To: <1329694375.61.0.870450235951.issue14056@psf.upfronthosting.co.za>
Message-ID: <1329903094.03.0.521779122082.issue14056@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

a) Good point, a case of sloppy naming.

b) IMO a table is a tad too much. The amount of different compression methods is still quite small. My patch proposes a simpler approach.

c) A link to shutil is very useful.

BTW, thanks for the effort.

----------
Added file: http://bugs.python.org/file24598/lars-comment.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14056>
_______________________________________

From report at bugs.python.org  Wed Feb 22 10:35:00 2012
From: report at bugs.python.org (Graham Dumpleton)
Date: Wed, 22 Feb 2012 09:35:00 +0000
Subject: [issue14073] allow per-thread atexit()
In-Reply-To: <1329833528.5.0.177059033602.issue14073@psf.upfronthosting.co.za>
Message-ID: <1329903300.83.0.553554542217.issue14073@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

I haven't said I am against it. All I have done so far is explain on the WEB-SIG how mod_wsgi works and how Python currently works and how one would normally handle this situation by having the thread be daemonised.

As for the proposed solution, where is the code example showing how what you are suggesting is meant to work. Right now you are making people assume how that would work. Add an actual example here at least of how with the proposed feature your code would then look.

For the benefit of those who might even implement what you want, which will not be me anyway as I am not involved in Python core development, you might also explain where you expect these special per thread atexit callbacks to be triggered within the current steps for shutting down the interpreter. That way it will be more obvious to those who come later as to what you are actually proposing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14073>
_______________________________________

From report at bugs.python.org  Wed Feb 22 10:43:13 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Feb 2012 09:43:13 +0000
Subject: [issue14085] PyUnicode_WRITE: "comparison is always true" warnings
In-Reply-To: <1329900692.24.0.951186261982.issue14085@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwawjd3DdBoDm6hC8Rp8xc=hwaRMVQrHUpm6+OGxFqaq9Q@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Can you try to cast value to Py_UCS4 in assertions of
PyUnicode_WRITE() macro? For example, replace
   assert(value <= 0xff);
by
   assert((Py_UCS4)value <= 0xff);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14085>
_______________________________________

From report at bugs.python.org  Wed Feb 22 10:45:22 2012
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 22 Feb 2012 09:45:22 +0000
Subject: [issue14073] allow per-thread atexit()
In-Reply-To: <1329833528.5.0.177059033602.issue14073@psf.upfronthosting.co.za>
Message-ID: <1329903922.15.0.438710745063.issue14073@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> Add an actual example here at least of how with the proposed feature your code would then look.

That's the part I am not sure at all about in fact. I don't know at all the internals in the shutdown process in Python and I was hoping Antoine would give us a proposal here.

I would suspect simply adding to the base thread class an .atexit() method that's called when atexit() is called, would do the trick since we'd be able to do things like:

  def atexit(self):
      ... do whatever cleanup needed...
      self.join()

but I have no real experience in these internals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14073>
_______________________________________

From report at bugs.python.org  Wed Feb 22 10:53:47 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Feb 2012 09:53:47 +0000
Subject: [issue14053] Make patchcheck work with MQ
In-Reply-To: <1329661471.35.0.733956428931.issue14053@psf.upfronthosting.co.za>
Message-ID: <E1S08tO-0003wI-5Q@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 179bc7557484 by Nadeem Vawda in branch '2.7':
Issue #14053: Fix "make patchcheck" to work with MQ.
http://hg.python.org/cpython/rev/179bc7557484

New changeset fc5de19c66e2 by Nadeem Vawda in branch '3.2':
Issue #14053: Fix "make patchcheck" to work with MQ.
http://hg.python.org/cpython/rev/fc5de19c66e2

New changeset 1bdca2bcba6d by Nadeem Vawda in branch 'default':
Merge: #14053: Fix "make patchcheck" to work with MQ.
http://hg.python.org/cpython/rev/1bdca2bcba6d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14053>
_______________________________________

From report at bugs.python.org  Wed Feb 22 11:02:24 2012
From: report at bugs.python.org (Graham Dumpleton)
Date: Wed, 22 Feb 2012 10:02:24 +0000
Subject: [issue14073] allow per-thread atexit()
In-Reply-To: <1329833528.5.0.177059033602.issue14073@psf.upfronthosting.co.za>
Message-ID: <1329904944.72.0.147377036794.issue14073@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

Except that calling it at the time of current atexit callbacks wouldn't change the current behaviour. As quoted in WEB-SIG emails the sequence is:

    wait_for_thread_shutdown();

    /* The interpreter is still entirely intact at this point, and the
     * exit funcs may be relying on that.  In particular, if some thread
     * or exit func is still waiting to do an import, the import machinery
     * expects Py_IsInitialized() to return true.  So don't say the
     * interpreter is uninitialized until after the exit funcs have run.
     * Note that Threading.py uses an exit func to do a join on all the
     * threads created thru it, so this also protects pending imports in
     * the threads created via Threading.
     */
    call_py_exitfuncs();

So would need to be done prior to wait_for_thread_shutdown() or by that function before waiting on thread.

The code in that function has:

    PyObject *threading = PyMapping_GetItemString(tstate->interp->modules,
                                                  "threading");

    ...
    result = PyObject_CallMethod(threading, "_shutdown", "");

So calls _shutdown() on the threading module.

That function is aliased to _exitfunc() method of _MainThread.

    def _exitfunc(self):
        self._stop()
        t = _pickSomeNonDaemonThread()
        if t:
            if __debug__:
                self._note("%s: waiting for other threads", self)
        while t:
            t.join()
            t = _pickSomeNonDaemonThread()
        if __debug__:
            self._note("%s: exiting", self)
        self._delete()

So can be done in here.

The decision which would need to be made is whether you call atexit() on all threads before then trying to join() on any, or call atexit() only prior to the join() of the thread.

Calling atexit() on all possibly sounds the better option but I am not sure, plus the code would need to deal with doing two passes like that which may not may not have implications.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14073>
_______________________________________

From report at bugs.python.org  Wed Feb 22 11:03:28 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 22 Feb 2012 10:03:28 +0000
Subject: [issue14053] Make patchcheck work with MQ
In-Reply-To: <1329661471.35.0.733956428931.issue14053@psf.upfronthosting.co.za>
Message-ID: <1329905008.18.0.155797923747.issue14053@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Committed. Thanks for the patch!

> I haven't added NEWS as I thing is easier for the person that applies the patch to simply write the line directly there instead of merging. Is that ok?

Yes, that's fine; usually the NEWS entry is more or less the same as the
commit message, so it makes sense to leave it to the committer. It also
makes backporting easier - a diff against 3.3's NEWS file often won't
apply cleanly to 3.2 or 2.7.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14053>
_______________________________________

From report at bugs.python.org  Wed Feb 22 11:46:45 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 22 Feb 2012 10:46:45 +0000
Subject: [issue14079] Problems with recent test_subprocess changes
In-Reply-To: <1329865011.81.0.762834414848.issue14079@psf.upfronthosting.co.za>
Message-ID: <1329907605.02.0.479005676047.issue14079@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Was it one of the buildbots that was failing?

No, I was doing some testing with the pythonv branch and ran into this on a Mac running OS X 10.5.8 (Leopard).

I'll re-test and close the issue if all is well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14079>
_______________________________________

From report at bugs.python.org  Wed Feb 22 13:32:52 2012
From: report at bugs.python.org (Julian Berman)
Date: Wed, 22 Feb 2012 12:32:52 +0000
Subject: [issue14086] str(KeyError("Foo")) Unexpected Result
In-Reply-To: <1329902756.66.0.575500165148.issue14086@psf.upfronthosting.co.za>
Message-ID: <1329913972.56.0.776178731413.issue14086@psf.upfronthosting.co.za>


Julian Berman <Julian+Python.org at GrayVines.com> added the comment:

Hey there. Check out #2651

----------
nosy: +Julian

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14086>
_______________________________________

From report at bugs.python.org  Wed Feb 22 13:36:18 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 22 Feb 2012 12:36:18 +0000
Subject: [issue14085] PyUnicode_WRITE: "comparison is always true" warnings
In-Reply-To: <1329900692.24.0.951186261982.issue14085@psf.upfronthosting.co.za>
Message-ID: <1329914178.17.0.95476791376.issue14085@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Your suggestion eliminates many warnings, but not all. FreeBSD
is still stuck with gcc-4.2, so perhaps this is a good compromise.
Getting rid of the remaining warnings might require a more bloated
solution.


These are the remaining warnings:


Objects/unicodeobject.c: In function 'PyUnicode_DecodeUTF16Stateful':
Objects/unicodeobject.c:5474: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:5474: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:5475: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:5475: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:5477: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:5477: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:5478: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:5478: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c: In function 'PyUnicode_DecodeASCII':
Objects/unicodeobject.c:6878: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:6878: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:6878: warning: comparison is always true due to limited range of data type

----------
keywords: +patch
Added file: http://bugs.python.org/file24599/comparison-always-true.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14085>
_______________________________________

From report at bugs.python.org  Wed Feb 22 13:41:05 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 22 Feb 2012 12:41:05 +0000
Subject: [issue14034] Add argparse howto
In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za>
Message-ID: <1329914465.46.0.351586579567.issue14034@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> You might want to coordinate with Issue 13850 a bit - they want a quick reference table before
> the first example (which would therefore mean before this howto which is replacing the first example).

The howto discussed here would be a new file in Doc/howto, so no conflict.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14034>
_______________________________________

From report at bugs.python.org  Wed Feb 22 13:43:37 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 22 Feb 2012 12:43:37 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>
Message-ID: <1329914617.68.0.398597838982.issue13447@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Wed Feb 22 13:45:39 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 22 Feb 2012 12:45:39 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>
Message-ID: <1329914739.26.0.582514340992.issue13447@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Wed Feb 22 13:55:15 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 22 Feb 2012 12:55:15 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>
Message-ID: <1329915315.37.0.173475412033.issue13447@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I went for something even simpler: one new file Lib/test/test_tools.py.  There is no need to have a file there and more files in Tools/tests, everything can go in test_tools (I?m not worried about file size, we already have a few thousand-liners test modules).  I think it?s the simplest thing that works.

My only concern is communication: how do we tell people working on a tool that they should write a test in test_tools?  I?m not sure they would read Tools/README; maybe a note at the top of the Python files would work; a note in the devguide; sending an email to python-dev to tell about the new file + reminders when we see a new tool bug opened.

----------
keywords: +patch
Added file: http://bugs.python.org/file24600/add-test_tools.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Wed Feb 22 15:26:04 2012
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Wed, 22 Feb 2012 14:26:04 +0000
Subject: [issue14012] Misc tarfile fixes
In-Reply-To: <1329235837.42.0.144867770777.issue14012@psf.upfronthosting.co.za>
Message-ID: <1329920764.41.0.320886053465.issue14012@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I updated your patch:

- I removed the "import as" bit completely and changed all occurrences of _open() to builtins.open() which is more readable and explanatory.

- I object to changing the error messages in the 3.2 branch due to backwards compatibility, although I left them in the patch for now. (I changed the style of %-formatting with a single item tuple in order to match the coding style of the rest of the module.)

- I inlined the shutil.copyfileobj() method to remove the shutil import.

----------
Added file: http://bugs.python.org/file24601/tarfile-misc-bugs-3.2-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14012>
_______________________________________

From report at bugs.python.org  Wed Feb 22 15:31:57 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 22 Feb 2012 14:31:57 +0000
Subject: [issue14085] PyUnicode_WRITE: "comparison is always true" warnings
In-Reply-To: <1329900692.24.0.951186261982.issue14085@psf.upfronthosting.co.za>
Message-ID: <1329921117.09.0.152246728347.issue14085@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

It looks like in the FreeBSD (patched?) gcc version -Wtype-limits is part
of -Wall. I can reproduce the same warnings on Ubuntu with:

  ./configure --with-pydebug CFLAGS=-Wtype-limits


So I'm not so sure anymore if this is worth a patch at all. I could
also export CFLAGS=-Wno-type-limits on the bot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14085>
_______________________________________

From report at bugs.python.org  Wed Feb 22 16:01:25 2012
From: report at bugs.python.org (sbt)
Date: Wed, 22 Feb 2012 15:01:25 +0000
Subject: [issue14087] multiprocessing.Condition.wait_for missing
Message-ID: <1329922885.58.0.881756065062.issue14087@psf.upfronthosting.co.za>


New submission from sbt <shibturn at gmail.com>:

multiprocessing.Condition is missing a counterpart for the wait_for() method added to threading.Condition in Python 3.2.

I will work on a patch.

----------
components: Library (Lib)
messages: 153956
nosy: sbt
priority: normal
severity: normal
status: open
title: multiprocessing.Condition.wait_for missing
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14087>
_______________________________________

From report at bugs.python.org  Wed Feb 22 16:23:06 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 22 Feb 2012 15:23:06 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1329924186.32.0.9959628786.issue2377@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So refactoring the Python code into C code has been done, but it's crashing. =) As usual, manual memory management sucks.

I also think that their is still too much C code as it makes the whole thing somewhat brittle to any refactoring of importlib. I am seriously thinking of tossing the C code I have written and writing in C only the bare minimum needed to get to the sys.modules check, and otherwise punting to importlib for everything else in a single call or two. So that would mean performing the sanity check on the arguments, calculating the absolute name of the module, grabbing the import lock, checking sys.modules, failing that going to importlib, and then figuring out what to return regardless of where the module came from thanks to fromlist. So about four functions calls. Compare that to the 8 I'm making now along with the need to muck with other things and you can see why starting from scratch where I only care about the sys.modules fast path starts to look mighty attractive.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Wed Feb 22 16:28:21 2012
From: report at bugs.python.org (sbt)
Date: Wed, 22 Feb 2012 15:28:21 +0000
Subject: [issue14059] Implement multiprocessing.Barrier
In-Reply-To: <1329699138.74.0.937439869593.issue14059@psf.upfronthosting.co.za>
Message-ID: <1329924501.6.0.72507536452.issue14059@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> Wouldn't it be simpler with a mp.Condition?

Well, it is a fair bit shorter than the implementation in threading.py.  But that is not a fair comparison because it does implement reset().

I was trying to avoid using shared memory/ctypes since multiprocessing.synchronize does not currently use them.  However, I think it would be better (and much simpler) to just subclass threading.Barrier, making self._state and self._counter properties which delegate to RawValue objects.  That gets rid of the differences in behaviour.  I have this working, although I had to monkey patch multiprocessing.Condition to add a wait_for() method.  See Issue 14087.

> Otherwise, this should be added to Lib/multiprocesing.synchronize.py,
> and the tests to test_multiprocessing.

I will provide a patch later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14059>
_______________________________________

From report at bugs.python.org  Wed Feb 22 16:28:51 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 22 Feb 2012 15:28:51 +0000
Subject: [issue14077] sporadic test_multiprocessing failure
In-Reply-To: <1329864693.77.0.0470189552052.issue14077@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W7AbkYCmr2WOefji2YZL0Jv33RsvURsQz3eVoS4LRnDEA@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

2012/2/21 Charles-Fran?ois Natali <report at bugs.python.org>

But in other VMs id() is simply a number that gets assigned to objects that
is monotonically increasing. So it can be extremely deterministic if the
object creation order is consistent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14077>
_______________________________________

From report at bugs.python.org  Wed Feb 22 16:32:44 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 22 Feb 2012 15:32:44 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1329924764.17.0.212021309188.issue14080@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I think the test is bogus. It would do better to either use str.endswith() or splitting off the various parts of __file__ to verify the filename is correct as is the directory. Otherwise it shouldn't matter if the directory is relative or absolute.

----------
assignee:  -> brett.cannon
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Wed Feb 22 16:36:06 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Wed, 22 Feb 2012 15:36:06 +0000
Subject: [issue13041] argparse: terminal width is not detected properly
In-Reply-To: <1316902039.33.0.744560309521.issue13041@psf.upfronthosting.co.za>
Message-ID: <1329924966.29.0.12944430494.issue13041@psf.upfronthosting.co.za>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

OK, I guess that this could now be closed, since 13609 has been commited.
(It is currently reopened, but the proposed tweaks wouldn't influence
the usage in argparse, even if accepted).

I'm attaching a patch which updates the tests to the new $COLUMNS logic.
Previously, unsetting COLUMNS would fix the width on 80, now setting
COLUMNS=80 is the proper way to do this.

----------
Added file: http://bugs.python.org/file24602/issue13041.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13041>
_______________________________________

From report at bugs.python.org  Wed Feb 22 16:36:33 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Wed, 22 Feb 2012 15:36:33 +0000
Subject: [issue13041] argparse: terminal width is not detected properly
In-Reply-To: <1316902039.33.0.744560309521.issue13041@psf.upfronthosting.co.za>
Message-ID: <1329924993.72.0.0951237993928.issue13041@psf.upfronthosting.co.za>


Changes by Zbyszek Szmek <zbyszek at in.waw.pl>:


Removed file: http://bugs.python.org/file23238/patch1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13041>
_______________________________________

From report at bugs.python.org  Wed Feb 22 16:36:42 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Wed, 22 Feb 2012 15:36:42 +0000
Subject: [issue13041] argparse: terminal width is not detected properly
In-Reply-To: <1316902039.33.0.744560309521.issue13041@psf.upfronthosting.co.za>
Message-ID: <1329925002.69.0.0666965378084.issue13041@psf.upfronthosting.co.za>


Changes by Zbyszek Szmek <zbyszek at in.waw.pl>:


Removed file: http://bugs.python.org/file23241/patch1.1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13041>
_______________________________________

From report at bugs.python.org  Wed Feb 22 16:36:48 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Wed, 22 Feb 2012 15:36:48 +0000
Subject: [issue13041] argparse: terminal width is not detected properly
In-Reply-To: <1316902039.33.0.744560309521.issue13041@psf.upfronthosting.co.za>
Message-ID: <1329925008.92.0.869148174102.issue13041@psf.upfronthosting.co.za>


Changes by Zbyszek Szmek <zbyszek at in.waw.pl>:


Removed file: http://bugs.python.org/file24152/patch2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13041>
_______________________________________

From report at bugs.python.org  Wed Feb 22 16:42:26 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Wed, 22 Feb 2012 15:42:26 +0000
Subject: [issue12806] argparse: Hybrid help text formatter
In-Reply-To: <1313973978.37.0.422477813424.issue12806@psf.upfronthosting.co.za>
Message-ID: <1329925346.46.0.0799195345486.issue12806@psf.upfronthosting.co.za>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

> I suppose here is where I should volunteer to update the patch file...
@GraylinKim: do you still intend to work on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12806>
_______________________________________

From report at bugs.python.org  Wed Feb 22 16:47:46 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Feb 2012 15:47:46 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1329925666.82.0.441016829533.issue14080@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Otherwise it shouldn't matter if the directory is relative or absolute.

That's not really the issue here, both are relative.
I am still baffled at that failure, I don't see why "" would be chosen over "." (which is inserted at the beginning of sys.path by the test).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Wed Feb 22 17:01:17 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Wed, 22 Feb 2012 16:01:17 +0000
Subject: [issue13779] os.walk: bottom-up
In-Reply-To: <1326452589.73.0.0617213643117.issue13779@psf.upfronthosting.co.za>
Message-ID: <1329926477.96.0.0381681228891.issue13779@psf.upfronthosting.co.za>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

Maybe this could be closed? I'm attaching a small patch with a documentation clarification. (Adds "In either case the list of
subdirectories is retrieved before the tuples for the directory and
its subdirectories are generated.").

----------
keywords: +patch
Added file: http://bugs.python.org/file24603/issue13779.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13779>
_______________________________________

From report at bugs.python.org  Wed Feb 22 17:03:07 2012
From: report at bugs.python.org (Graylin Kim)
Date: Wed, 22 Feb 2012 16:03:07 +0000
Subject: [issue12806] argparse: Hybrid help text formatter
In-Reply-To: <1329925346.46.0.0799195345486.issue12806@psf.upfronthosting.co.za>
Message-ID: <CANzvMwUntzcqF2c_ixmSZXDS0Fb9MO8YAs0V=ZSWoCsyqUUEmg@mail.gmail.com>


Graylin Kim <graylin.kim at gmail.com> added the comment:

I'd be willing to at some point but I cannot see myself getting around to
it in the near future.

If someone else wants to offer an implementation that would be great.

On Wed, Feb 22, 2012 at 10:42 AM, Zbyszek Szmek <report at bugs.python.org>wrote:

>
> Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:
>
> > I suppose here is where I should volunteer to update the patch file...
> @GraylinKim: do you still intend to work on this?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12806>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12806>
_______________________________________

From report at bugs.python.org  Wed Feb 22 17:04:12 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Feb 2012 16:04:12 +0000
Subject: [issue14084] test_imp resource leak
In-Reply-To: <1329899868.11.0.386279986218.issue14084@psf.upfronthosting.co.za>
Message-ID: <1329926652.07.0.571031539833.issue14084@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Both test_issue9319 and test_find_module_encoding seem to leak file descriptors.

----------
priority: normal -> high
stage:  -> needs patch
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14084>
_______________________________________

From report at bugs.python.org  Wed Feb 22 17:20:38 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 22 Feb 2012 16:20:38 +0000
Subject: [issue14079] Problems with recent test_subprocess changes
In-Reply-To: <1329865011.81.0.762834414848.issue14079@psf.upfronthosting.co.za>
Message-ID: <1329927638.95.0.279495979257.issue14079@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14079>
_______________________________________

From report at bugs.python.org  Wed Feb 22 17:22:05 2012
From: report at bugs.python.org (Steven Bethard)
Date: Wed, 22 Feb 2012 16:22:05 +0000
Subject: [issue14034] Add argparse howto
In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za>
Message-ID: <1329927725.28.0.78096261446.issue14034@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Oh ok. Sounds good then!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14034>
_______________________________________

From report at bugs.python.org  Wed Feb 22 17:22:09 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 22 Feb 2012 16:22:09 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1329927729.38.0.212174550327.issue14080@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Well, if you execute test_imp w/ importlib (-m importlib.test.regrtest test_imp) it still passes. So there is something very odd going on that probably relies on some other test doing something weird. And this might be hard to diagnose until the error triggers again to show the error arguments that are in the file now (the traceback below doesn't match what is in the default branch ATM).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Wed Feb 22 17:27:36 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Wed, 22 Feb 2012 16:27:36 +0000
Subject: [issue4256] argparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1329928056.94.0.780567607506.issue4256@psf.upfronthosting.co.za>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

zsh completion is much more powerful. E.g. for git<SP>log<SP><TAB> I see:
completing head
<list-of-heads>
completing commit object name
completing cached file
abspath.c                   git-lost-found.sh           README                    
aclocal.m4                  git-merge-octopus.sh        reflog-walk.c             
...

git<SP><TAB>
completing alias
diffab                    -- alias for 'diff --src-prefix=a/ --dst-prefix=b/'
lol                       -- alias for 'log --graph --decorate --pretty=oneline --abbrev-commit'
lola                      -- alias for 'log --graph --decorate --pretty=oneline --abbrev-commit --all'
mergeu                    -- alias for 'merge --ff-only @{u}'
completing main porcelain command
add                       -- add file contents to index
am                        -- apply patches from a mailbox
...

The header parts ('completing commit object name', 'completing head',
'completing cached file') are in bold red. So different completions
types are supported, and some help is provided, and completions
are split in groups.

Completion for options knows which short/long options go together:
git log -<TAB> prints:
...
--oneline                                          -- shorthand for --pretty=oneline --abbrev-commit    
--ours                    -2                       -- diff against "our branch" version                 
--parents                                          -- display parents of commit                         
--patch                   -u           -p          -- generate diff in patch format                     
...

fish ("a friendly interactive shell" which I don't use but
which has some very cool features) prints something like
a\%b                                                                                         (Branch)
abspath.c                                                                      (C source code, 4.2kB)
abspath.o                                                                         (Object code, 13kB)
aclocal.m4                                                                          (M4 macro, 1.4kB)
adres                                                                                     (File, 23B)
advice.c                                                                       (C source code, 2.4kB)
advice.h                                                                             (C header, 555B)

I think that for --help-options to be usefull, it should list more information
than is needed just for bash completion. At least:
- options, with long and short options specified together
- short help for options (or maybe all of the help)
- option groups if such are used
- metavar names

This last part could be used by the completion script to customize completions
for a specific program. E.g. the completion script could know that FILE means a file,
and HOST means a host name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Wed Feb 22 17:36:57 2012
From: report at bugs.python.org (Antonio Ribeiro)
Date: Wed, 22 Feb 2012 16:36:57 +0000
Subject: [issue14088] sys.executable generating canonical path
Message-ID: <1329928617.24.0.609517948319.issue14088@psf.upfronthosting.co.za>


New submission from Antonio Ribeiro <alvesjunior.antonio at gmail.com>:

Hi all,

As it is my first time here, I'll try to explay step-by-step why I'm providing this path, and why I think that it is changing something that I believe that is not correct.

First of all, I was trying to run one individual test, as the dev guide says:

./python -m test -v test_sys

but, instead of run this test from the root directory of the project, I run it from ./Lib/test, so I did:

../../python -m test -v test_sys

and it returned an error. The reason is that my sys.executable was not an abspath. When I went to see why it is different, I get this value to sys.executable:

sys.executable -> '/home/antonio/Projects/cpython/Lib/test/../../python'

I'm not sure if I'm thinking write, but for me don't look nice to have this value as sys.executable, once the real path should be:

'/home/antonio/Projects/cpython/python'

So I'm providing a paatch that do exactly this.

Hope you enjoy

----------
components: None
files: canonical_path.diff
keywords: patch
messages: 153970
nosy: alvesjnr
priority: normal
severity: normal
status: open
title: sys.executable generating canonical path
type: behavior
Added file: http://bugs.python.org/file24604/canonical_path.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14088>
_______________________________________

From report at bugs.python.org  Wed Feb 22 17:40:29 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 22 Feb 2012 16:40:29 +0000
Subject: [issue14079] Problems with recent test_subprocess changes
In-Reply-To: <1329865011.81.0.762834414848.issue14079@psf.upfronthosting.co.za>
Message-ID: <1329928829.82.0.826442429111.issue14079@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Cool, thanks for reporting and debugging the issue :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14079>
_______________________________________

From report at bugs.python.org  Wed Feb 22 17:57:15 2012
From: report at bugs.python.org (Eric Snow)
Date: Wed, 22 Feb 2012 16:57:15 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>
Message-ID: <1329929835.56.0.748330887598.issue13447@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Wed Feb 22 18:12:04 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Feb 2012 17:12:04 +0000
Subject: [issue14084] test_imp resource leak
In-Reply-To: <1329899868.11.0.386279986218.issue14084@psf.upfronthosting.co.za>
Message-ID: <E1S0FjW-00022m-SX@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset cbfd2bf80db0 by Antoine Pitrou in branch '3.2':
Issue #14084: Fix a file descriptor leak when importing a module with a bad encoding.
http://hg.python.org/cpython/rev/cbfd2bf80db0

New changeset fcd0a67e708e by Antoine Pitrou in branch 'default':
Issue #14084: Fix a file descriptor leak when importing a module with a bad encoding.
http://hg.python.org/cpython/rev/fcd0a67e708e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14084>
_______________________________________

From report at bugs.python.org  Wed Feb 22 18:13:01 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Feb 2012 17:13:01 +0000
Subject: [issue14084] test_imp resource leak
In-Reply-To: <1329899868.11.0.386279986218.issue14084@psf.upfronthosting.co.za>
Message-ID: <1329930781.05.0.847685728533.issue14084@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Should be fixed now.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14084>
_______________________________________

From report at bugs.python.org  Wed Feb 22 18:16:28 2012
From: report at bugs.python.org (Anton Korobeynikov)
Date: Wed, 22 Feb 2012 17:16:28 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1329930988.64.0.997478951977.issue13241@psf.upfronthosting.co.za>


Changes by Anton Korobeynikov <anton at korobeynikov.info>:


----------
nosy: +Anton.Korobeynikov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Wed Feb 22 18:16:55 2012
From: report at bugs.python.org (Anton Korobeynikov)
Date: Wed, 22 Feb 2012 17:16:55 +0000
Subject: [issue13370] test_ctypes fails when building python with clang
In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za>
Message-ID: <1329931015.56.0.777138265978.issue13370@psf.upfronthosting.co.za>


Changes by Anton Korobeynikov <anton at korobeynikov.info>:


----------
nosy: +Anton.Korobeynikov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13370>
_______________________________________

From report at bugs.python.org  Wed Feb 22 18:19:51 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Wed, 22 Feb 2012 17:19:51 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1329931191.79.0.280937907509.issue13405@psf.upfronthosting.co.za>


Marc Abramowitz <msabramo at gmail.com> added the comment:

My understanding of DTrace is extremely shallow, but I think there is a major difference in how USDT probes are created between Solaris and OS X. Whereas on Solaris one generates object code using the -G option of dtrace and then links it in with the application, it seems that on OS X, the header file that dtrace -h spits out already has the magic assembler voodoo in it and thus you don't link with anything extra for DTrace. If that's true, then we probably need Makefile ifdef stuff to make it work.

If someone can verify my theories, I might be inclined to take a stab at it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Wed Feb 22 18:46:49 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 22 Feb 2012 17:46:49 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1329932809.36.0.417875487075.issue13703@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I have to amend my suggestion about sys.flags.hash_randomization.  It needs to be non-zero even if $PYTHONHASHSEED is given instead of -R.  Many other flags that also have envars work the same way, e.g. -O and $PYTHONOPTIMIZE.  So hash_randomization has to work the same way.

I'll still work on a patch for exposing the seed in sys.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Wed Feb 22 18:51:03 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 22 Feb 2012 17:51:03 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1329933063.13.0.679751422885.issue14080@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

OK, on FreeBSD the failure occurs reliably when test_sqlite and
test_imp are chained, perhaps because of the import failure
of sqlite3:

[stefan at freebsd-amd64 ~/hg/cpython]$ ./python -m test -uall test_sqlite test_imp
[1/2] test_sqlite
test_sqlite skipped -- No module named '_sqlite3'
[2/2] test_imp
test test_imp failed -- Traceback (most recent call last):
  File "/usr/home/stefan/hg/cpython/Lib/test/test_imp.py", line 330, in test_package___file__
    self.assertEqual(m.__file__, expected___file__, (m.__file__, m.__path__))
AssertionError: 'pep3147/__init__.py' != './pep3147/__init__.py'
- pep3147/__init__.py
+ ./pep3147/__init__.py
? ++
 : ('pep3147/__init__.py', ['pep3147'])

1 test failed:
    test_imp
1 test skipped:
    test_sqlite
Those skips are all expected on freebsd9.
[109902 refs]


On Linux I cannot reproduce it under the same conditions:

$ ./python -m test -uall test_sqlite test_imp
[1/2] test_sqlite
test_sqlite skipped -- No module named _sqlite3
[2/2] test_imp
1 test OK.
1 test skipped:
    test_sqlite
Those skips are all expected on linux2.
[94195 refs]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Wed Feb 22 18:58:08 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Feb 2012 17:58:08 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329933063.13.0.679751422885.issue14080@psf.upfronthosting.co.za>
Message-ID: <1329933280.3339.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> OK, on FreeBSD the failure occurs reliably when test_sqlite and
> test_imp are chained, perhaps because of the import failure
> of sqlite3:

Mmh, funny, I can't trigger it here. Is there anything special in your
sys.path?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Wed Feb 22 19:01:03 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Wed, 22 Feb 2012 18:01:03 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1329915315.37.0.173475412033.issue13447@psf.upfronthosting.co.za>
Message-ID: <4F452DB3.60301@email.de>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

> My only concern is communication: how do we tell people working on a tool that they should write a test in test_tools?  I?m not sure they would read Tools/README; maybe a note at the top of the Python files would work; a note in the devguide; sending an email to python-dev to tell about the new file + reminders when we see a new tool bug opened.

Patch patchcheck to "check" ;-) if some file in Tool/** has been touched 
and give a message accordingly (that happens already for NEWS and ACKS) ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Wed Feb 22 19:10:39 2012
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Wed, 22 Feb 2012 18:10:39 +0000
Subject: [issue14089] Patch to increase fractions lib test coverage
Message-ID: <1329934239.36.0.224119101932.issue14089@psf.upfronthosting.co.za>


New submission from Oleg Plakhotnyuk <olegus8 at gmail.com>:

The last few missing bits to complete test coverage of 'fractions.py' library.

./python.exe -E -Wd -m test -v -T -D ../coverage/test_fractions test_fractions

lines   cov%   module   (path)
  270   100%   fractions   (/Users/family/Documents/code/python/repo/Lib/fractions.py)

----------
components: Tests
files: test_fractions.patch
keywords: patch
messages: 153979
nosy: Oleg.Plakhotnyuk, mark.dickinson, rhettinger
priority: normal
severity: normal
status: open
title: Patch to increase fractions lib test coverage
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24605/test_fractions.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14089>
_______________________________________

From report at bugs.python.org  Wed Feb 22 19:12:12 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 22 Feb 2012 18:12:12 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1329934332.69.0.999627054185.issue13703@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Never mind about sys.hash_seed.  See my follow up in python-dev.  I consider this issue is closed wrt the 2.6 branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Wed Feb 22 19:20:33 2012
From: report at bugs.python.org (Michael Foord)
Date: Wed, 22 Feb 2012 18:20:33 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1329934833.59.0.890188106179.issue13241@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Note that apple have made gcc available, as part of command line tools for XCode, freely (free developer registration required though) from:

https://developer.apple.com/downloads/

See: 

http://kennethreitz.com/xcode-gcc-and-homebrew.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Wed Feb 22 20:15:49 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 22 Feb 2012 19:15:49 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1329938149.25.0.26358132566.issue14080@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

No, this is sys.path after sys.path.insert(0, os.curdir):

['.', '', '/usr/local/lib/python33.zip', '/usr/home/stefan/hg/cpython/Lib', '/usr/home/stefan/hg/cpython/Lib/plat-freebsd9', '/usr/home/stefan/hg/cpython/build/lib.freebsd-9.0-RELEASE-amd64-3.3-pydebug']


It is also possible to trigger the failure by adding this to the top of 
test_imp.py:

try:
    importlib.import_module("_sqlite3")
except ImportError:
    pass


Then it's sufficient to run only test_imp (and not test_sqlite).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Wed Feb 22 20:33:32 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 22 Feb 2012 19:33:32 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1329939212.75.0.0834214437168.issue14080@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I can confirm the failure when an import fails prior to running test_imp (i.e. trying importing some non-existent module like Stefan did at the top of test_imp). Luckily importlib doesn't fail in this case. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Wed Feb 22 21:01:08 2012
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Wed, 22 Feb 2012 20:01:08 +0000
Subject: [issue14073] allow per-thread atexit()
In-Reply-To: <1329833528.5.0.177059033602.issue14073@psf.upfronthosting.co.za>
Message-ID: <1329940868.0.0.0976276005473.issue14073@psf.upfronthosting.co.za>


Changes by Zvezdan Petkovic <zvezdan at computer.org>:


----------
nosy: +zvezdan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14073>
_______________________________________

From report at bugs.python.org  Wed Feb 22 21:03:47 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Feb 2012 20:03:47 +0000
Subject: [issue14077] sporadic test_multiprocessing failure
In-Reply-To: <1329856335.15.0.565948372805.issue14077@psf.upfronthosting.co.za>
Message-ID: <E1S0IPh-0004Bn-S4@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 27d31f0c4ad5 by Charles-Fran?ois Natali in branch 'default':
Issue #14077: importlib: Fix regression introduced by de6703671386.
http://hg.python.org/cpython/rev/27d31f0c4ad5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14077>
_______________________________________

From report at bugs.python.org  Wed Feb 22 21:08:57 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 22 Feb 2012 20:08:57 +0000
Subject: [issue12702] shutil.copytree() should use os.lutimes() to copy the
	metadata of symlinks
In-Reply-To: <1312612968.3.0.232528111658.issue12702@psf.upfronthosting.co.za>
Message-ID: <1329941337.02.0.193564167332.issue12702@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Yeah. Seems that fixing #12715 automatically also fixed this, so closing as duplicate.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Add symlink support to shutil functions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12702>
_______________________________________

From report at bugs.python.org  Wed Feb 22 21:16:10 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 22 Feb 2012 20:16:10 +0000
Subject: [issue14077] sporadic test_multiprocessing failure
In-Reply-To: <1329856335.15.0.565948372805.issue14077@psf.upfronthosting.co.za>
Message-ID: <1329941770.32.0.315777782967.issue14077@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I've committed the fix.
As for improving the randomness of the temporary file name, I'm not against it (I'm just not convinced it's necessary).

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14077>
_______________________________________

From report at bugs.python.org  Wed Feb 22 21:59:37 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Feb 2012 20:59:37 +0000
Subject: [issue14090] Bus error on test_big_buffer() of test_zlib,
	buildbot AMD64 debian bigmem 3.x
Message-ID: <1329944377.36.0.413864839881.issue14090@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

[241/364/1] test_zlib
Fatal Python error: Bus error

Current thread 0x00002b8f2240d260:
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/test_zlib.py", line 96 in test_big_buffer
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/case.py", line 385 in _executeTestPart
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/case.py", line 440 in run
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/case.py", line 492 in __call__
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/suite.py", line 105 in run
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/suite.py", line 67 in __call__
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/suite.py", line 105 in run
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/suite.py", line 67 in __call__
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/runner.py", line 168 in run
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/support.py", line 1369 in _run_suite
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/support.py", line 1403 in run_unittest
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/test_zlib.py", line 666 in test_main
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/regrtest.py", line 1221 in runtest_inner
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/regrtest.py", line 907 in runtest
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/regrtest.py", line 710 in main
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/__main__.py", line 13 in <module>
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/runpy.py", line 73 in _run_code
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/runpy.py", line 160 in _run_module_as_main
make: *** [buildbottest] Bus error

http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/136/steps/test/logs/stdio

----------
messages: 153987
nosy: haypo, loewis, pitrou
priority: normal
severity: normal
status: open
title: Bus error on test_big_buffer() of test_zlib, buildbot AMD64 debian bigmem 3.x
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14090>
_______________________________________

From report at bugs.python.org  Wed Feb 22 22:27:40 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 22 Feb 2012 21:27:40 +0000
Subject: [issue14090] Bus error on test_big_buffer() of test_zlib,
	buildbot AMD64 debian bigmem 3.x
In-Reply-To: <1329944377.36.0.413864839881.issue14090@psf.upfronthosting.co.za>
Message-ID: <1329946060.15.0.540203378495.issue14090@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

This was already reported as issue 13873.

----------
nosy: +nadeem.vawda
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> SIGBUS in test_zlib on Debian bigmem buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14090>
_______________________________________

From report at bugs.python.org  Wed Feb 22 22:28:13 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 22 Feb 2012 21:28:13 +0000
Subject: [issue13873] SIGBUS in test_zlib on Debian bigmem buildbot
In-Reply-To: <1327583804.29.0.71599909936.issue13873@psf.upfronthosting.co.za>
Message-ID: <1329946093.37.0.12760697353.issue13873@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +haypo, loewis, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13873>
_______________________________________

From report at bugs.python.org  Wed Feb 22 22:29:03 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Feb 2012 21:29:03 +0000
Subject: [issue13873] SIGBUS in test_zlib on Debian bigmem buildbot
In-Reply-To: <1327583804.29.0.71599909936.issue13873@psf.upfronthosting.co.za>
Message-ID: <1329946143.27.0.751559805901.issue13873@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

The same test found a bug in Mac OS X kernel: issue #11277.

I'm unable to reproduce the crash on Fedora 16 (with 12 GB of RAM). It may depend on zlib version or the kernel version. I'm running Linux 3.2.6-3.fc16.x86_64 with zlib 1.2.5-6.fc16.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13873>
_______________________________________

From report at bugs.python.org  Wed Feb 22 22:29:30 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Feb 2012 21:29:30 +0000
Subject: [issue13873] SIGBUS in test_zlib on Debian bigmem buildbot
In-Reply-To: <1327583804.29.0.71599909936.issue13873@psf.upfronthosting.co.za>
Message-ID: <1329946170.25.0.892006687949.issue13873@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

A recent crash:

[241/364/1] test_zlib
Fatal Python error: Bus error

Current thread 0x00002b8f2240d260:
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/test_zlib.py", line 96 in test_big_buffer
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/case.py", line 385 in _executeTestPart
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/case.py", line 440 in run
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/case.py", line 492 in __call__
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/suite.py", line 105 in run
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/suite.py", line 67 in __call__
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/suite.py", line 105 in run
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/suite.py", line 67 in __call__
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/runner.py", line 168 in run
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/support.py", line 1369 in _run_suite
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/support.py", line 1403 in run_unittest
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/test_zlib.py", line 666 in test_main
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/regrtest.py", line 1221 in runtest_inner
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/regrtest.py", line 907 in runtest
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/regrtest.py", line 710 in main
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/__main__.py", line 13 in <module>
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/runpy.py", line 73 in _run_code
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/runpy.py", line 160 in _run_module_as_main
make: *** [buildbottest] Bus error

http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/136/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13873>
_______________________________________

From report at bugs.python.org  Wed Feb 22 22:29:47 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Feb 2012 21:29:47 +0000
Subject: [issue13873] SIGBUS in test_big_buffer() of test_zlib on Debian
	bigmem buildbot
In-Reply-To: <1327583804.29.0.71599909936.issue13873@psf.upfronthosting.co.za>
Message-ID: <1329946187.92.0.894805232585.issue13873@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: SIGBUS in test_zlib on Debian bigmem buildbot -> SIGBUS in test_big_buffer() of test_zlib on Debian bigmem buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13873>
_______________________________________

From report at bugs.python.org  Wed Feb 22 22:30:24 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Feb 2012 21:30:24 +0000
Subject: [issue14090] Bus error on test_big_buffer() of test_zlib,
	buildbot AMD64 debian bigmem 3.x
In-Reply-To: <1329944377.36.0.413864839881.issue14090@psf.upfronthosting.co.za>
Message-ID: <1329946224.04.0.3393412535.issue14090@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> This was already reported as issue 13873.

I searched the issue but I failed to find it because you forgot to mention the test name (test_big_buffer) :-p

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14090>
_______________________________________

From report at bugs.python.org  Wed Feb 22 22:36:52 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Feb 2012 21:36:52 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329939212.75.0.0834214437168.issue14080@psf.upfronthosting.co.za>
Message-ID: <1329946402.3339.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I can confirm the failure when an import fails prior to running
> test_imp (i.e. trying importing some non-existent module like Stefan
> did at the top of test_imp). Luckily importlib doesn't fail in this
> case. =)

I can't reproduce :( Can either of you two try to debut it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Wed Feb 22 22:48:00 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Feb 2012 21:48:00 +0000
Subject: [issue14089] Patch to increase fractions lib test coverage
In-Reply-To: <1329934239.36.0.224119101932.issue14089@psf.upfronthosting.co.za>
Message-ID: <1329947280.71.0.516933009518.issue14089@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ezio.melotti
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14089>
_______________________________________

From report at bugs.python.org  Wed Feb 22 22:49:30 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Feb 2012 21:49:30 +0000
Subject: [issue14088] sys.executable generating canonical path
In-Reply-To: <1329928617.24.0.609517948319.issue14088@psf.upfronthosting.co.za>
Message-ID: <1329947370.48.0.924364152672.issue14088@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is unfortunately wrong since it will fail in the face of symlinks.
(if "foo" is a symlink to another directory, then "foo/../bar" is not the same thing as "bar")

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14088>
_______________________________________

From report at bugs.python.org  Wed Feb 22 23:00:04 2012
From: report at bugs.python.org (Massimo Paladin)
Date: Wed, 22 Feb 2012 22:00:04 +0000
Subject: [issue14091] python subprocess hangs if script called from another
	directory
Message-ID: <1329948004.01.0.833709233922.issue14091@psf.upfronthosting.co.za>


New submission from Massimo Paladin <massimo.paladin at gmail.com>:

Here is the behavior I am getting only on Python 2.7.2 in a Fedora 16:
$ cat /tmp/example.py
from subprocess import Popen,PIPE
args = "whatever program".split()
p = Popen(args)

If I run the program with:
$ cd /tmp/; python example.py

I get following as expected
Traceback (most recent call last):
  File "example.py", line 7, in <module>
    p = Popen(args)
  File "/usr/lib64/python2.7/subprocess.py", line 679, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.7/subprocess.py", line 1228, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

Instead if I run the program with:
$ cd ~; python /tmp/example.py

It hangs until I stop it with ctrl-c

On the same machine python 3.2.1 works fine.
On a mac with python 2.7.1 works fine.
On a rhel5 with python 2.4 works fine too.

----------
components: None
messages: 153994
nosy: Massimo.Paladin
priority: normal
severity: normal
status: open
title: python subprocess hangs if script called from another directory
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14091>
_______________________________________

From report at bugs.python.org  Wed Feb 22 23:03:21 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Feb 2012 22:03:21 +0000
Subject: [issue14091] python subprocess hangs if script called from another
	directory
In-Reply-To: <1329948004.01.0.833709233922.issue14091@psf.upfronthosting.co.za>
Message-ID: <1329948201.57.0.368574972652.issue14091@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I'm unable to reproduce the problem on Fedora 16 with Python 2.7.2.

> It hangs until I stop it with ctrl-c

Do you get an exception after hiting CTRL+c?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14091>
_______________________________________

From report at bugs.python.org  Wed Feb 22 23:05:28 2012
From: report at bugs.python.org (Massimo Paladin)
Date: Wed, 22 Feb 2012 22:05:28 +0000
Subject: [issue14091] python subprocess hangs if script called from another
	directory
In-Reply-To: <1329948004.01.0.833709233922.issue14091@psf.upfronthosting.co.za>
Message-ID: <1329948328.97.0.471026669743.issue14091@psf.upfronthosting.co.za>


Massimo Paladin <massimo.paladin at gmail.com> added the comment:

Yes, the expected one:

^CTraceback (most recent call last):
  File "/tmp/example.py", line 7, in <module>
    p = Popen(args)
  File "/usr/lib64/python2.7/subprocess.py", line 679, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.7/subprocess.py", line 1228, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14091>
_______________________________________

From report at bugs.python.org  Wed Feb 22 23:08:07 2012
From: report at bugs.python.org (Massimo Paladin)
Date: Wed, 22 Feb 2012 22:08:07 +0000
Subject: [issue14091] python subprocess hangs if script called from another
	directory
In-Reply-To: <1329948004.01.0.833709233922.issue14091@psf.upfronthosting.co.za>
Message-ID: <1329948487.62.0.526712478845.issue14091@psf.upfronthosting.co.za>


Massimo Paladin <massimo.paladin at gmail.com> added the comment:

The line which is mentioned in the exception for the file example.py is 7 because I have something commented out which I didn't past in the text before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14091>
_______________________________________

From report at bugs.python.org  Wed Feb 22 23:08:50 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Feb 2012 22:08:50 +0000
Subject: [issue14091] python subprocess hangs if script called from another
	directory
In-Reply-To: <1329948004.01.0.833709233922.issue14091@psf.upfronthosting.co.za>
Message-ID: <1329948530.78.0.717266799083.issue14091@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Could you try to collect more information with gdb?

cd ~; gdb -args python /tmp/example.py
(gdb) run
<python hangs>
CTRL+c
(gdb) where
<the expected output>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14091>
_______________________________________

From report at bugs.python.org  Wed Feb 22 23:10:41 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 22 Feb 2012 22:10:41 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1329948641.23.0.854518154594.issue2377@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Makes sense to me (your new proposal sounds pretty close to the sketch I posted on the mailing list).

It's really only the performance of in-function imports that concerned me and those are almost always going to get hits in sys.modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Wed Feb 22 23:11:09 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Wed, 22 Feb 2012 22:11:09 +0000
Subject: [issue14019] Unify tests for str.format and string.Formatter
In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za>
Message-ID: <1329948669.04.0.565570327579.issue14019@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

I have some questions about this:

1) In Lib/test/string_tests.py it says:
?Common tests shared by test_str, test_unicode, test_userstring and
test_string?

but

   a) I cannot find test_str

   b) string is imported and only some constants ascii_letters
   and digits are used

   c) In test_join there is a comment ?see the test in
   test.test_string.StringTest.test_join? Is that obsolete?
   (I cannot find StringTest in the test_string test)

2) Is there more tests for the build in format (in
test_buildin.BuiltinTest.test_format only the basic machinery is tested.
I would expect something like in test_format.py somewhere

3) it is true that all tests for the build in 'format' should also pass 
in 'string.Formatter().format'

Thanks in advance!

francis

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14019>
_______________________________________

From report at bugs.python.org  Wed Feb 22 23:12:07 2012
From: report at bugs.python.org (Massimo Paladin)
Date: Wed, 22 Feb 2012 22:12:07 +0000
Subject: [issue14091] python subprocess hangs if script called from another
	directory
In-Reply-To: <1329948004.01.0.833709233922.issue14091@psf.upfronthosting.co.za>
Message-ID: <1329948727.02.0.934089847793.issue14091@psf.upfronthosting.co.za>


Massimo Paladin <massimo.paladin at gmail.com> added the comment:

$ cd ~; gdb -args python /tmp/example.py
GNU gdb (GDB) Fedora (7.3.50.20110722-10.fc16)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/python...(no debugging symbols found)...done.
Missing separate debuginfos, use: debuginfo-install python-2.7.2-5.2.fc16.x86_64
(gdb) run
Starting program: /usr/bin/python /tmp/example.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Detaching after fork from child process 16202.
^C
Program received signal SIGINT, Interrupt.
0x00000039d3a0e8e0 in __connect_nocancel () from /lib64/libpthread.so.0
(gdb) where
#0  0x00000039d3a0e8e0 in __connect_nocancel () from /lib64/libpthread.so.0
#1  0x00007ffff095c678 in ?? () from /usr/lib64/python2.7/lib-dynload/_socketmodule.so
#2  0x00007ffff095d524 in ?? () from /usr/lib64/python2.7/lib-dynload/_socketmodule.so
#3  0x00000039d6ae00bd in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#4  0x00000039d6ae15a5 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0
#5  0x00000039d6a6dc2c in ?? () from /usr/lib64/libpython2.7.so.1.0
#6  0x00000039d6a49193 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#7  0x00007ffff0755597 in ?? () from /usr/lib64/python2.7/lib-dynload/_functoolsmodule.so
#8  0x00000039d6a49193 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#9  0x00000039d6ade795 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#10 0x00000039d6ae0580 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#11 0x00000039d6ae0580 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#12 0x00000039d6ae15a5 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0
#13 0x00000039d6a6dc2c in ?? () from /usr/lib64/libpython2.7.so.1.0
#14 0x00000039d6a49193 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#15 0x00000039d6ada457 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.7.so.1.0
#16 0x00000039d6afcdde in PyErr_PrintEx () from /usr/lib64/libpython2.7.so.1.0
#17 0x00000039d6afd38e in PyRun_SimpleFileExFlags () from /usr/lib64/libpython2.7.so.1.0
#18 0x00000039d6b0e745 in Py_Main () from /usr/lib64/libpython2.7.so.1.0
#19 0x00000039d362169d in __libc_start_main () from /lib64/libc.so.6
#20 0x0000000000400651 in _start ()
(gdb)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14091>
_______________________________________

From report at bugs.python.org  Wed Feb 22 23:18:50 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 22 Feb 2012 22:18:50 +0000
Subject: [issue14019] Unify tests for str.format and string.Formatter
In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za>
Message-ID: <1329949130.38.0.952059529933.issue14019@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

At least the first couple of those look like obsolete comments left over from the 2.x branch (we didn't do a mass renaming in the test suite, so many tests still live in their old locations).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14019>
_______________________________________

From report at bugs.python.org  Wed Feb 22 23:27:54 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 22 Feb 2012 22:27:54 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1329949674.49.0.58933234557.issue14080@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I'd rather get importlib working fast enough that you are okay with bootstrapping it so we can delete the offending code. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Wed Feb 22 23:39:03 2012
From: report at bugs.python.org (Ned Deily)
Date: Wed, 22 Feb 2012 22:39:03 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1329950343.48.0.749192594454.issue13241@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

>Note that apple have made gcc available, as part of command line tools >for XCode, freely (free developer registration required though) from:
> https://developer.apple.com/downloads
>See: 
>http://kennethreitz.com/xcode-gcc-and-homebrew.html

No. The new version of Xcode (Xcode 4.3, released last week) referred to in that post does *not* make gcc-4.2 available again.  Like Xcode 4.2, it only includes clang and llvm-gcc; 4.3 includes updated versions of each of the two. gcc-4.2 was removed starting with 4.2 and there is no indication that Apple intends to re-instate it. Besides the compiler updates, Xoode 4.3 has been significantly repackaged, including the ability to download and install its components in smaller sub-packages, instead of the monolithic large downloads of recent past releases.  However, Xcode 4.3 has moved the install location of components like the SDKs (which are used by Python universal builds) from /Developer to within the new Xcode application bundle (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer); this change will require additional changes to the Python build and Distutils/packaging infrastructure to support properly.  For now, the easiest workaround when installing Xcode 4.3 and removing previous versions is to create a symlink from the app bundle Developer directory above to /Developer.  I will be testing the new compiler versions shortly and working on more general support for 4.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Wed Feb 22 23:45:53 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Wed, 22 Feb 2012 22:45:53 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1329950753.54.0.825365721201.issue13405@psf.upfronthosting.co.za>


Marc Abramowitz <msabramo at gmail.com> added the comment:

I noticed that jcea already had some commented out stuff for OS X in his configure.in.

I tried it out and stuff builds and works in a basic way, although it might not be fully functional.

```
~/src/python-hg/cpython-2011$ hg diff configure.in
diff -r b50130b35288 configure.in
--- a/configure.in	Wed Feb 22 02:15:47 2012 +0100
+++ b/configure.in	Wed Feb 22 14:19:42 2012 -0800
@@ -2670,8 +2670,7 @@
         DFLAGS="-32"
     fi
 
-    #if dtrace -G -o /dev/null Include/pydtrace.d 2>/dev/null
-    if true
+    if dtrace -G -o /dev/null Include/pydtrace.d 2>/dev/null
     then
         DTRACE_NM=SOLARIS
         AC_DEFINE(WITH_DTRACE, 1,
```

```
~/src/python-hg/cpython-2011$ ./configure --prefix=/Users/marca/custom --enable-shared --with-dtrace
...
~/src/python-hg/cpython-2011$ make
...
~/src/python-hg/cpython-2011$ DYLD_LIBRARY_PATH=. python2.7
Python 2.7.2+ (dtrace-issue13405_2.7:b50130b35288+, Feb 22 2012, 14:11:17) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.getpid()
34764

# In another tab...
$ sudo dtrace -l | grep python34764
124748 python34764 libpython2.7.dylib            PyEval_EvalFrameExReal function-entry
124749 python34764 libpython2.7.dylib            PyEval_EvalFrameExReal function-return
124750 python34764 libpython2.7.dylib                           collect gc-done
124751 python34764 libpython2.7.dylib                           collect gc-start
124752 python34764 libpython2.7.dylib                   subtype_dealloc instance-delete-done
124753 python34764 libpython2.7.dylib                  instance_dealloc instance-delete-done
124754 python34764 libpython2.7.dylib                   subtype_dealloc instance-delete-start
124755 python34764 libpython2.7.dylib                  instance_dealloc instance-delete-start
124756 python34764 libpython2.7.dylib               PyType_GenericAlloc instance-new-done
124757 python34764 libpython2.7.dylib                    PyInstance_New instance-new-done
124758 python34764 libpython2.7.dylib               PyType_GenericAlloc instance-new-start
124759 python34764 libpython2.7.dylib                    PyInstance_New instance-new-start
124760 python34764 libpython2.7.dylib            PyEval_EvalFrameExReal line
```

So it builds and works at a basic level.

However, I did see some weirdness as well:

```
$ sudo dtrace -n 'python34764::: { printf("%s (%s:%d)", copyinstr(arg1), copyinstr(arg0), arg2) }' | grep test
dtrace: description 'python34764::: ' matched 13 probes
dtrace: error on enabled probe ID 4 (ID 124751: python34764:libpython2.7.dylib:collect:gc-start): invalid address (0x2) in action #2 at DIF offset 24
dtrace: error on enabled probe ID 3 (ID 124750: python34764:libpython2.7.dylib:collect:gc-done): invalid address (0xfffffffffffffffb) in action #1 at DIF offset 24
```

and

```
~/src/python-hg/cpython-2011$ sudo DYLD_LIBRARY_PATH=. dtrace -n 'python*::: { printf("%s (%s:%d)", copyinstr(arg1), copyinstr(arg0), arg2) }' -c 'python2.7 /Users/marca/python/test.py' > /dev/null
dtrace: description 'python*::: ' matched 29 probes
dtrace: pid 34907 has exited
dtrace: error on enabled probe ID 20 (ID 126731: python34907:libpython2.7.dylib:collect:gc-start): invalid address (0x2) in action #2 at DIF offset 24
dtrace: error on enabled probe ID 19 (ID 126730: python34907:libpython2.7.dylib:collect:gc-done): invalid address (0xfffffffffffffffb) in action #1 at DIF offset 24
```

On the other hand, some stuff appears to work sometimes:

```
~/src/python-hg/cpython-2011$ sudo DYLD_LIBRARY_PATH=. dtrace -n 'python*:::function-entry { printf("%s (%s:%d)", copyinstr(arg1), copyinstr(arg0), arg2) }' -c 'python2.7 /Users/marca/python/test.py'
dtrace: description 'python*:::function-entry ' matched 9 probes
Current working directory: /Users/marca/src/python-hg/cpython-2011
11
Current working directory: /Users/marca/src/python-hg/cpython-2011
11
Current working directory: /Users/marca/src/python-hg/cpython-2011
11
dtrace: pid 34953 has exited
CPU     ID                    FUNCTION:NAME
  2 125639 PyEval_EvalFrameExReal:function-entry <module> (/Users/marca/python/test.py:1)
  2 125639 PyEval_EvalFrameExReal:function-entry <module> (/Users/marca/python/marcsmath.py:1)
  2 125639 PyEval_EvalFrameExReal:function-entry test_func (/Users/marca/python/test.py:4)
  2 125639 PyEval_EvalFrameExReal:function-entry add (/Users/marca/python/marcsmath.py:1)
  2 125639 PyEval_EvalFrameExReal:function-entry test_func (/Users/marca/python/test.py:4)
  2 125639 PyEval_EvalFrameExReal:function-entry add (/Users/marca/python/marcsmath.py:1)
  2 125639 PyEval_EvalFrameExReal:function-entry test_func (/Users/marca/python/test.py:4)
  2 125639 PyEval_EvalFrameExReal:function-entry add (/Users/marca/python/marcsmath.py:1)
  2 125639 PyEval_EvalFrameExReal:function-entry _remove (/Users/marca/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/_weakrefset.py:38)
  2 125639 PyEval_EvalFrameExReal:function-entry _remove (/Users/marca/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/_weakrefset.py:38)
```

```
~/src/python-hg/cpython-2011$ sudo dtrace -n 'python*::: { printf("%s (%s:%d)", copyinstr(arg1), copyinstr(arg0), arg2) }' 2> /dev/null | grep 'function-entry.*pip'
### In another tab, do: "pip install --help" ###
  1 124748 PyEval_EvalFrameExReal:function-entry <module> (/Users/marca/.pythonbrew/pythons/Python-2.7.2/bin/pip:3)
  2 124748 PyEval_EvalFrameExReal:function-entry <module> (/Users/marca/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/site-packages/pip-1.0.2-py2.7.egg/pip/basecommand.py:1)
  2 124748 PyEval_EvalFrameExReal:function-entry <module> (/Users/marca/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/site-packages/pip-1.0.2-py2.7.egg/pip/commands/__init__.py:1)
  2 124748 PyEval_EvalFrameExReal:function-entry <module> (/Users/marca/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/site-packages/pip-1.0.2-py2.7.egg/pip/log.py:2)
  2 124748 PyEval_EvalFrameExReal:function-entry Logger (/Users/marca/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/site-packages/pip-1.0.2-py2.7.egg/pip/log.py:8)
  2 124748 PyEval_EvalFrameExReal:function-entry __init__ (/Users/marca/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/site-packages/pip-1.0.2-py2.7.egg/pip/log.py:25)
  2 124748 PyEval_EvalFrameExReal:function-entry <module> (/Users/marca/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/site-packages/pip-1.0.2-py2.7.egg/pip/baseparser.py:1)
  2 124748 PyEval_EvalFrameExReal:function-entry <module> (/Users/marca/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/site-packages/pip-1.0.2-py2.7.egg/pip/locations.py:1)
  2 124748 PyEval_EvalFrameExReal:function-entry running_under_virtualenv (/Users/marca/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/site-packages/pip-1.0.2-py2.7.egg/pip/locations.py:8)
  2 124748 PyEval_EvalFrameExReal:function-entry UpdatingDefaultsHelpFormatter (/Users/marca/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/site-packages/pip-1.0.2-py2.7.egg/pip/baseparser.py:12)
  2 124748 PyEval_EvalFrameExReal:function-entry ConfigOptionParser (/Users/marca/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/site-packages/pip-1.0.2-py2.7.egg/pip/baseparser.py:23)
  3 124748 PyEval_EvalFrameExReal:function-entry <module> (/Users/marca/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/site-packages/pip-1.0.2-py2.7.egg/pip/exceptions.py:1)
  3 124748 PyEval_EvalFrameExReal:function-entry InstallationError (/Users/marca/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/site-packages/pip-1.0.2-py2.7.egg/pip/exceptions.py:4)
  3 124748 PyEval_EvalFrameExReal:function-entry UninstallationError (/Users/marca/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/site-packages/pip-1.0.2-py2.7.egg/pip/exceptions.py:8)
  3 124748 PyEval_EvalFrameExReal:function-entry DistributionNotFound (/Users/marca/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/site-packages/pip-1.0.2-py2.7.egg/pip/exceptions.py:12)
  3 124748 PyEval_EvalFrameExReal:function-entry BadCommand (/Users/marca/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/site-packages/pip-1.0.2-py2.7.egg/pip/exceptions.py:16)
  3 124748 PyEval_EvalFrameExReal:function-entry <module> (/Users/marca/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/site-packages/pip-1.0.2-py2.7.egg/pip/util.py:1)
  3 124748 PyEval_EvalFrameExReal:function-entry _Inf (/Users/marca/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/site-packages/pip-1.0.2-py2.7.egg/pip/util.py:119)
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Wed Feb 22 23:57:20 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 22 Feb 2012 22:57:20 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1329951440.54.0.759208587795.issue14080@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Here's a minimal test case for now. It only fails if called as -m test:


$ ./python Lib/test/test_dot.py          # OK 


$ ./python Lib/test/regrtest.py test_dot # OK
[1/1] test_dot
Warning -- sys.path was modified by test_dot


$ ./python -m test test_dot
[1/1] test_dot
Warning -- sys.path was modified by test_dot
test test_dot crashed -- Traceback (most recent call last):
  File "/home/stefan/pydev/cpython/Lib/test/regrtest.py", line 1214, in runtest_inner
    the_package = __import__(abstest, globals(), locals(), [])
  File "/home/stefan/pydev/cpython/Lib/test/test_dot.py", line 20, in <module>
    assert m.__file__ == expected___file__
AssertionError

1 test failed:
    test_dot

----------
Added file: http://bugs.python.org/file24606/test_dot.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Thu Feb 23 00:09:03 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Feb 2012 23:09:03 +0000
Subject: [issue14091] python subprocess hangs if script called from another
	directory
In-Reply-To: <1329948727.02.0.934089847793.issue14091@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZKLhpUZAY3=M=72R_dgUc75_+C+H9LaL7W2dfkW_zACw@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> (gdb) where
> #0 ?0x00000039d3a0e8e0 in __connect_nocancel () from /lib64/libpthread.so.0
> #1 ?0x00007ffff095c678 in ?? () from /usr/lib64/python2.7/lib-dynload/_socketmodule.so
> #2 ?0x00007ffff095d524 in ?? () from /usr/lib64/python2.7/lib-dynload/_socketmodule.so

Hum, it's something related to network. Fedora uses its ABRT program
to catch program failures.

/usr/lib/python2.7/site-packages/abrt.pth contains "import
abrt_exception_handler" which install a custom sys.excepthook. This
hook writes a report and send it to the UNIX socket
/var/run/abrt/abrt.socket.

In your example, it looks like the abrt daemon is dead or at least
doesn't not answer, and so the abrt "client" hangs on the connection
to the UNIX socket. You may try to add a timeout to
s.connect("/var/run" + "/abrt/abrt.socket") in write_dump() of the
abrt_exception_handler module. You should also report the bug to
Fedora because it's unrelated to Python (core).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14091>
_______________________________________

From report at bugs.python.org  Thu Feb 23 00:09:37 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Feb 2012 23:09:37 +0000
Subject: [issue14091] python subprocess hangs if script called from another
	directory
In-Reply-To: <1329948004.01.0.833709233922.issue14091@psf.upfronthosting.co.za>
Message-ID: <1329952177.12.0.147520311144.issue14091@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14091>
_______________________________________

From report at bugs.python.org  Thu Feb 23 00:12:09 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Feb 2012 23:12:09 +0000
Subject: [issue14088] sys.executable generating canonical path
In-Reply-To: <1329928617.24.0.609517948319.issue14088@psf.upfronthosting.co.za>
Message-ID: <1329952329.32.0.267527517262.issue14088@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

We can use realpath() if the function is available. Something similar is already done for sys.argv[0]. We should also use GetFullPathNameW() on Windows.

----------
nosy: +haypo
Added file: http://bugs.python.org/file24607/sys_executable_realpath.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14088>
_______________________________________

From report at bugs.python.org  Thu Feb 23 00:13:13 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Feb 2012 23:13:13 +0000
Subject: [issue14088] sys.executable generating canonical path
In-Reply-To: <1329928617.24.0.609517948319.issue14088@psf.upfronthosting.co.za>
Message-ID: <1329952393.98.0.196363300312.issue14088@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

See also the issue #13402.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14088>
_______________________________________

From report at bugs.python.org  Thu Feb 23 00:17:32 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Feb 2012 23:17:32 +0000
Subject: [issue14088] sys.executable generating canonical path
In-Reply-To: <1329952329.32.0.267527517262.issue14088@psf.upfronthosting.co.za>
Message-ID: <1329952443.3339.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> We can use realpath() if the function is available. Something similar
> is already done for sys.argv[0]. We should also use GetFullPathNameW()
> on Windows.

GetFullPathName() is an abspath() equivalent. For realpath() you want
GetFinalPathNameByHandle(), aka. _nt.getfinalpathname().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14088>
_______________________________________

From report at bugs.python.org  Thu Feb 23 00:23:06 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 22 Feb 2012 23:23:06 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1329952986.91.0.190545175113.issue14080@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Antoine, what is your gcc version? The test case I posted fails
with Debian/gcc-4.3.2 and Ubuntu/gcc-4.4.3. The two affected
buildbots have gcc-4.2.x.

But the test case passes on Fedora/gcc-4.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Thu Feb 23 00:26:04 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Feb 2012 23:26:04 +0000
Subject: [issue14088] sys.executable generating canonical path
In-Reply-To: <1329928617.24.0.609517948319.issue14088@psf.upfronthosting.co.za>
Message-ID: <1329953164.41.0.526329847769.issue14088@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> GetFullPathName() is an abspath() equivalent. For realpath() you
> want GetFinalPathNameByHandle(), aka. _nt.getfinalpathname().

Ah? ntpath.realpath() uses nt._getfullpathname(). Is it a bug in ntpath?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14088>
_______________________________________

From report at bugs.python.org  Thu Feb 23 00:29:08 2012
From: report at bugs.python.org (Lex Berezhny)
Date: Wed, 22 Feb 2012 23:29:08 +0000
Subject: [issue14092] __name__ inconsistently applied in class definition
Message-ID: <1329953348.22.0.00582409575183.issue14092@psf.upfronthosting.co.za>


New submission from Lex Berezhny <eukreign at gmail.com>:

The following behavior doesn't make sense, especially since it works correctly for other special attributes:

>>> class F:
	__name__ = "Foo"

>>> F.__name__
'F'
>>> F().__name__
'Foo'
>>> F.__name__ = 'Foo'
>>> F.__name__
'Foo'


Works fine for __module__ and others:

>>> class F:
	__module__ = "mod"
	
>>> F.__module__
'mod'
>>> F
<class mod.F at 0x0212B360>

----------
components: Interpreter Core
messages: 154013
nosy: eukreign
priority: normal
severity: normal
status: open
title: __name__ inconsistently applied in class definition
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/issue14092>
_______________________________________

From report at bugs.python.org  Thu Feb 23 00:37:07 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 22 Feb 2012 23:37:07 +0000
Subject: [issue14093] Mercurial version information not appearing in Windows
	builds
Message-ID: <1329953826.97.0.233883201006.issue14093@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

Currently, the Mercurial revision information is not appearing in Windows builds - they always appear to be "default". This appears to be because the relevant information is not passed to getbuildinfo.c.

The attached patch rectifies this, making the assumption that "hg" will always be accessible on the path. The basic method is to call "hg id -bit" and then pass the branch, tag and revision information when compiling getbuildinfo.c.

If "hg" is not in the path, no Mercurial information is added (i.e. the current behaviour).

----------
components: Build, Windows
files: build-info-diff.diff
keywords: patch
messages: 154014
nosy: loewis, vinay.sajip
priority: normal
severity: normal
stage: patch review
status: open
title: Mercurial version information not appearing in Windows builds
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24608/build-info-diff.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14093>
_______________________________________

From report at bugs.python.org  Thu Feb 23 00:37:11 2012
From: report at bugs.python.org (Lex Berezhny)
Date: Wed, 22 Feb 2012 23:37:11 +0000
Subject: [issue14092] __name__ inconsistently applied in class definition
In-Reply-To: <1329953348.22.0.00582409575183.issue14092@psf.upfronthosting.co.za>
Message-ID: <1329953831.52.0.337427301932.issue14092@psf.upfronthosting.co.za>


Changes by Lex Berezhny <eukreign at gmail.com>:


----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14092>
_______________________________________

From report at bugs.python.org  Thu Feb 23 00:37:46 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Feb 2012 23:37:46 +0000
Subject: [issue14088] sys.executable generating canonical path
In-Reply-To: <1329953164.41.0.526329847769.issue14088@psf.upfronthosting.co.za>
Message-ID: <1329953657.3339.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Ah? ntpath.realpath() uses nt._getfullpathname(). Is it a bug in ntpath?

Probably:

# realpath is a no-op on systems without islink support
realpath = abspath

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14088>
_______________________________________

From report at bugs.python.org  Thu Feb 23 00:43:10 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 22 Feb 2012 23:43:10 +0000
Subject: [issue14093] Mercurial version information not appearing in Windows
	builds
In-Reply-To: <1329953826.97.0.233883201006.issue14093@psf.upfronthosting.co.za>
Message-ID: <1329954190.72.0.835663977192.issue14093@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Added Brian to nosy, as he said on IRC that he would look into my query about this.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14093>
_______________________________________

From report at bugs.python.org  Thu Feb 23 00:44:17 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Feb 2012 23:44:17 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329952986.91.0.190545175113.issue14080@psf.upfronthosting.co.za>
Message-ID: <1329954048.3339.8.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, what is your gcc version? The test case I posted fails
> with Debian/gcc-4.3.2 and Ubuntu/gcc-4.4.3. The two affected
> buildbots have gcc-4.2.x.

Mageia/gcc-4.5.2 here. It also passes with Debian/gcc-4.4.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Thu Feb 23 00:47:50 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Feb 2012 23:47:50 +0000
Subject: [issue14094] nt.realpath() should use GetFinalPathNameByHandle() when
	available
Message-ID: <1329954470.08.0.180096078595.issue14094@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

nt.realpath() should use GetFinalPathNameByHandleW() when available, instead of GetFullPathNameW(), to resolve symlinks.

By the way, it's strange that Py_GetFinalPathNameByHandleW() is called with VOLUME_NAME_NT to get the buffer size, and then with VOLUME_NAME_DOS. Is it a bug?

    /* We have a good handle to the target, use it to determine the
       target path name. */
    buf_size = Py_GetFinalPathNameByHandleW(hFile, 0, 0, VOLUME_NAME_NT);

    if(!buf_size)
        return win32_error_object("GetFinalPathNameByHandle", po);

    target_path = (wchar_t *)malloc((buf_size+1)*sizeof(wchar_t));
    if(!target_path)
        return PyErr_NoMemory();

    result_length = Py_GetFinalPathNameByHandleW(hFile, target_path,
                                                 buf_size, VOLUME_NAME_DOS);

See also issue #9333 (issue which added os.symlink() on Windows).

----------
components: Library (Lib)
messages: 154018
nosy: brian.curtin, haypo, pitrou
priority: normal
severity: normal
status: open
title: nt.realpath() should use GetFinalPathNameByHandle() when available
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14094>
_______________________________________

From report at bugs.python.org  Thu Feb 23 00:48:11 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Feb 2012 23:48:11 +0000
Subject: [issue14094] nt.realpath() should use GetFinalPathNameByHandle() when
	available
In-Reply-To: <1329954470.08.0.180096078595.issue14094@psf.upfronthosting.co.za>
Message-ID: <1329954491.85.0.628129128714.issue14094@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14094>
_______________________________________

From report at bugs.python.org  Thu Feb 23 00:48:38 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Feb 2012 23:48:38 +0000
Subject: [issue14088] sys.executable generating canonical path
In-Reply-To: <1329928617.24.0.609517948319.issue14088@psf.upfronthosting.co.za>
Message-ID: <1329954518.44.0.263715924271.issue14088@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

>> Is it a bug in ntpath?
> Probably

Ok, I opened the issue #14094.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14088>
_______________________________________

From report at bugs.python.org  Thu Feb 23 01:27:45 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Feb 2012 00:27:45 +0000
Subject: [issue14095] type_new() removes __qualname__ from the input dictionary
Message-ID: <1329956865.57.0.697177106628.issue14095@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

The C function type_new() creates a copy the dictionary for __dict__ and modifies the copy... except for __qualname__: it does modify the input dictionary before the copy.
---
def f(): pass

d = {'__qualname__': 42, '__new__': f}
assert d['__new__'] is f
assert '__qualname__' in d
Enum = type.__new__(type, 'Enum', (), d)
assert d['__new__'] is f
assert '__qualname__' in d
---

I don't know if it is expected. If not, the copy should be done before.

----------
messages: 154020
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: type_new() removes __qualname__ from the input dictionary
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14095>
_______________________________________

From report at bugs.python.org  Thu Feb 23 01:27:51 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Feb 2012 00:27:51 +0000
Subject: [issue14095] type_new() removes __qualname__ from the input dictionary
In-Reply-To: <1329956865.57.0.697177106628.issue14095@psf.upfronthosting.co.za>
Message-ID: <1329956871.42.0.517146632096.issue14095@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
components: +Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14095>
_______________________________________

From report at bugs.python.org  Thu Feb 23 01:28:18 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Feb 2012 00:28:18 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>
Message-ID: <1329956898.07.0.623455483043.issue13447@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Nice idea, but

1) not everyone uses patchcheck

2) patchcheck comes after you?ve fixed something, but tests should be written before fixes (to reproduce the error)

:)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Thu Feb 23 01:35:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Feb 2012 00:35:07 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1329957307.21.0.164717878451.issue2377@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I also think that [there] is still too much C code as it makes the whole thing somewhat brittle
> to any refactoring of importlib. I am seriously thinking of tossing the C code I have written and
> writing in C only the bare minimum needed to get to the sys.modules check, and otherwise punting
> to importlib for everything else in a single call or two.

A few thoughts from my outsider viewpoint:

1) I think the point of importlib is to have maintainable code (i.e. the anti-import.c <wink>), so writing only the minimum code in C makes sense.

2) Speed is a concern, especially with sysconfig in 3.3 slowing startup, but a secondary concern.

3) Maybe some parts can be written in C later, after profiling, and then override Python functions (? la ?from _heapq import *?, if that?s possible at all for importlib).

4) When is PyPy going to be the reference implementation again?  Then we?ll have no speed issues?ha ha only serious.

5) importlib rocks hard.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Thu Feb 23 01:43:13 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 23 Feb 2012 00:43:13 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>
Message-ID: <1329957793.92.0.268557684031.issue13447@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> I went for something even simpler: one new file Lib/test/test_tools.py.

I'm fine with this option too; if it grows too big we can always split it in several modules later.

> My only concern is communication: how do we tell people working on a
> tool that they should write a test in test_tools?

I don't think it's a big deal, eventually people will learn that it's there and we can always point to that file when a new issue is opened or during the patch review.
Adding a check to `make patchcheck` will also help (it's still better to add tests later than leaving the code untested), but maybe it should be displayed only if something is actually changed in the Tools dir (since that doesn't happen often, having always a "Tools modified... no" will just add noise to the output).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Thu Feb 23 01:45:48 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Feb 2012 00:45:48 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>
Message-ID: <1329957948.38.0.507807833684.issue13447@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Shall I commit the new file or first add more tests?

> I don't think it's a big deal, eventually people will learn that it's there and we can always
> point to that file when a new issue is opened or during the patch review.
Good.

> Adding a check to `make patchcheck` will also help [...]
I?ll let Francisco do that in another bug report :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Thu Feb 23 01:54:19 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Feb 2012 00:54:19 +0000
Subject: [issue14056] Misc doc changes for tarfile
In-Reply-To: <1329694375.61.0.870450235951.issue14056@psf.upfronthosting.co.za>
Message-ID: <1329958459.75.0.926514587875.issue14056@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I like your idea.  I?ll keep the table for shutil, which has more things to say (description, file extensions, etc.).

----------
Added file: http://bugs.python.org/file24609/misc-tarfile-doc-changes-3.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14056>
_______________________________________

From report at bugs.python.org  Thu Feb 23 02:08:25 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Feb 2012 01:08:25 +0000
Subject: [issue14012] Misc tarfile fixes
In-Reply-To: <1329235837.42.0.144867770777.issue14012@psf.upfronthosting.co.za>
Message-ID: <1329959305.19.0.925330325269.issue14012@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I removed the "import as" bit completely and changed all occurrences of _open() to
> builtins.open() which is more readable and explanatory.
Truly.  tokenize got a similar fix in ea260d393cde (without a test, so I think that here we don?t need one either); locale has a similar bug.

> I object to changing the error messages in the 3.2 branch due to backwards compatibility,
> although I left them in the patch for now.
I removed these changes in the attached patch.  I?ll make another patch for 3.3 for that.

> (I changed the style of %-formatting with a single item tuple in order to match the coding
> style of the rest of the module.)
My reason was not style (I hate %-formatting with single-element tuples) but defensive coding, in case someone gives a tuple as argument.  OTOH, that will just change the type of error they get for the same line, and the doc clearly says what is allowed, so it does not matter.

> I inlined the shutil.copyfileobj() method to remove the shutil import.
Great, this will eliminate a circular dependency I had in a shutil refactoring (I need to access tarfile.compression_formats, but the tarfile module is not ready when shutil gets imported), and also reduce the diff with the tarfile backport we have in distutils2.

Tell me if you want me to commit.

----------
Added file: http://bugs.python.org/file24610/tarfile-misc-bugs-3.2-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14012>
_______________________________________

From report at bugs.python.org  Thu Feb 23 02:09:43 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 23 Feb 2012 01:09:43 +0000
Subject: [issue14092] __name__ inconsistently applied in class definition
In-Reply-To: <1329953348.22.0.00582409575183.issue14092@psf.upfronthosting.co.za>
Message-ID: <1329959383.57.0.86492696398.issue14092@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I don't think this is actually incorrect. Basically setting something in the class body is not equivalent to setting it as an attribute on the class.

This happens with other attributes. Consider

>>> class X:
...     __class__ = list
... 
>>> X.__class__
<class 'type'>
>>> X().__class__
<class 'list'>

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14092>
_______________________________________

From report at bugs.python.org  Thu Feb 23 02:18:35 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Feb 2012 01:18:35 +0000
Subject: [issue14061] Clean up archiving code in shutil
In-Reply-To: <1329705067.15.0.02936958618.issue14061@psf.upfronthosting.co.za>
Message-ID: <1329959915.48.0.45869180806.issue14061@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Another bug: the bztar unpacker will be called for files ending in '.bz2', but it should really check for '.tar.bz2' (just like the gztar unpacker is called for '.tar.gz' or '.tgz').

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14061>
_______________________________________

From report at bugs.python.org  Thu Feb 23 02:22:06 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Feb 2012 01:22:06 +0000
Subject: [issue5411] Add xz support to shutil
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1329960126.06.0.327226213912.issue5411@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I think we can restructure the code a bit to reduce the work involved in adding a new format, though.
> Maybe something like this: [snip]
Thanks, I?ve applied your obvious refactor in my clone :)  For clarity, I will split my patch into many patches for different reports (bug fixes and doc improvements for 3.2, then code cleanup in 3.3, then adding xz).

> By the way, is there any reason why you've used ".gz" instead of ".tar.gz" as the extension for "gztar"
> in your proposed change? The current version of shutil.py uses ".tar.gz", but has ".bz2" for "bztar".
Yes, I confused the two formats.  I reported the '.bz2' bug (should be '.tar.bz2') and will fix it.

> Also, I notice that _make_tarball() will need to be updated to add the info for xz to the tar_compression
> and compress_ext dictionaries.
I ripped them off.  I could have pasted my full patch to save you time, sorry!

> For the "xztar" format, you should also perhaps recognize the ".txz" extension
Done.  Google finds a number of matches.  I won?t add '.tbz' though, as I don?t know if it?s bzip or bzip2, and as it does not seem used much.

----------
dependencies:  -tarfile should expose supported formats

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5411>
_______________________________________

From report at bugs.python.org  Thu Feb 23 02:27:02 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Feb 2012 01:27:02 +0000
Subject: [issue14006] Improve the documentation of xml.etree.ElementTree
In-Reply-To: <1329190125.69.0.69162565954.issue14006@psf.upfronthosting.co.za>
Message-ID: <1329960422.72.0.602754063182.issue14006@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The ElementTree.py module has good JavaDoc-style function-level documentation, but as it's not
> in docstring format, it can't be seen from the interactive help.
> 
> I'd be willing to convert the current comments into docstrings, as long as I wouldn't be
> stepping on anybody's toes,
Great, thanks!  I don?t know if the best approach here is to add lengthy docstrings or move the information from the comments into the reST docs.  Maybe this should be asked on the core-mentorship or python-dev mailing list.

> and somebody could give me some guidance as to how to convert the @return and @param declarations
In docstrings as well as in reST docs we just use English, with asterisks to mark up parameters, e.g. ?*path* is an instance of :class:`ElementPath`. ... Returns ``True`` if there is a match, ``False`` otherwise.?

> and how to handle the C version of the module.
Doctrings for C modules are not hard to find, just a little painful to write.  If we agree to turn comments into docstrings and you need help, I?ll be glad to guide you with that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14006>
_______________________________________

From report at bugs.python.org  Thu Feb 23 02:33:44 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Feb 2012 01:33:44 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
Message-ID: <1329960824.13.0.292987430999.issue1521950@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Previously when punctuation chars were set, wordchars was being augmented by '-'. This was
> incomplete, so the augmentation is now with '~-./*?=' which allows for wildcards, filename
> chars and argument flags.
I did not fully get what you meant here, but the example you added to the doc made it clear.  Is this covered by tests?

Overall great patch!  Dan, do you have time to test it (or read the new examples in the patch) to tell us if it meets what you wanted?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521950>
_______________________________________

From report at bugs.python.org  Thu Feb 23 02:38:20 2012
From: report at bugs.python.org (Lex Berezhny)
Date: Thu, 23 Feb 2012 01:38:20 +0000
Subject: [issue14092] __name__ inconsistently applied in class definition
In-Reply-To: <1329953348.22.0.00582409575183.issue14092@psf.upfronthosting.co.za>
Message-ID: <1329961100.63.0.637315151086.issue14092@psf.upfronthosting.co.za>


Lex Berezhny <eukreign at gmail.com> added the comment:

I think for __class__ it might make sense but for __name__ it seems not intuitive.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14092>
_______________________________________

From report at bugs.python.org  Thu Feb 23 02:40:55 2012
From: report at bugs.python.org (Gustavo Niemeyer)
Date: Thu, 23 Feb 2012 01:40:55 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
Message-ID: <1329961255.7.0.616843709838.issue1521950@psf.upfronthosting.co.za>


Changes by Gustavo Niemeyer <gustavo at niemeyer.net>:


----------
nosy:  -niemeyer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521950>
_______________________________________

From report at bugs.python.org  Thu Feb 23 02:43:23 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 23 Feb 2012 01:43:23 +0000
Subject: [issue14092] __name__ inconsistently applied in class definition
In-Reply-To: <1329953348.22.0.00582409575183.issue14092@psf.upfronthosting.co.za>
Message-ID: <1329961403.89.0.515030364553.issue14092@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Well, what do you expect the name of the class to be? The one you assign __name__ to or the one you pass to type()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14092>
_______________________________________

From report at bugs.python.org  Thu Feb 23 03:01:38 2012
From: report at bugs.python.org (Lex Berezhny)
Date: Thu, 23 Feb 2012 02:01:38 +0000
Subject: [issue14092] __name__ inconsistently applied in class definition
In-Reply-To: <1329953348.22.0.00582409575183.issue14092@psf.upfronthosting.co.za>
Message-ID: <1329962498.02.0.602368433263.issue14092@psf.upfronthosting.co.za>


Lex Berezhny <eukreign at gmail.com> added the comment:

The one in __name__ since logically that happens after the class declaration ('class X' line) and should overwrite the name in the class declaration.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14092>
_______________________________________

From report at bugs.python.org  Thu Feb 23 03:06:19 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 23 Feb 2012 02:06:19 +0000
Subject: [issue14092] __name__ inconsistently applied in class definition
In-Reply-To: <1329953348.22.0.00582409575183.issue14092@psf.upfronthosting.co.za>
Message-ID: <1329962779.02.0.763627713971.issue14092@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

It can be implemented but I'm skeptical that it's correct. You might try convincing Python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14092>
_______________________________________

From report at bugs.python.org  Thu Feb 23 03:38:49 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 23 Feb 2012 02:38:49 +0000
Subject: [issue13633] Handling of hex character references in
	HTMLParser.handle_charref
In-Reply-To: <1324277757.56.0.0733657691883.issue13633@psf.upfronthosting.co.za>
Message-ID: <1329964729.93.0.382093206807.issue13633@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This behavior is now documented, but the situation could still be improved.  Adding a new method that receives the converted entity seems a good way to handle this.  The parser can call both, and users can pick either one.

One problem with the current methods (handle_charref and handle_entityref) is that they don't do any processing on the entity and let invalid character references like &#x1000000000; or &#iamnotanentity; go through.

There are at least 3 changes that should be done in order to follow the HTML5 standard [0]:
 1) the parser should look at html.entities while parsing named character references (see also #11113).  This will allow the parser to parse &notit; as "?it;" and &notin; as "?" (see note at the very end of [0]);
 2) invalid character references (e.g. &#x1000000000;, &#iamnotanentity;) should not go through;
 3) the table at [0] with the replacement character should be used by the parser to "correct" those invalid character references (e.g. 0x80 -> U+20AC);

Now, 1) can be done for both the old and new method, but for 2) and 3) the situation is a bit more complicated.  The best thing is probably to keep sending them unchanged to the old methods, and implement the correct behavior for the new method only.

[0]: http://www.w3.org/TR/html5/tokenization.html#tokenizing-character-references

----------
dependencies: +html.entities mapping dicts need updating?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13633>
_______________________________________

From report at bugs.python.org  Thu Feb 23 03:41:32 2012
From: report at bugs.python.org (wang)
Date: Thu, 23 Feb 2012 02:41:32 +0000
Subject: [issue14096] Python 3.1 IDLE has a bug.Can fix it?
Message-ID: <1329964892.44.0.577555550319.issue14096@psf.upfronthosting.co.za>


New submission from wang <zevboy at gmail.com>:

paltform is windows.
generate this bug:
within IDLE edtor.
first select some text.
second press down the shift key.
third  press  the end key.
fourth press the home key.
last IDLE quit with no message and document with no save.

----------
components: IDLE
messages: 154037
nosy: guxianminer
priority: normal
severity: normal
status: open
title: Python 3.1 IDLE has a bug.Can fix it?
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14096>
_______________________________________

From report at bugs.python.org  Thu Feb 23 03:45:12 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Feb 2012 02:45:12 +0000
Subject: [issue14096] IDLE quits unexpectedly when some keys are pressed
In-Reply-To: <1329964892.44.0.577555550319.issue14096@psf.upfronthosting.co.za>
Message-ID: <1329965112.48.0.0653055049796.issue14096@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  Python 3.1 only gets fixes for security bugs now, could you try to reproduce your bug with Python 2.7, 3.2 or 3.3?

----------
nosy: +eric.araujo
title: Python 3.1 IDLE has a bug.Can fix it? -> IDLE quits unexpectedly when some keys are pressed
type: crash -> behavior
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14096>
_______________________________________

From report at bugs.python.org  Thu Feb 23 03:52:24 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 23 Feb 2012 02:52:24 +0000
Subject: [issue14096] IDLE quits unexpectedly when some keys are pressed
In-Reply-To: <1329964892.44.0.577555550319.issue14096@psf.upfronthosting.co.za>
Message-ID: <1329965544.28.0.306167425569.issue14096@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I tried to reproduce it on 3.1 and 3.2 but it worked fine here (WinXP).
This is what I did:
1) open IDLE;
2) file --> new window;
3) write some text;
4) select with the mouse some text;
5) press shift and keep it pressed;
6) press end;
7) press home;
8) release shift;

I also tried in the "Python Shell" and releasing shift before pressing end and home, but I got the same result.  Shift+end highlights till the end of the line, shift+home till the beginning.

----------
nosy: +ezio.melotti, terry.reedy
type: behavior -> crash
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14096>
_______________________________________

From report at bugs.python.org  Thu Feb 23 03:54:30 2012
From: report at bugs.python.org (Lex Berezhny)
Date: Thu, 23 Feb 2012 02:54:30 +0000
Subject: [issue14092] __name__ inconsistently applied in class definition
In-Reply-To: <1329953348.22.0.00582409575183.issue14092@psf.upfronthosting.co.za>
Message-ID: <1329965670.39.0.999868152943.issue14092@psf.upfronthosting.co.za>


Lex Berezhny <eukreign at gmail.com> added the comment:

I don't particularly need this functionality. It was just something that seemed  counter intuitive to me.

I discovered this while working on a python to javascript compiler. I'll probably implement the compiler to allow overriding with __name__ as it seems more intuitive to me that way.

Hopefully cpython will be changed to work that way too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14092>
_______________________________________

From report at bugs.python.org  Thu Feb 23 03:58:35 2012
From: report at bugs.python.org (David)
Date: Thu, 23 Feb 2012 02:58:35 +0000
Subject: [issue14086] str(KeyError("Foo")) Unexpected Result
In-Reply-To: <1329902756.66.0.575500165148.issue14086@psf.upfronthosting.co.za>
Message-ID: <1329965915.53.0.633848687558.issue14086@psf.upfronthosting.co.za>


David <vencabot_teppoo at hotmail.com> added the comment:

Thanks, Julian. I'm closing this and marking it as a duplicate of #2651.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14086>
_______________________________________

From report at bugs.python.org  Thu Feb 23 03:59:34 2012
From: report at bugs.python.org (wang)
Date: Thu, 23 Feb 2012 02:59:34 +0000
Subject: [issue14096] IDLE quits unexpectedly when some keys are pressed
In-Reply-To: <1329964892.44.0.577555550319.issue14096@psf.upfronthosting.co.za>
Message-ID: <1329965974.94.0.61741753172.issue14096@psf.upfronthosting.co.za>


wang <zevboy at gmail.com> added the comment:

thanks.
new version 3.2.2 have not this problem.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14096>
_______________________________________

From report at bugs.python.org  Thu Feb 23 04:00:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Feb 2012 03:00:07 +0000
Subject: [issue14086] str(KeyError("Foo")) Unexpected Result
In-Reply-To: <1329902756.66.0.575500165148.issue14086@psf.upfronthosting.co.za>
Message-ID: <1329966007.01.0.311414179661.issue14086@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> committed/rejected
superseder:  -> Strings passed to KeyError do not round trip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14086>
_______________________________________

From report at bugs.python.org  Thu Feb 23 04:02:33 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Feb 2012 03:02:33 +0000
Subject: [issue14096] IDLE quits unexpectedly when some keys are pressed
In-Reply-To: <1329964892.44.0.577555550319.issue14096@psf.upfronthosting.co.za>
Message-ID: <1329966153.66.0.99273420745.issue14096@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14096>
_______________________________________

From report at bugs.python.org  Thu Feb 23 04:14:16 2012
From: report at bugs.python.org (David)
Date: Thu, 23 Feb 2012 03:14:16 +0000
Subject: [issue2651] Strings passed to KeyError do not round trip
In-Reply-To: <1208453081.65.0.886847251895.issue2651@psf.upfronthosting.co.za>
Message-ID: <1329966856.43.0.369862099403.issue2651@psf.upfronthosting.co.za>


David <vencabot_teppoo at hotmail.com> added the comment:

I'm +1 for fixing this behavior for the same reasons that are mentioned in the OP: consistency and predictability. I raised this issue as #14086, and I was referred to this issue before closing mine as a duplicate.

It took me a while to figure out why I was getting unexpected escaped quotation marks in my strings, and it turned out that it was because I was passing strings back and forth as Exception arguments (tagging built-in Exceptions with a little bit of extra information when they occurred and re-raising), and every time that it occurred with a KeyError (and only with a KeyError), the string would grow another pair of quotation marks.

In my issue, I bring up the documentation in the Python Tutorial about Exception.args and Exception.__str__(); it states very plainly and simply (as it should be) that the __str__() method is there to be able to conveniently print Exception arguments without calling .args, and, when an unhandled Exception stops Python, the tail-end of the message (the details) of the exception will be the arguments that it was given. This is not the case with KeyError.

str(KeyError("Foo")) should be equal to "Foo", as it would be with any other Exception and as is the documented behavior of built-in Exceptions, at least in the tutorial (which I realize isn't the be-all, end-all document). The documented behavior makes more sense.

----------
nosy: +vencabot_teppoo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2651>
_______________________________________

From report at bugs.python.org  Thu Feb 23 04:14:35 2012
From: report at bugs.python.org (Eric Snow)
Date: Thu, 23 Feb 2012 03:14:35 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1329966875.34.0.511415230131.issue14080@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Thu Feb 23 04:23:20 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 23 Feb 2012 03:23:20 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1329967400.18.0.583126563388.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Marc, the MacOS X support is planned, but I want first to finish the Solaris support 100%. I am working with other people in being sure this patch works in a standard Solaris machine (my machines are heavily tuned, GNU tools installed, GCC, extra libraries, etc), specially under Sparc, that I can not check personally.

This work is progressing fine. I hope to have it done in a week or two.

After that, next step is MacOS, if I can convince a friend to spend a weekend at home with me :-).

BTW, as far as I know, DTrace port for MacOS X DOESN'T support "jstack();" at all. So that test must be skipped under MacOS.

Anyway, all of this is planned.

The gc-start/gc-done probe errors you are seeing are strange, but I can't investigate them until I start building under MacOS. Late March, I hope.

I assume your machine is x86 based, not PowerPC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Thu Feb 23 04:27:21 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 23 Feb 2012 03:27:21 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1329967641.92.0.772268419279.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Marc, if you have a XMPP account (for instance, gtalk), we can chat online and work together on this. My JID is jcea at jabber.org. I am in Spain, so Central European Time timezone (GMT+1, +2 under DST).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Thu Feb 23 04:36:33 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 23 Feb 2012 03:36:33 +0000
Subject: [issue14006] Improve the documentation of xml.etree.ElementTree
In-Reply-To: <1329190125.69.0.69162565954.issue14006@psf.upfronthosting.co.za>
Message-ID: <1329968193.97.0.794544535456.issue14006@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Converting sounds good to me, but it should be done carefully.

I think you can have two paragraphs in the docstrings: the first with the description of what it does and what it returns, and the second with the arguments.

For example Lib/xml/etree/ElementTree.py:355:
# Finds the first matching subelement, by tag name or path.
#
# @param path What element to look for.
# @keyparam namespaces Optional namespace prefix map.
# @return The first matching element, or None if no element was found.
# @defreturn Element or None

can become something like:
"""
Finds the first matching subelement, by tag name or path
and returns the first matching element, or None if no
 element was found.

*path* is the element to look for and *namespace* is an
optional namespace prefix map.
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14006>
_______________________________________

From report at bugs.python.org  Thu Feb 23 04:47:17 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Feb 2012 03:47:17 +0000
Subject: [issue14006] Improve the documentation of xml.etree.ElementTree
In-Reply-To: <1329190125.69.0.69162565954.issue14006@psf.upfronthosting.co.za>
Message-ID: <1329968837.3.0.273301679104.issue14006@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

My general rule is that function/method docstrings are better short descriptions of what the function does and what the arguments are, a usage reminder for people who have already used the function.  Classes docstrings can tell a bit more about how the class is supposed to be used, e.g. what particular responsibility they have and what they work with.  Module docstrings should help you make sense of the public objects in the module, for example tell about the main classes and functions and briefly mentioning the less important ones.

This is a personal viewpoint; some people use dir and pydoc a lot to get the most info out of a new module, whereas I like separate documentation more.

ElementTree has no docstrings at all, which is IMO bad; I?d like the javadoc comments to be turned into docstrings, and if they are too big they can be reduced to their core and the extra help moved to reST docs (which are at this moment in what looks like a good shape: they have the same info as the javadoc comments from a quick glance).

I think some of the comments can just be deleted, like the @see lines.  Finally, a note about the comments for attributes: they should be documented in the reST docs, and for the Python code you have two possibilities: you can document them in the class docstring, or put string literals after them (see http://www.python.org/dev/peps/pep-0258/#attribute-docstrings ? they are discarded by Python, so not available to help/pydoc, but some tools can process them).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14006>
_______________________________________

From report at bugs.python.org  Thu Feb 23 04:58:31 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 23 Feb 2012 03:58:31 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1329969511.26.0.174141017274.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Marc, the memory invalid accesses are because you are enabling all probes and printing three parameters, but each probe actually has a different number of parameters and different meaning for them. Current version:

"""
provider python {
    probe function__entry(const char *, const char *, int);
    probe function__return(const char *, const char *, int);
    probe instance__new__start(const char *, const char *);
    probe instance__new__done(const char *, const char *);
    probe instance__delete__start(const char *, const char *);
    probe instance__delete__done(const char *, const char *);
    probe line(const char *, const char *, int);
    probe gc__start(int);
    probe gc__done(long);
};
"""

In particular, this explain the weirdness in your gc-start/gc-done probes.

Can you run the testsuite with "./python Lib/test/regrtest.py -v test_dtrace.py"?. The stack dump test will fail for sure, because MacOS DTrace port doesn't support uhelpers at all.

5AM here. Time for some sleep!.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Thu Feb 23 05:22:36 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Feb 2012 04:22:36 +0000
Subject: [issue1927] raw_input behavior incorrect if readline not enabled
In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za>
Message-ID: <1329970956.66.0.809951096433.issue1927@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>From reading the code for raw_input in 2.7 or input in 3.3 (Python/bltinmodule.c:1573), it looks to me that stdout is used, which would mean this issue is fixed.  However I browsed the file history and could not find the commit that changed this, and my C skills are limited, so I?m adding Ezio to nosy to have another pair of eyes confirm.

----------
nosy: +eric.araujo, ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1927>
_______________________________________

From report at bugs.python.org  Thu Feb 23 05:26:20 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Feb 2012 04:26:20 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1329971180.3.0.654226832655.issue2771@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Let?s link to branches other than default: 2.7/Lib/fileinput.py, 3.2/Python/bltinmodule.c:42

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Thu Feb 23 06:37:53 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 23 Feb 2012 05:37:53 +0000
Subject: [issue14097] Improve the "introduction" page of the tutorial
Message-ID: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

I was reading the "introduction" page of the tutorial [0], and noticed a few things that could be improved:
 1) the first paragraph is a bit confusing, showing a simple example and explaining what the >>> is would be better;
 2) comments can be introduced later too, they are not really necessary at the beginning;
 3) the first example is supposed to introduce numbers and basic operations, but it's still going on with the comments;
 4) the note about floating point issues is not so relevant anymore nowadays, so it could be (re)moved;
 5) "A value can be assigned to several variables simultaneously:" is not technically correct;
 6) "Variables must be ?defined? (assigned a value) before they can be used" this might be improved too;
 7) almost half of the section about numbers goes on explaining complex numbers.  This is totally unnecessary here, I think that mentioning them and maybe showing a simple example is more than enough.  Another option is to make a subsection with a note that says that the section can be skipped;
 8) the examples in this part lack some space (e.g. "a=3.0+4.0j");
 9) the print() function could get a better introduction and used in the first set of string examples;
 10) suggesting to use continuation lines with a trailing \ in string literals is not a good idea, it's better to use """...""" or implicit concatenation inside ();
 11) "Degenerate slice indices are handled gracefully" it might be better to show that it's not the same for "non-slice" indices;
 12) the "About Unicode" section could link to the Unicode HOWTO;
 13) while it's true that lists can contain different types of object, they usually shouldn't;
 14) while the "while" example is good (it first shows a piece of code and then explains what it does), I would introduce the "if" and the "for" first.  The "while" is arguably the most complex and less used of the three statements.

[0]: http://docs.python.org/py3k/tutorial/introduction.html

----------
assignee: docs at python
components: Documentation
messages: 154051
nosy: docs at python, eli.bendersky, eric.araujo, ezio.melotti, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve the "introduction" page of the tutorial
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14097>
_______________________________________

From report at bugs.python.org  Thu Feb 23 08:58:41 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 23 Feb 2012 07:58:41 +0000
Subject: [issue14098] provide public C-API for reading/setting sys.exc_info()
Message-ID: <1329983921.26.0.0291312337524.issue14098@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

Following up on recent mailing list threads on pypy-dev and python-dev, this is a request for adding a public C-API to read and write the sys.exc_info() fields, currently stored in tstate->exc_*.

While not of major interest for CPython itself, this C-API addition would allow other Python implementations (currently PyPy) to hide their internal representation of these fields and to allow extensions that need to access them (most notably those generated by the Cython compiler) to write portable code.

Martin von L?wis proposed the names PyErr_GetExcInfo() and PyErr_SetExcInfo(), making them simple getter and setter functions that operate on owned references.

http://thread.gmane.org/gmane.comp.python.devel/129787/focus=129792

I'm currently working on a patch for CPython 3.3.

----------
components: Interpreter Core
messages: 154052
nosy: loewis, scoder
priority: normal
severity: normal
status: open
title: provide public C-API for reading/setting sys.exc_info()
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14098>
_______________________________________

From report at bugs.python.org  Thu Feb 23 09:00:41 2012
From: report at bugs.python.org (patrick vrijlandt)
Date: Thu, 23 Feb 2012 08:00:41 +0000
Subject: [issue13779] os.walk: bottom-up
In-Reply-To: <1329926477.96.0.0381681228891.issue13779@psf.upfronthosting.co.za>
Message-ID: <CAHRxO8is9ho9T_K4vFTk2BXFnEbzgkXRFjyjdO1J1_KhfsAidw@mail.gmail.com>


patrick vrijlandt <patrick.vrijlandt at gmail.com> added the comment:

Good solution. +1 for closing.

Patrick

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13779>
_______________________________________

From report at bugs.python.org  Thu Feb 23 09:44:21 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 23 Feb 2012 08:44:21 +0000
Subject: [issue13873] SIGBUS in test_big_buffer() of test_zlib on Debian
	bigmem buildbot
In-Reply-To: <1327583804.29.0.71599909936.issue13873@psf.upfronthosting.co.za>
Message-ID: <1329986661.74.0.830693692105.issue13873@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

"""
File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/test_zlib.py", line 96 in test_big_buffer
"""

The SIGBUS could be due to the buildbot running out of tmpfs.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13873>
_______________________________________

From report at bugs.python.org  Thu Feb 23 10:07:56 2012
From: report at bugs.python.org (Giovanni Funchal)
Date: Thu, 23 Feb 2012 09:07:56 +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: <1329988076.99.0.579096185799.issue10805@psf.upfronthosting.co.za>


Giovanni Funchal <gafunchal at gmail.com> added the comment:

This bug affects me, found it when migrating from 2.7 to 3.2, in a function calling traceback.print_exc() called while there were no "active" exception being handled. Previous behavior was to print "None".

----------
nosy: +Giovanni.Funchal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10805>
_______________________________________

From report at bugs.python.org  Thu Feb 23 11:08:34 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 23 Feb 2012 10:08:34 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
In-Reply-To: <1329960824.13.0.292987430999.issue1521950@psf.upfronthosting.co.za>
Message-ID: <1329991711.15169.YahooMailNeo@web171309.mail.ir2.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

>?ric Araujo <merwok at netwok.org> added the comment:

>I did not fully get what you meant here, but the example you added to the doc made it clear.? Is this covered by tests?

Yes, I believe that testSyntaxSplitCustom covers this.

>Overall great patch!? Dan, do you have time to test it (or read the new examples in the patch) to tell us if it meets what you wanted?

Thanks! It was a bit fiddly, shlex is somewhat difficult to extend cleanly. I developed this functionality for a subprocess ease-of-use-wrapper module called sarge, and I had to basically copy and modify the whole read_token method :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521950>
_______________________________________

From report at bugs.python.org  Thu Feb 23 11:09:22 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 23 Feb 2012 10:09:22 +0000
Subject: [issue14098] provide public C-API for reading/setting sys.exc_info()
In-Reply-To: <1329983921.26.0.0291312337524.issue14098@psf.upfronthosting.co.za>
Message-ID: <1329991762.26.0.227598054623.issue14098@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

I wonder if these functions should have an error return value, i.e. return -1 on failure. They'd "never" fail in CPython, but other implementations may want to report failures, in case their internal implementation is more involved. OTOH, documenting that they may fail (even though they won't) means that users will have to deal with errors in potentially tricky situations.

Amaury, any comments?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14098>
_______________________________________

From report at bugs.python.org  Thu Feb 23 11:46:32 2012
From: report at bugs.python.org (Stepan Kasal)
Date: Thu, 23 Feb 2012 10:46:32 +0000
Subject: [issue14099] zipfile: ZipFile.open() should not reopen the underlying
	file
Message-ID: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za>


New submission from Stepan Kasal <kasal at ucw.cz>:

When a file inside a zip is open, the underlying zip file is open again.
(Unless the file name is unknown, because the ZipFile object was created with fp only.)

This design is incorrect, insecure, and ineffective:
- the reopen uses the same string as file name, but on unix-like systems that file name may no longer exist, or may point to a different file
- opening n files from the same zip archive consumes n OS file descriptors, wasting resources

I believe that the parent ZipFile object and all the child ZipExtFile objects should keep the same fp.  The last one would close it.

I'm working on a patch currently.

----------
components: Library (Lib)
messages: 154058
nosy: kasal
priority: normal
severity: normal
status: open
title: zipfile: ZipFile.open() should not reopen the underlying file
type: resource usage
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14099>
_______________________________________

From report at bugs.python.org  Thu Feb 23 12:02:20 2012
From: report at bugs.python.org (Matej Cepl)
Date: Thu, 23 Feb 2012 11:02:20 +0000
Subject: [issue14099] zipfile: ZipFile.open() should not reopen the underlying
	file
In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za>
Message-ID: <1329994940.71.0.181575303695.issue14099@psf.upfronthosting.co.za>


Changes by Matej Cepl <mcepl at redhat.com>:


----------
nosy: +mcepl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14099>
_______________________________________

From report at bugs.python.org  Thu Feb 23 12:15:16 2012
From: report at bugs.python.org (sbt)
Date: Thu, 23 Feb 2012 11:15:16 +0000
Subject: [issue14095] type_new() removes __qualname__ from the input dictionary
In-Reply-To: <1329956865.57.0.697177106628.issue14095@psf.upfronthosting.co.za>
Message-ID: <1329995716.03.0.983489163333.issue14095@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

I get a segfault with

  Python 3.3.0a0 (default:31784350f849, Feb 23 2012, 11:07:41)
  [GCC 4.5.2] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> d = {'__qualname__':'XXX'}
  >>> T = type('foo', (), d)
  >>> d
  Segmentation fault

On Windows I also get a crash.  Wierdly, if I replace 'XXX' by 'foo', 
there is no segfault, but d is empty

  Python 3.3.0a0 (default:31784350f849, Feb 23 2012, 11:07:41)
  [GCC 4.5.2] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> d = {'__qualname__':'foo'}
  >>> T = type('foo', (), d)
  >>> d
  {}

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14095>
_______________________________________

From report at bugs.python.org  Thu Feb 23 12:36:23 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Feb 2012 11:36:23 +0000
Subject: [issue13873] SIGBUS in test_big_buffer() of test_zlib on Debian
	bigmem buildbot
In-Reply-To: <1327583804.29.0.71599909936.issue13873@psf.upfronthosting.co.za>
Message-ID: <E1S0WyD-0001uh-W4@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f3f3bb45205b by Nadeem Vawda in branch 'default':
Issue #13873: Fix crash in test_zlib on bigmem buildbot.
http://hg.python.org/cpython/rev/f3f3bb45205b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13873>
_______________________________________

From report at bugs.python.org  Thu Feb 23 13:21:55 2012
From: report at bugs.python.org (Massimo Paladin)
Date: Thu, 23 Feb 2012 12:21:55 +0000
Subject: [issue14091] python subprocess hangs if script called from another
	directory
In-Reply-To: <1329948004.01.0.833709233922.issue14091@psf.upfronthosting.co.za>
Message-ID: <1329999715.4.0.525058292203.issue14091@psf.upfronthosting.co.za>


Massimo Paladin <massimo.paladin at gmail.com> added the comment:

Will follow it.

Thanks,
-Massimo

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14091>
_______________________________________

From report at bugs.python.org  Thu Feb 23 13:44:05 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 23 Feb 2012 12:44:05 +0000
Subject: [issue13873] SIGBUS in test_big_buffer() of test_zlib on Debian
	bigmem buildbot
In-Reply-To: <1327583804.29.0.71599909936.issue13873@psf.upfronthosting.co.za>
Message-ID: <1330001045.99.0.22219964093.issue13873@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> The SIGBUS could be due to the buildbot running out of tmpfs.

I haven't been able to reproduce the crash by running the test on a tmpfs
on my own machine (Ubuntu AMD64; 8GB RAM; Linux 3.0.0-15-generic; zlib
1:1.2.3.4.dfsg-3ubuntu3), but maybe it's due to something specific about
the configuration of the buildbot machine?

I've temporarily changed the test to use a regular chunk of memory
instead of the mmap hack). If possible, I'd like to change back to the
old technique in the long run (since it allows the test to run on
machines with less RAM), but until we can figure out the problem, I'd
rather not have the test failing needlessly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13873>
_______________________________________

From report at bugs.python.org  Thu Feb 23 14:41:23 2012
From: report at bugs.python.org (sbt)
Date: Thu, 23 Feb 2012 13:41:23 +0000
Subject: [issue14087] multiprocessing.Condition.wait_for missing
In-Reply-To: <1329922885.58.0.881756065062.issue14087@psf.upfronthosting.co.za>
Message-ID: <1330004483.95.0.139854452421.issue14087@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

Patch which just copies the implementation from threading.

----------
keywords: +patch
Added file: http://bugs.python.org/file24611/cond_wait_for.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14087>
_______________________________________

From report at bugs.python.org  Thu Feb 23 15:47:36 2012
From: report at bugs.python.org (Dan Christian)
Date: Thu, 23 Feb 2012 14:47:36 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
Message-ID: <1330008456.13.0.707927106957.issue1521950@psf.upfronthosting.co.za>


Dan Christian <robodan at users.sourceforge.net> added the comment:

I haven't been following this much.  Sorry.  My day job isn't in this area any more (and I'm stuck using 2.4 :-().

Looking at the docs, I notice the "old" is different from what it used to be.  Notably: 'e;' gets split into two tokens; and ">'abc';" gets split into 3.  I'm pretty sure that baseline code doesn't split those at all.  So there is a question of if "old" is fully backward compatible.

The "new" functionality looks great.  That's what I was looking for when I filed the bug.

Thank you!
-Dan

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521950>
_______________________________________

From report at bugs.python.org  Thu Feb 23 15:58:10 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 23 Feb 2012 14:58:10 +0000
Subject: [issue14100] expose a note a hidden note
Message-ID: <1330009090.66.0.133471342458.issue14100@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

I wonder if this note was hidden deliberately.

----------
assignee: docs at python
components: Documentation
files: make-note-visible.patch
keywords: patch
messages: 154065
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: expose a note a hidden note
versions: Python 3.3
Added file: http://bugs.python.org/file24612/make-note-visible.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14100>
_______________________________________

From report at bugs.python.org  Thu Feb 23 16:01:37 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 23 Feb 2012 15:01:37 +0000
Subject: [issue14100] expose a note a hidden note
In-Reply-To: <1330009090.66.0.133471342458.issue14100@psf.upfronthosting.co.za>
Message-ID: <1330009297.72.0.459622435782.issue14100@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +haypo, pitrou
stage:  -> patch review
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14100>
_______________________________________

From report at bugs.python.org  Thu Feb 23 16:28:36 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 23 Feb 2012 15:28:36 +0000
Subject: [issue2209] mailbox module doesn't support compressed mbox
In-Reply-To: <1204283686.29.0.398991298124.issue2209@psf.upfronthosting.co.za>
Message-ID: <1330010916.39.0.600088426895.issue2209@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

J?rgen, would you consider writing a patch?

----------
nosy: +jcea
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2209>
_______________________________________

From report at bugs.python.org  Thu Feb 23 16:30:23 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 23 Feb 2012 15:30:23 +0000
Subject: [issue14100] expose a hidden note
In-Reply-To: <1330009090.66.0.133471342458.issue14100@psf.upfronthosting.co.za>
Message-ID: <1330011023.22.0.747465800228.issue14100@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
title: expose a note a hidden note -> expose a hidden note

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14100>
_______________________________________

From report at bugs.python.org  Thu Feb 23 16:38:17 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 23 Feb 2012 15:38:17 +0000
Subject: [issue14098] provide public C-API for reading/setting sys.exc_info()
In-Reply-To: <1329983921.26.0.0291312337524.issue14098@psf.upfronthosting.co.za>
Message-ID: <1330011497.73.0.277620087793.issue14098@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Writing up a test case, I noticed that it makes sense to let PyErr_SetExcInfo() steal the references. This matches the main use case of saving and restoring the fields. For the getter, it's still best to return new references in order to support the use case of just reading the fields, as well as the use case of reading and clearing the fields (which a subsequent call to PyErr_SetExcInfo(NULL,NULL,NULL) does).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14098>
_______________________________________

From report at bugs.python.org  Thu Feb 23 16:45:34 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 23 Feb 2012 15:45:34 +0000
Subject: [issue14100] expose a hidden note
In-Reply-To: <1330009090.66.0.133471342458.issue14100@psf.upfronthosting.co.za>
Message-ID: <1330011934.26.0.466334584886.issue14100@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, presumably the XXX tells you why it's hidden.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14100>
_______________________________________

From report at bugs.python.org  Thu Feb 23 16:46:03 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 23 Feb 2012 15:46:03 +0000
Subject: [issue14098] provide public C-API for reading/setting sys.exc_info()
In-Reply-To: <1329983921.26.0.0291312337524.issue14098@psf.upfronthosting.co.za>
Message-ID: <1330011963.18.0.663716940863.issue14098@psf.upfronthosting.co.za>


Changes by Stefan Behnel <scoder at users.sourceforge.net>:


----------
keywords: +patch
Added file: http://bugs.python.org/file24613/exc_info_capi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14098>
_______________________________________

From report at bugs.python.org  Thu Feb 23 16:57:09 2012
From: report at bugs.python.org (Meador Inge)
Date: Thu, 23 Feb 2012 15:57:09 +0000
Subject: [issue14095] type_new() removes __qualname__ from the input dictionary
In-Reply-To: <1329956865.57.0.697177106628.issue14095@psf.upfronthosting.co.za>
Message-ID: <1330012629.91.0.510809413359.issue14095@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14095>
_______________________________________

From report at bugs.python.org  Thu Feb 23 17:05:17 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 23 Feb 2012 16:05:17 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1330013117.15.0.544716136111.issue10848@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Thu Feb 23 17:47:46 2012
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 23 Feb 2012 16:47:46 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1329957307.21.0.164717878451.issue2377@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W6R2_4SPO7Xkn=TSLUcTe_=73UQAVOhhx17o_mvSoC4VQ@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Wed, Feb 22, 2012 at 19:35, ?ric Araujo <report at bugs.python.org> wrote:

I have already done that and pushed the initial change. The ultimate goal
will be fetching from sys.modules when level == 0 and not bool(fromlist)
only touch C code. All other work will touch varying levels of Python code.
Someone else can worry about speeding up fromlist so that only C code is
touched when level == 0.

I also have some failing tests, but that all has to do with Antoine's
caching work and thus fails in the default branch as well when the tests
are run under importlib itself (i.e. tests that generate a file and then
immediately try to import it). But what's nice is that test_reprlib now
fails only in my bootstrap branch and not default because it is just fast
enough to beat the directory mtime granularity. =)

Ha! I wish. I have to get within reasonable striking distance of current
performance or else I will get blocked for including the work.

It's possible as long as it is exposed through imp.

> 4) When is PyPy going to be the reference implementation again?  Then
> we?ll have no speed issues?ha ha only serious.
>
> 5) importlib rocks hard.

=) Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Thu Feb 23 17:55:16 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 23 Feb 2012 16:55:16 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>
Message-ID: <1330016116.68.0.225262880714.issue13447@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Shall I commit the new file or first add more tests?

Might as well commit now; there's no sense in leaving the code sitting
around just because the file feels a bit short.

A couple of minor nits about your patch, though:

- The docstring for test_tools says "Tests for reindent.py". It would be
  better to have something referring to the Tools directory, so people
  know that this is the right place to put new tests for scripts that
  currently don't have any.

- The wording of the message 'requires an uninstalled Python build' is a
  bit awkward - I'd use "non-installed" instead of "uninstalled", so
  inexperienced users don't go and try to uninstall their system Python ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Thu Feb 23 17:58:05 2012
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 23 Feb 2012 16:58:05 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1330016285.31.0.664190757974.issue2377@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

That last comment from me looks odd because somewhere along the way my replies to ?ric's comment got stripped out.

First two paragraphs are in response to 1)
Third paragraph is for 2)
Fourth paragraph is for 3)

Rest makes sense since the inline reply survived.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Thu Feb 23 18:19:41 2012
From: report at bugs.python.org (sbt)
Date: Thu, 23 Feb 2012 17:19:41 +0000
Subject: [issue14059] Implement multiprocessing.Barrier
In-Reply-To: <1329699138.74.0.937439869593.issue14059@psf.upfronthosting.co.za>
Message-ID: <1330017581.75.0.947087097198.issue14059@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

Patch which subclasses threading.Barrier.

----------
keywords: +patch
Added file: http://bugs.python.org/file24614/mp_barrier.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14059>
_______________________________________

From report at bugs.python.org  Thu Feb 23 18:23:37 2012
From: report at bugs.python.org (Peter)
Date: Thu, 23 Feb 2012 17:23:37 +0000
Subject: [issue11438] 2to3 does not fix izip_longest
In-Reply-To: <1299552985.81.0.590298886377.issue11438@psf.upfronthosting.co.za>
Message-ID: <1330017817.11.0.991181612938.issue11438@psf.upfronthosting.co.za>


Changes by Peter <p.j.a.cock at googlemail.com>:


----------
nosy: +maubp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11438>
_______________________________________

From report at bugs.python.org  Thu Feb 23 18:32:29 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 23 Feb 2012 17:32:29 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1330018349.83.0.221581802066.issue7652@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Added file: http://bugs.python.org/file24615/40917e4b51aa.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Thu Feb 23 18:33:53 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 23 Feb 2012 17:33:53 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1330018433.14.0.672501581514.issue7652@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Over the last two months I've done a full review of all files except
_decimal.c and mpdecimal.c.

I now have additional ACL2 proofs for a couple of functions in basearith.c
(some are partial proofs), a full proof for the special case (d = 10**19)
of Granlund/Montgomery's "Divide double word by constant" algorithm and a
full proof for the Chinese Remainder Theorem in crt.c.


I didn't find anything important. I found a couple of useless variable
initializations, missing comments etc.

There was one (deliberate) incompatibility in the format function:
If rounding lead to an Overflow, _decimal printed 'Infinity'.

_decimal can't read back numbers that are out of bounds, so this
was done to ensure that a roundtrip is always possible.


But I changed the function so _decimal now uses exactly the same algorithm
for formatting as decimal.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Thu Feb 23 18:41:30 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 23 Feb 2012 17:41:30 +0000
Subject: [issue14095] type_new() removes __qualname__ from the input dictionary
In-Reply-To: <1329956865.57.0.697177106628.issue14095@psf.upfronthosting.co.za>
Message-ID: <1330018890.83.0.987315264993.issue14095@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.
(I can't reproduce the crash, btw)

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file24616/qualname_dict.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14095>
_______________________________________

From report at bugs.python.org  Thu Feb 23 19:11:02 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 23 Feb 2012 18:11:02 +0000
Subject: [issue14071] allow more than one hash seed per process (move
	_Py_HashSecret into PyInterpreterState)
In-Reply-To: <1329807287.0.0.916593271901.issue14071@psf.upfronthosting.co.za>
Message-ID: <1330020662.14.0.694240967105.issue14071@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Agreed with Victor, this is not really doable currently.
Besides, you can't really have several interpreter instances simultaneously, you can have several sub-interpreters, which isn't exactly the same thing (sub-interpreters share some stuff, I don't remember which exactly).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14071>
_______________________________________

From report at bugs.python.org  Thu Feb 23 19:50:33 2012
From: report at bugs.python.org (Stepan Kasal)
Date: Thu, 23 Feb 2012 18:50:33 +0000
Subject: [issue14099] zipfile: ZipFile.open() should not reopen the underlying
	file
In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za>
Message-ID: <1330023033.33.0.751804639959.issue14099@psf.upfronthosting.co.za>


Stepan Kasal <kasal at ucw.cz> added the comment:

Attached please find a patch that fixes this issue by reusing the original fp from ZipFile object.

Two of the test cases attempted to read a file from a zip as soon as write() was called.  I believe that this is not correct usage: zip file is not even fully written to disk at that stage!
So I took the liberty to change these two test cases so that they first write the file and then read it.

Let me thank to Martin Sikora for discovering the issue and to Matej Cepl for testing it on current source tree.

----------
keywords: +patch
Added file: http://bugs.python.org/file24617/Proposed-fix-of-issue14099.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14099>
_______________________________________

From report at bugs.python.org  Thu Feb 23 20:06:51 2012
From: report at bugs.python.org (sbt)
Date: Thu, 23 Feb 2012 19:06:51 +0000
Subject: [issue14059] Implement multiprocessing.Barrier
In-Reply-To: <1329699138.74.0.937439869593.issue14059@psf.upfronthosting.co.za>
Message-ID: <1330024011.16.0.32825202836.issue14059@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

Forgot to mention, mp_barrier.patch needs to be applied on top of cond_wait_for.patch for Issue14087.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14059>
_______________________________________

From report at bugs.python.org  Thu Feb 23 20:07:23 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 23 Feb 2012 19:07:23 +0000
Subject: [issue13866] {urllib,
	urllib.parse}.urlencode should not use quote_plus
In-Reply-To: <1327529522.13.0.464287316871.issue13866@psf.upfronthosting.co.za>
Message-ID: <1330024043.01.0.695826546818.issue13866@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

A couple of points to help summarize and to help come to a conclusion.

In the initial message, Stephen pointed out, "it would be desirable to merely encode spaces using percent encoding".

It seems to me that only in cases where a custom handling of query string is done, would space be encoded to %20 (or if it's an IRI instead of URI - details below) and for HTTP requests and in both GET and POST, encoding to space in a URI to + is a correct thing to do.

The query part in the URL always needs to follow the application/x-www-form-urlencoded format, so even when urlencode is used for constructing a query parameters, it should encode space to +

The argument that all characters should be hex encoded (and thereby space should be %20), seems to apply if it is an IRI. Look at an interesting discussion in this link:
http://stackoverflow.com/questions/5366007/why-does-the-encodings-of-a-url-and-the-query-string-part-differ/5433216#5433216

Only with this point as consideration. I think, sending a parameter for quote to use quote or quote_plus may be worthy option to consider (Stephen's point #3). 

But I have to add that the existing behavior of replacing space with "+" in "URL"s is not breaking anything and in fact is following the rules properly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13866>
_______________________________________

From report at bugs.python.org  Thu Feb 23 20:17:08 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 23 Feb 2012 19:17:08 +0000
Subject: [issue13873] SIGBUS in test_big_buffer() of test_zlib on Debian
	bigmem buildbot
In-Reply-To: <1330001045.99.0.22219964093.issue13873@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM20rdqQ1H9+9igaQ7Nur5PtQGpg-bSG4Nc8_oW9gve2pg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> but maybe it's due to something specific about  the configuration of the buildbot
> machine?

Maybe you didn't try with a large enough file. Here's a trial on my box:
"""
$ df -h /tmp/
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           253M   68K  253M   1% /tmp
$ cat /tmp/test.py
import mmap
import zlib

f = open('/tmp/foo', 'wb+')
f.seek(512 * 1024 * 1024)
f.write(b'x')
f.flush()
m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
zlib.crc32(m)
m.close()
$ python /tmp/test.py
Bus error (core dumped)
"""

> I've temporarily changed the test to use a regular chunk of memory
>instead of the mmap hack). If possible, I'd like to change back to the
>old technique in the long run (since it allows the test to run on
>machines with less RAM)

Yes, but this kind of test is only supposed to be run on machines
which have enough memory.
Also, if the filesystem doesn't support sparse files, this writes a
lot to the disk (and if it crashes, you end up with a huge file).
I'd say it's fine this way...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13873>
_______________________________________

From report at bugs.python.org  Thu Feb 23 20:59:55 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 23 Feb 2012 19:59:55 +0000
Subject: [issue13873] SIGBUS in test_big_buffer() of test_zlib on Debian
	bigmem buildbot
In-Reply-To: <1327583804.29.0.71599909936.issue13873@psf.upfronthosting.co.za>
Message-ID: <1330027195.44.0.938276880911.issue13873@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Well, it turns out that when I tested it on my own machine, I actually
wasn't using a tmpfs - I misread the output of df and used /tmp? instead
of /run. Doing the test in /run does in fact give a bus error. Mea culpa.

? Apparently on my system /tmp isn't a tmpfs. Go figure.


> Also, if the filesystem doesn't support sparse files, this writes a
> lot to the disk (and if it crashes, you end up with a huge file).

You may be right; I hadn't thought about that possibility. My concern was
that the test suite isn't run with -M very often, so these sorts of tests
could often be broken for a while before someone found out. In the past,
none of the buildbots ran bigmem tests, so there was a real danger that
we wouldn't notice breakages. However, with the addition of the debian
bigmem buildbot, that is no longer the case, so this isn't such an issue
any more.

I'm okay with leaving the tests as they are in 3.3. Any objections?
If not, I'll also backport the change to 3.2 and 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13873>
_______________________________________

From report at bugs.python.org  Thu Feb 23 21:01:02 2012
From: report at bugs.python.org (Stephen Day)
Date: Thu, 23 Feb 2012 20:01:02 +0000
Subject: [issue13866] {urllib,
	urllib.parse}.urlencode should not use quote_plus
In-Reply-To: <1327529522.13.0.464287316871.issue13866@psf.upfronthosting.co.za>
Message-ID: <1330027262.81.0.49889942612.issue13866@psf.upfronthosting.co.za>


Stephen Day <stevvooe at gmail.com> added the comment:

While it's likely that adding a `quote`/`quote_plus` function paramater to urlencode is the right solution, I want to ensure that the key point is communicated clearly: encoding a space as a '+' is pathological, in that in the common case, an unescaped encoded character is indistinguishable from a literal '+'. Take the case of the literal string '+ '. If one uses the javascript encodeURI function to encode the string in a browser console, one gets the following:

> encodeURI('+ ')
"+%20"

Now, we have a string that will not decode symmetrically. In other words, we cannot tell if this string should decode to '  ' or '+ '. And while use of encodeURI is discouraged, application developers still use it places, introducing these kinds of errors.

Conversely, we can see that the behavior of encodeURIComponent, is unambiguous:

encodeURIComponent('+ ')
"%2B%20"

And while these are analogues to quote and quote_plus (there exists now analogue to javascripts urlencode), it's easy to see that disambiguating the encoding of the resulting output of urlencode would be desirable.

There is a similar situation with php library functions. 

Furthermore, it is agreed that urlencode does follow the rules, but the rules, as they are, introduce an asymmetrical, pathological encoding. Most services accept '%20' as space in lieu of '+' when data is encoded as 'application/x-www-form-urlencoded' anyway.

Concluding, I know it seems a little silly to spend time filing this bug and provide relevant cases, but I'd like to cite professional experience in this matter; I have seen "pluses-for-spaces" introduce errors time and time again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13866>
_______________________________________

From report at bugs.python.org  Thu Feb 23 21:03:35 2012
From: report at bugs.python.org (Meador Inge)
Date: Thu, 23 Feb 2012 20:03:35 +0000
Subject: [issue14095] type_new() removes __qualname__ from the input dictionary
In-Reply-To: <1329956865.57.0.697177106628.issue14095@psf.upfronthosting.co.za>
Message-ID: <1330027415.07.0.495856370159.issue14095@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I can reproduce the segfault on F16:

Python 3.3.0a0 (default:3828d93fd330, Feb 23 2012, 13:49:57) 
[GCC 4.4.6] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> d = {'__qualname__':'XXX'}
[66934 refs]
>>> T = type('foo', (), d)
[66956 refs]
>>> T
python: Objects/unicodeobject.c:301: _PyUnicode_CheckConsistency: Assertion `((((((PyObject*)(op))->ob_type))->tp_flags & ((1L<<28))) != 0)' failed.
Aborted (core dumped)

The patch looks mostly OK, but I can still segfault the interpreter by using a '__qualname__' of 'None':

Python 3.3.0a0 (default:3828d93fd330+, Feb 23 2012, 13:55:57) 
[GCC 4.4.6] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> d = {'__qualname__':'XXX'}
[67128 refs]
>>> T = type('foo', (), d)
[67156 refs]
>>> T
<class '__main__.XXX'>
[67161 refs]
>>> d = {'__qualname__': None}
[67161 refs]
>>> T = type('foo', (), d)
[67185 refs]
>>> T
python: Objects/unicodeobject.c:301: _PyUnicode_CheckConsistency: Assertion `((((((PyObject*)(op))->ob_type))->tp_flags & ((1L<<28))) != 0)' failed.
Aborted (core dumped)

Try this additional unit test:

        d = {'__qualname__': None}
        tp = type('foo', (), d)
        self.assertEqual(tp.__qualname__, None)
        self.assertEqual(tp.__dict__['__qualname__'], None)
        self.assertEqual(d, {'__qualname__': None})
        self.assertTrue(repr(tp))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14095>
_______________________________________

From report at bugs.python.org  Thu Feb 23 21:07:13 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Thu, 23 Feb 2012 20:07:13 +0000
Subject: [issue14101] example function in tertools.count is misindented
Message-ID: <1330027633.46.0.670191761588.issue14101@psf.upfronthosting.co.za>


New submission from Zbyszek Szmek <zbyszek at in.waw.pl>:

Indentation is broken.

diff --git a/Modules/itertoolsmodule.c b/Modules/itertoolsmodule.c
--- a/Modules/itertoolsmodule.c
+++ b/Modules/itertoolsmodule.c
@@ -3221,10 +3221,10 @@
 Return a count object whose .__next__() method returns consecutive values.\n\
 Equivalent to:\n\n\
     def count(firstval=0, step=1):\n\
-    x = firstval\n\
-    while 1:\n\
-        yield x\n\
-        x += step\n");
+        x = firstval\n\
+        while 1:\n\
+            yield x\n\
+            x += step\n");

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: itertools-count-indentation.diff
keywords: patch
messages: 154084
nosy: docs at python, zbysz
priority: normal
severity: normal
status: open
title: example function in tertools.count is misindented
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file24618/itertools-count-indentation.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14101>
_______________________________________

From report at bugs.python.org  Thu Feb 23 21:08:48 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Feb 2012 20:08:48 +0000
Subject: [issue14095] type_new() removes __qualname__ from the input dictionary
In-Reply-To: <1329956865.57.0.697177106628.issue14095@psf.upfronthosting.co.za>
Message-ID: <1330027728.84.0.692820213753.issue14095@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Here is a patch.

Oh, I also wrote a patch :-) My patch fixes this issue but also many memory leaks in error cases.

> (I can't reproduce the crash, btw)

I can reproduce the crash, but only with Python compiled in release mode (not with Python compiled in debug mode).

----------
Added file: http://bugs.python.org/file24619/type_new.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14095>
_______________________________________

From report at bugs.python.org  Thu Feb 23 21:14:00 2012
From: report at bugs.python.org (Meador Inge)
Date: Thu, 23 Feb 2012 20:14:00 +0000
Subject: [issue14095] type_new() removes __qualname__ from the input dictionary
In-Reply-To: <1329956865.57.0.697177106628.issue14095@psf.upfronthosting.co.za>
Message-ID: <1330028040.01.0.957986997321.issue14095@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

haypo, I can reproduce the segfault using the 'None' test case on your patch as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14095>
_______________________________________

From report at bugs.python.org  Thu Feb 23 21:23:32 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Feb 2012 20:23:32 +0000
Subject: [issue13873] SIGBUS in test_big_buffer() of test_zlib on Debian
	bigmem buildbot
In-Reply-To: <1327583804.29.0.71599909936.issue13873@psf.upfronthosting.co.za>
Message-ID: <1330028612.03.0.103755561807.issue13873@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> I'm okay with leaving the tests as they are in 3.3. Any objections?

Nope, it's fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13873>
_______________________________________

From report at bugs.python.org  Thu Feb 23 21:26:06 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Feb 2012 20:26:06 +0000
Subject: [issue14091] python subprocess hangs if script called from another
	directory
In-Reply-To: <1329948004.01.0.833709233922.issue14091@psf.upfronthosting.co.za>
Message-ID: <1330028766.77.0.774428156164.issue14091@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Will follow it.

If you report the issue to abrt, could you give me the url to your report please? (as a comment to this issue)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14091>
_______________________________________

From report at bugs.python.org  Thu Feb 23 22:15:22 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Feb 2012 21:15:22 +0000
Subject: [issue14095] type_new() removes __qualname__ from the input dictionary
In-Reply-To: <1329956865.57.0.697177106628.issue14095@psf.upfronthosting.co.za>
Message-ID: <1330031722.52.0.96165163314.issue14095@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I merged the two patches (qualname_dict.patch and type_new.patch) and added a fix for non-string __qualname__ => type_new-2.patch.

----------
Added file: http://bugs.python.org/file24620/type_new-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14095>
_______________________________________

From report at bugs.python.org  Thu Feb 23 22:16:00 2012
From: report at bugs.python.org (Daniel Walsh)
Date: Thu, 23 Feb 2012 21:16:00 +0000
Subject: [issue14102] argparser should create a man page for me.
Message-ID: <1330031760.56.0.8938390885.issue14102@psf.upfronthosting.co.za>


New submission from Daniel Walsh <rhatdan at gmail.com>:

I have developed a new tool virt-sandbox-service using argparse.  Currently the argparse has the ability to print help and usage.  Being naturally lazy, I think it should be able to print out a man page also.  This would help with development and make maintaining the different documents.

----------
components: None
messages: 154090
nosy: Daniel.Walsh, dmalcolm
priority: normal
severity: normal
status: open
title: argparser should create a man page for me.
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14102>
_______________________________________

From report at bugs.python.org  Thu Feb 23 22:18:02 2012
From: report at bugs.python.org (Daniel Walsh)
Date: Thu, 23 Feb 2012 21:18:02 +0000
Subject: [issue14103] argparser should create a bash_completion script for me.
Message-ID: <1330031882.01.0.825351616002.issue14103@psf.upfronthosting.co.za>


New submission from Daniel Walsh <rhatdan at gmail.com>:

I have developed a new tool virt-sandbox-service using argparse.  Currently the argparse has the ability to print help and usage.  Being naturally lazy, I think it should be able to generate a bash_completion script also.

----------
messages: 154091
nosy: Daniel.Walsh, dmalcolm
priority: normal
severity: normal
status: open
title: argparser should create a bash_completion script for me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14103>
_______________________________________

From report at bugs.python.org  Thu Feb 23 22:22:49 2012
From: report at bugs.python.org (Chris Rebert)
Date: Thu, 23 Feb 2012 21:22:49 +0000
Subject: [issue13866] {urllib,
	urllib.parse}.urlencode should not use quote_plus
In-Reply-To: <1327529522.13.0.464287316871.issue13866@psf.upfronthosting.co.za>
Message-ID: <1330032169.4.0.251819753884.issue13866@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13866>
_______________________________________

From report at bugs.python.org  Thu Feb 23 22:29:33 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 23 Feb 2012 21:29:33 +0000
Subject: [issue14097] Improve the "introduction" page of the tutorial
In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>
Message-ID: <1330032573.74.0.502519603795.issue14097@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

some of theses are great suggestions.  I'll do an update shortly.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14097>
_______________________________________

From report at bugs.python.org  Thu Feb 23 22:39:55 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 23 Feb 2012 21:39:55 +0000
Subject: [issue14103] argparser should create a bash_completion script for me.
In-Reply-To: <1330031882.01.0.825351616002.issue14103@psf.upfronthosting.co.za>
Message-ID: <1330033195.31.0.614109522758.issue14103@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
components: +Library (Lib)
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14103>
_______________________________________

From report at bugs.python.org  Thu Feb 23 22:49:36 2012
From: report at bugs.python.org (Chris Rebert)
Date: Thu, 23 Feb 2012 21:49:36 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1330033776.37.0.467328849299.issue13703@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Thu Feb 23 23:06:20 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 23 Feb 2012 22:06:20 +0000
Subject: [issue14087] multiprocessing.Condition.wait_for missing
In-Reply-To: <1329922885.58.0.881756065062.issue14087@psf.upfronthosting.co.za>
Message-ID: <1330034780.92.0.509259920259.issue14087@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

In test/test_multiprocessing.py:
"""
   def test_waitfor(self):
       [...]
       with cond:
           result = cond.wait_for(lambda : state.value==0)
           self.assertTrue(result)
           self.assertEqual(state.value, 0)
           for i in range(4):
               time.sleep(0.01)
               with cond:
                   state.value += 1
                   cond.notify()
"""

Shouldn't the `for` loop be outside the outer `with` block?

In Lib/multiprocessing/managers.py:
Is there a good reason why the wait_for() proxy method can't simply be implemented as:
return self._callmethod('wait_for', (predicate, timeout))?

(There may be, I just didn't check).

Finally, the documentation should be updated (Doc/library/multiprocessing.rst).

Otherwise, it would probably be better if you could submit a contributor agreement (and also maybe update your name on the tracker), unless that's a problem for you?

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14087>
_______________________________________

From report at bugs.python.org  Thu Feb 23 23:13:03 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 23 Feb 2012 22:13:03 +0000
Subject: [issue812369] module shutdown procedure based on GC
In-Reply-To: <1329499155.03.0.0606955045376.issue812369@psf.upfronthosting.co.za>
Message-ID: <4F46B9ED.5070909@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> (This is just a report about PyPy's situation; I understand that the
> situation in CPython is a bit more delicate if CPython is embedded in
> a larger process.)

I think that would indeed be unacceptable for Python - there is a
long-standing expectation that we free all memory that we allocated,
as well as release any other resources that we hold. There are also
expectations wrt. running atexit code. So there clearly must be a
shutdown procedure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue812369>
_______________________________________

From report at bugs.python.org  Fri Feb 24 00:09:15 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Feb 2012 23:09:15 +0000
Subject: [issue14104] Implement time.monotonic() on Mac OS X
Message-ID: <1330038555.4.0.559569598295.issue14104@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

time.monotonic() can use mach_absolute_time() on Mac OS X. mach_timebase_info() may be used to convert the result to a number of seconds. Examples:

https://github.com/ThomasHabets/monotonic_clock/blob/master/src/monotonic_mach.c
http://svn.boost.org/svn/boost/trunk/boost/chrono/detail/inlined/mac/chrono.hpp
(search steady_clock)

Another way is to use clock_get_time() with host_get_clock_service(SYSTEM_CLOCK). Example:

https://github.com/gavinbeatty/python-monotonic-time/blob/master/darwin.c

----------
components: Library (Lib)
messages: 154095
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: Implement time.monotonic() on Mac OS X
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14104>
_______________________________________

From report at bugs.python.org  Fri Feb 24 00:10:17 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Feb 2012 23:10:17 +0000
Subject: [issue13846] Add time.monotonic() function
In-Reply-To: <1327364549.64.0.960699645726.issue13846@psf.upfronthosting.co.za>
Message-ID: <E1S0hnk-0002ZW-IL@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 50b1f2d07011 by Victor Stinner in branch 'default':
Issue #13846: Enhance time.monotonic() documentation
http://hg.python.org/cpython/rev/50b1f2d07011

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13846>
_______________________________________

From report at bugs.python.org  Fri Feb 24 00:11:19 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Feb 2012 23:11:19 +0000
Subject: [issue13846] Add time.monotonic() function
In-Reply-To: <1327364549.64.0.960699645726.issue13846@psf.upfronthosting.co.za>
Message-ID: <1330038679.1.0.184118397789.issue13846@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Boost has a monotonic time implementation (steady_clock) for OS X

I opened a new issue for Mac OS X: #14104.

--

@?ric: I enhanced the doc. Feel free to complete or rewrite it if you have better information about such clocks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13846>
_______________________________________

From report at bugs.python.org  Fri Feb 24 00:31:26 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 23 Feb 2012 23:31:26 +0000
Subject: [issue14104] Implement time.monotonic() on Mac OS X
In-Reply-To: <1330038555.4.0.559569598295.issue14104@psf.upfronthosting.co.za>
Message-ID: <1330039886.27.0.196495722349.issue14104@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14104>
_______________________________________

From report at bugs.python.org  Fri Feb 24 00:49:32 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Feb 2012 23:49:32 +0000
Subject: [issue13706] non-ascii fill characters no longer work in formatting
In-Reply-To: <1325630185.42.0.0487894537415.issue13706@psf.upfronthosting.co.za>
Message-ID: <E1S0iPj-0005kH-15@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f89e2f4cda88 by Victor Stinner in branch 'default':
Issue #13706: Fix format(int, "n") for locale with non-ASCII thousands separator
http://hg.python.org/cpython/rev/f89e2f4cda88

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13706>
_______________________________________

From report at bugs.python.org  Fri Feb 24 01:26:23 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 24 Feb 2012 00:26:23 +0000
Subject: [issue13706] non-ascii fill characters no longer work in formatting
In-Reply-To: <1325630185.42.0.0487894537415.issue13706@psf.upfronthosting.co.za>
Message-ID: <1330043183.05.0.168567957665.issue13706@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The ps_AF locale fails with an assert after the latest commit:


Python 3.3.0a0 (default:f89e2f4cda88+, Feb 24 2012, 01:14:50) 
[GCC 4.4.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
[67103 refs]
>>> locale.setlocale(locale.LC_ALL, "ps_AF")
'ps_AF'
[67108 refs]
>>> format(13232434234.23423, "n")
python: Python/formatter_unicode.c:606: fill_number: Assertion `r == spec->n_grouped_digits' failed.
Aborted

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13706>
_______________________________________

From report at bugs.python.org  Fri Feb 24 01:47:05 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 24 Feb 2012 00:47:05 +0000
Subject: [issue13706] non-ascii fill characters no longer work in formatting
In-Reply-To: <1325630185.42.0.0487894537415.issue13706@psf.upfronthosting.co.za>
Message-ID: <E1S0jJP-00022T-RM@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a29d20fa85b4 by Victor Stinner in branch 'default':
Issue #13706: Fix format(float, "n") for locale with non-ASCII decimal point (e.g. ps_aF)
http://hg.python.org/cpython/rev/a29d20fa85b4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13706>
_______________________________________

From report at bugs.python.org  Fri Feb 24 01:56:28 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Feb 2012 00:56:28 +0000
Subject: [issue13706] non-ascii fill characters no longer work in formatting
In-Reply-To: <1325630185.42.0.0487894537415.issue13706@psf.upfronthosting.co.za>
Message-ID: <1330044988.82.0.0738216441307.issue13706@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> The ps_AF locale fails with an assert after the latest commit:
> ...
> format(13232434234.23423, "n")
> python: Python/formatter_unicode.c:606: fill_number: 
> Assertion `r == spec->n_grouped_digits' failed.
> Aborted

Oh, you found a locale with a non-ASCII decimal point, cool! I failed to find such locale. The last commit makes Python supports non-ASCII decimal point.

Your comment is incorrect, it was already failing before my commit ;-) Example at changeset 548a023c8230:

$ LANG=ps_AF ./python 
Python 3.3.0a0 (default:548a023c8230, Feb 24 2012, 01:48:01) 
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'ps_AF')
'ps_AF'
>>> format(0.1, 'n')
python: Objects/unicodeobject.c:391: _PyUnicode_CheckConsistency: Assertion `maxchar < 128' failed.
Abandon

--

By the way, Python 3.2 fails also to handle non-ASCII thousands separator or non-ASCII decimal point:

$ LANG=ps_AF python3
Python 3.2.1 (default, Jul 11 2011, 18:54:42) 
[GCC 4.6.1 20110627 (Red Hat 4.6.1-1)] on linux2
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'ps_AF')
'ps_AF'
>>> format(1234, 'n')
'1\Uffffffd9\Uffffffac234'
>>> format(0.1, 'n')
'0\Uffffffd9\Uffffffab1'

D9 AC/AB are byte strings b'\xD9\xAC' and b'\xD9\xAB' which are UTF-8 encode strings corresponding to U+066C (arabic thousands separator) and U+066B (arabic decimal separator).

\Uffffffab is a bug in a cast from signed char to 32-bit unsigned integer (Py_UNICODE on Linux).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13706>
_______________________________________

From report at bugs.python.org  Fri Feb 24 02:04:00 2012
From: report at bugs.python.org (Larry A. Taylor)
Date: Fri, 24 Feb 2012 01:04:00 +0000
Subject: [issue10722] IDLE's subprocess didnit make connection ..... Python 2.7
In-Reply-To: <1292541211.42.0.50542503549.issue10722@psf.upfronthosting.co.za>
Message-ID: <1330045440.86.0.948714401194.issue10722@psf.upfronthosting.co.za>


Larry A. Taylor <larry.taylor at bankofamerica.com> added the comment:

I have had this happen to me many times with Windows XP, the standard OS here. Using IDLE and Python 2.7.

Some of the time the following applies: I have more than one Python Shell open at the same time. The first Python shell/IDLE with debug is running a long job I don't want to interrupt. 

A second IDLE edit window is connected to the second Python shell. I set the shell to debug, then to the edit window with the program, and select 'run'. 

Result: I get the message reported in this issue. Sometimes.

It appears to have nothing to do with firewalls.

----------
nosy: +ltaylor934

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10722>
_______________________________________

From report at bugs.python.org  Fri Feb 24 02:06:39 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Feb 2012 01:06:39 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1330045599.0.0.347459341445.issue2377@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, so I have now streamlined the case so that only C is called when a module is in sys.modules, level == 0 and not fromlist.

Using the normal_startup benchmark, bootstrapped importlib is 1.12x slower. A fast run of startup_nosite puts it at 1.2x slower.

Using importlib.test.benchmark, the results are:


Comparing new vs. old

sys.modules : 331,097 vs. 383,180 (86.407694%)
Built-in module : 14,906 vs. 33,071 (45.072722%)
Source writing bytecode: small : 1,244 vs. 2,128 (58.458647%)
Source w/o bytecode: small : 2,420 vs. 4,784 (50.585284%)
Source w/ bytecode: small : 2,757 vs. 5,221 (52.805976%)
Source writing bytecode: tabnanny : 129 vs. 133 (96.992481%)
Source w/o bytecode: tabnanny : 144 vs. 147 (97.959184%)
Source w/ bytecode: tabnanny : 1,004 vs. 1,120 (89.642857%)
Source writing bytecode: decimal : 9 vs. 9 (100.000000%)
Source w/o bytecode: decimal : 9 vs. 9 (100.000000%)
Source w/ bytecode: decimal : 96 vs. 98 (97.959184%)


Where does that leave us? Well, obviously on medium-sized modules and up, the I/O involved along with parsing and execution outweighs importlib's costs to the point of being negligible. sys.modules is also now fast enough (I don't care what people say; being able to import from sys.modules at 0.0026 ms vs. 0.003 ms is not important in the grand scheme of things).

Built-in modules and such could be faster, but (a) there are only so many and they end up in sys.modules quickly anyway, and (b) even at their current speed they are still fast. So the real hold-up is small modules and whether they matter. The tabnanny benchmark is the median size of the stdlib, so half of modules will see no slowdown while half will see something of some level.

The most critical thing is to not use _gcd_import() in situations where the import function is currently passed in but instead use builtins.__import__() so as to get any C speed-ups (which I measured to make sure there are in all cases). After that I think unrolling the mentioned functions would help speed things up, but otherwise it becomes time to profile the Python code to see where the inefficiencies lie.

Some more C unrolling could be done. The situation of not fromlist could be written in C. Both _calc___packages__() and _resolve_name() could probably be written in C if someone cared.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Fri Feb 24 02:35:27 2012
From: report at bugs.python.org (Larry A. Taylor)
Date: Fri, 24 Feb 2012 01:35:27 +0000
Subject: [issue14105] Breakpoints in debug lost if line is inserted; IDLE
Message-ID: <1330047327.02.0.291761854329.issue14105@psf.upfronthosting.co.za>


New submission from Larry A. Taylor <larry.taylor at bankofamerica.com>:

My environment is Windows XP, using IDLE and Python 2.7 distribution.

Open an IDLE Python shell. Open the file with three lines in it, 1,2 and 3.

In IDLE, Set Breakpoint on Line 2.

In Shell, set Debug.

In IDLE, select run. 

In the Debug window, click Go.

Run stops at line 2, displayed in Debug. Click Quit.

Edit the file, inserting a line 0, like: print "this is line 0". Save the file

Run again, Go in Debug. 

The breakpoint has disappeared and the debugger does not stop on line 2 (now the third line). It doesn't stop anywhere.

Delete line 0, and set breakpoint on line 2 again. At the end of the file, insert a line 4, such as: print "this is line 4".

Run again, Go in Debug.

The breakpoint is preserved, and the debugger stops at line 2.

This is inconsistent behavior. I expect that a breakpoint will not disappear, and that it will always point to the same line, moving down when the line moves down. The breakpoint should move up if the line it refers to moves up.

----------
components: IDLE, Windows
files: debug-line-numbers.py
messages: 154104
nosy: ltaylor934
priority: normal
severity: normal
status: open
title: Breakpoints in debug lost if line is inserted; IDLE
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file24621/debug-line-numbers.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14105>
_______________________________________

From report at bugs.python.org  Fri Feb 24 02:40:53 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Feb 2012 01:40:53 +0000
Subject: [issue10722] IDLE's subprocess didnit make connection ..... Python 2.7
In-Reply-To: <1292541211.42.0.50542503549.issue10722@psf.upfronthosting.co.za>
Message-ID: <1330047653.67.0.620454359231.issue10722@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Some changes have been made to the subprocess connection code since my last message here. I believe they occurred after the last releases. There should be new 2.7.3 and 3.2.3 releases in about a month, after PyCon. Larry, if you can semi-deterministically make the problem happen, please try 3.2 also. I believe the IDLE code is the same for both 2.7 and 3.2, but I have no idea about the subprocess code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10722>
_______________________________________

From report at bugs.python.org  Fri Feb 24 03:18:34 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Feb 2012 02:18:34 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1330049914.63.0.852123617701.issue2377@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So I finished rewriting _return_module() so that if fromlist is not defined then it's all in C (and subsequently naming the function _handle_fromlist()).

That leaves rewriting in C _calc___package__() and _resolve_name(). After that I don't think there is anything left to do in C for __import__() itself (beyond maybe some reorganizing to avoid stupid things).

After that the only thing I can think of writing in C would be BuiltinImporter (and FrozenImporter if someone truly cared).

And once all that is said and done, that only leaves optimizing the Python code to try to appease the performance gods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Fri Feb 24 05:10:02 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Feb 2012 04:10:02 +0000
Subject: [issue1659] Tests needing network flag?
In-Reply-To: <18281.12938.264352.782990@montanaro.dyndns.org>
Message-ID: <1330056602.81.0.296953997277.issue1659@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

All tests now use regrtest resources and/or unittest skips and/or test.support.transient_internet.  I ran the faulty tests mentioned in this report while disconnected and got no failure, only skips.  Closing as duplicate/out of date.

----------
nosy: +eric.araujo
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1659>
_______________________________________

From report at bugs.python.org  Fri Feb 24 05:36:10 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Feb 2012 04:36:10 +0000
Subject: [issue14088] sys.executable generating canonical path
In-Reply-To: <1329928617.24.0.609517948319.issue14088@psf.upfronthosting.co.za>
Message-ID: <1330058170.47.0.297534639706.issue14088@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I wonder if the doc for sys.executable should mention that .. segments may be present.

----------
nosy: +eric.araujo, petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14088>
_______________________________________

From report at bugs.python.org  Fri Feb 24 05:39:05 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Feb 2012 04:39:05 +0000
Subject: [issue14100] Add a missing info to PEP 393 + link from whatsnew 3.3
In-Reply-To: <1330009090.66.0.133471342458.issue14100@psf.upfronthosting.co.za>
Message-ID: <1330058345.81.0.480736464064.issue14100@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Agreed with Antoine.  If you want, you can make a patch for the PEPs repo with the info requested by the XXX note, then a patch to replace that note by a link to the PEP, unless Martin wanted to do that himself.

----------
nosy: +eric.araujo
title: expose a hidden note -> Add a missing info to PEP 393 + link from whatsnew 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14100>
_______________________________________

From report at bugs.python.org  Fri Feb 24 05:42:11 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Feb 2012 04:42:11 +0000
Subject: [issue14099] ZipFile.open() should not reopen the underlying file
In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za>
Message-ID: <1330058531.47.0.817756756859.issue14099@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report and patch.  I?m afraid changing the constructor signature is not an option, due to our backward compatibility policy.  Do you think the bug can be fixed without changing the signature, or with new arguments added after the existing ones?

----------
nosy: +alanmcintyre, eric.araujo
stage:  -> patch review
title: zipfile: ZipFile.open() should not reopen the underlying file -> ZipFile.open() should not reopen the underlying file
type: resource usage -> behavior
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14099>
_______________________________________

From report at bugs.python.org  Fri Feb 24 05:43:26 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Feb 2012 04:43:26 +0000
Subject: [issue14101] example function in tertools.count docstring is
	misindented
In-Reply-To: <1330027633.46.0.670191761588.issue14101@psf.upfronthosting.co.za>
Message-ID: <1330058606.81.0.779648873521.issue14101@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch LGTM.  Raymond, any objection?

----------
components: +Extension Modules -Documentation, Library (Lib)
nosy: +eric.araujo, rhettinger
stage:  -> patch review
title: example function in tertools.count is misindented -> example function in tertools.count docstring is misindented
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14101>
_______________________________________

From report at bugs.python.org  Fri Feb 24 05:50:59 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Feb 2012 04:50:59 +0000
Subject: [issue14102] argparse: add ability to create a man page
In-Reply-To: <1330031760.56.0.8938390885.issue14102@psf.upfronthosting.co.za>
Message-ID: <1330059059.85.0.142135036391.issue14102@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Are you aware of help2man?  It can transmogrify the output of ?your-program-that-uses-argparse --help? to a man page.  Another solution is to use docutils? rst2man to convert some documentation file to the man format.

On the other hand, this blog post contains code implementing a custom optparse formatter for man pages, which could probably be adapted for argparse easily, so it does not look hard to implement.  (Note that the code has no licensing information.)

Steven, what do you think?  Too specialized for the stdlib or small, useful new feature?

----------
components: +Library (Lib) -None
nosy: +bethard, eric.araujo
title: argparser should create a man page for me. -> argparse: add ability to create a man page
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14102>
_______________________________________

From report at bugs.python.org  Fri Feb 24 05:51:23 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Feb 2012 04:51:23 +0000
Subject: [issue14102] argparse: add ability to create a man page
In-Reply-To: <1330031760.56.0.8938390885.issue14102@psf.upfronthosting.co.za>
Message-ID: <1330059083.93.0.990347024165.issue14102@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Forgot the link to the blog post: https://andialbrecht.wordpress.com/2009/03/17/creating-a-man-page-with-distutils-and-optparse/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14102>
_______________________________________

From report at bugs.python.org  Fri Feb 24 06:01:20 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Feb 2012 05:01:20 +0000
Subject: [issue14103] argparse: add ability to create a bash_completion script
In-Reply-To: <1330031882.01.0.825351616002.issue14103@psf.upfronthosting.co.za>
Message-ID: <1330059680.54.0.98320958016.issue14103@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

There is a module that implements this for optparse: <https://hg.furius.ca/public/optcomplete/>; I contacted the author when argparse was moved to the standard library and he told me that he would like to support argparse but had to time to code it.

optcomplete is 451 physical lines long, and 211 single logical lines long (courtesy of the sloccount program).  Maybe it would be smaller after being adapted to argparse, but that?s still a large chunk of code to add, and my feeling is that it would not serve a large enough part of our users.  For example, many people use zsh, which has a wholly different completion system.  I?m also given to understand that some people use Windows.

The decision is Steven?s call, as argparse maintainer, but in my opinion the best course would be to update optcomplete to work with argparse, publish it on PyPI, collect feedback and download statistics, and if it proves solid and widely used, reconsider it for stdlib inclusion.

----------
nosy: +bethard, eric.araujo
title: argparser should create a bash_completion script for me. -> argparse: add ability to create a bash_completion script
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14103>
_______________________________________

From report at bugs.python.org  Fri Feb 24 06:04:14 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 24 Feb 2012 05:04:14 +0000
Subject: [issue14103] argparse: add ability to create a bash_completion script
In-Reply-To: <1330031882.01.0.825351616002.issue14103@psf.upfronthosting.co.za>
Message-ID: <1330059854.14.0.585944552645.issue14103@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/issue14103>
_______________________________________

From report at bugs.python.org  Fri Feb 24 06:52:02 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Feb 2012 05:52:02 +0000
Subject: [issue1353344] python.desktop
Message-ID: <1330062722.6.0.974126767747.issue1353344@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Here?s a patch by Georg for the unix install machinery: http://mail.python.org/pipermail/python-dev/2006-July/067261.html

----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1353344>
_______________________________________

From report at bugs.python.org  Fri Feb 24 07:31:05 2012
From: report at bugs.python.org (Adam Venturella)
Date: Fri, 24 Feb 2012 06:31:05 +0000
Subject: [issue672115] Assignment to __bases__ of direct object subclasses
Message-ID: <1330065065.24.0.18396487475.issue672115@psf.upfronthosting.co.za>


Adam Venturella <aventurella at gmail.com> added the comment:

I too just found the same issue, dunno if it was settled on as being a bug per se. 

"class object(object): pass" 

Also worked for me. I don't feel great about doing that though. So I opted for more verbose name as not to collide with "object"

I have to wonder, since it's been 9 years, if all of us finding this issue are guilty of doing it wrong =)

----------
nosy: +aventurella

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue672115>
_______________________________________

From report at bugs.python.org  Fri Feb 24 08:00:46 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 24 Feb 2012 07:00:46 +0000
Subject: [issue14097] Improve the "introduction" page of the tutorial
In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>
Message-ID: <1330066846.32.0.484628336409.issue14097@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The attached patch addresses 8) -- you might want to use it as a starting point (that's what I was going to fix before deciding to do a full review of the page).

----------
assignee: rhettinger -> docs at python
keywords: +patch
Added file: http://bugs.python.org/file24622/issue14097.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14097>
_______________________________________

From report at bugs.python.org  Fri Feb 24 08:13:50 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 24 Feb 2012 07:13:50 +0000
Subject: [issue14097] Improve the "introduction" page of the tutorial
In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>
Message-ID: <1330067630.14.0.699634246853.issue14097@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14097>
_______________________________________

From report at bugs.python.org  Fri Feb 24 08:22:28 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Feb 2012 07:22:28 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1330068148.54.0.419872128605.issue6884@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for testing and confirming that this code never worked.  I am now confident that we?re about to fix once and for all this basket of bugs in the correct way.

I updated the tests to make them hopefully pass on Windows, and while doing that I realized that I don?t like the unnecessary escaping of / on posix systems.  Regexes already look like grit on my monitor, so I prefer not making them harder to read.  My latest patch only escapes if os.sep is the backslash.

Should apply cleanly to 2.7, please test.


> While we're talking about translate_pattern(), I have a question about this line:
> [snip]
> For example, it seems wrong that "recursive-include foo bar.*" matches foo/test_bar.py.
Certainly.  Feel free to open another report for that, or I?ll do it.

----------
resolution: accepted -> 
Added file: http://bugs.python.org/file24623/filelist-regex-bugs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Fri Feb 24 08:27:40 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Feb 2012 07:27:40 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1330068460.22.0.828162274416.issue6884@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Escalated to release blocker, as bugfix releases are about to go out of the door and I?d prefer they weren?t published with the buggy fixes committed for #13193.

----------
nosy: +benjamin.peterson, georg.brandl
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Fri Feb 24 08:48:13 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Feb 2012 07:48:13 +0000
Subject: [issue14061] Clean up archiving code in shutil
In-Reply-To: <1329705067.15.0.02936958618.issue14061@psf.upfronthosting.co.za>
Message-ID: <1330069693.37.0.507628867152.issue14061@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I intend to commit this simple fix for all branches:

-    _UNPACK_FORMATS['bztar'] = (['.bz2'], _unpack_tarfile, [],
+    _UNPACK_FORMATS['bztar'] = (['.tar.bz2'], _unpack_tarfile, [],

I could write a unit test, but it would be coupled to the exact text of the exception* (i.e. with assertRaisesRegex) and IMO not very useful.  I tested manually: I compressed a text file with bzip2, passed the filename to unpack_archive, and it tried to unpack it with tarfile.  With my fix, it does not try to unpack it.


* unpack_archive raises ValueError when you give an unsupported value to its format
  parameter, but when it?s in autodetect mode and can?t find an unpacker for the file
  extension, then it raises a ReadError.  Is it okay to change that to ValueError?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14061>
_______________________________________

From report at bugs.python.org  Fri Feb 24 09:31:40 2012
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 24 Feb 2012 08:31:40 +0000
Subject: [issue812369] module shutdown procedure based on GC
Message-ID: <1330072300.12.0.451797985807.issue812369@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

Obviously we run atexit code too.  There is no point in having atexit if it's not guaranteed to run in a normal shutdown.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue812369>
_______________________________________

From report at bugs.python.org  Fri Feb 24 09:48:43 2012
From: report at bugs.python.org (Stepan Kasal)
Date: Fri, 24 Feb 2012 08:48:43 +0000
Subject: [issue14099] ZipFile.open() should not reopen the underlying file
In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za>
Message-ID: <1330073323.07.0.751962255302.issue14099@psf.upfronthosting.co.za>


Stepan Kasal <kasal at ucw.cz> added the comment:

Attached please find a second iteration of the fix.
This time the signature of ZipExtFile is kept backward compatible, with one new parameter added.

----------
Added file: http://bugs.python.org/file24624/Proposed-fix-of-issue14099-second.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14099>
_______________________________________

From report at bugs.python.org  Fri Feb 24 10:23:07 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 24 Feb 2012 09:23:07 +0000
Subject: [issue14100] Add a missing info to PEP 393 + link from whatsnew 3.3
In-Reply-To: <1330009090.66.0.133471342458.issue14100@psf.upfronthosting.co.za>
Message-ID: <1330075387.21.0.0270703440277.issue14100@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'll look into this shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14100>
_______________________________________

From report at bugs.python.org  Fri Feb 24 10:53:05 2012
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 24 Feb 2012 09:53:05 +0000
Subject: [issue14102] argparse: add ability to create a man page
In-Reply-To: <1330031760.56.0.8938390885.issue14102@psf.upfronthosting.co.za>
Message-ID: <1330077185.36.0.911374332516.issue14102@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I think adding a new formatter for man pages would be generally useful. Assuming someone provides a patch. ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14102>
_______________________________________

From report at bugs.python.org  Fri Feb 24 10:56:32 2012
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 24 Feb 2012 09:56:32 +0000
Subject: [issue14103] argparse: add ability to create a bash_completion script
In-Reply-To: <1330031882.01.0.825351616002.issue14103@psf.upfronthosting.co.za>
Message-ID: <1330077392.7.0.718325240791.issue14103@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Yeah, the same issues have been discussed in Issue 4256. My feeling so far is that if there isn't "one true format" that argparse can produce and be useful to a wide variety of shells, then it's probably not functionality that belongs in Python core, and instead belongs on PyPI.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14103>
_______________________________________

From report at bugs.python.org  Fri Feb 24 10:57:53 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 24 Feb 2012 09:57:53 +0000
Subject: [issue13706] non-ascii fill characters no longer work in formatting
In-Reply-To: <1325630185.42.0.0487894537415.issue13706@psf.upfronthosting.co.za>
Message-ID: <1330077473.56.0.899361754604.issue13706@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

STINNER Victor <report at bugs.python.org> wrote:
> Your comment is incorrect, it was already failing before my commit ;-) Example at changeset 548a023c8230:

Ah, sorry about that. I was lazy and tested against 585d3664da89 (which is a
couple of weeks old).

That version didn't crash but produced UTF-8 output. :)

>>> format(0.1, 'n')
'0\xd9\xab1'


Now things look great, thanks for fixing all of that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13706>
_______________________________________

From report at bugs.python.org  Fri Feb 24 10:59:39 2012
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 24 Feb 2012 09:59:39 +0000
Subject: [issue4256] argparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1330077579.76.0.924851942829.issue4256@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

So it seems like what bash needs and what zsh needs are pretty different. My feeling so far is that if there isn't "one true format" that argparse can produce and be useful to a wide variety of shells, then it's probably not functionality that belongs in Python core, and instead belongs on PyPI.

So I guess my recommended next step would be to have someone offer help to the maintainer of http://pypi.python.org/pypi/optcomplete to update it to support argparse as well. If and when optcomplete supports argparse, bash, zsh and whatever other common shells people are using, and when optcomplete has significant usage in the field, then we can consider integrating it into the Python stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Fri Feb 24 11:11:58 2012
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 24 Feb 2012 10:11:58 +0000
Subject: [issue13909] Ordering of free variables in dis is dependent on dict
	ordering.
In-Reply-To: <1327879534.06.0.507724097117.issue13909@psf.upfronthosting.co.za>
Message-ID: <1330078318.36.0.404743201645.issue13909@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

Fixed by revisions 224ebf9d428a and 38828f0c9312

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13909>
_______________________________________

From report at bugs.python.org  Fri Feb 24 11:31:01 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 24 Feb 2012 10:31:01 +0000
Subject: [issue14081] Allow "maxsplit" argument to str.split() to be passed as
	a keyword argument
In-Reply-To: <1329875650.41.0.375574316124.issue14081@psf.upfronthosting.co.za>
Message-ID: <1330079461.06.0.514540154312.issue14081@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

New patch that changes .rsplit() too and updates docs and docstrings.

----------
Added file: http://bugs.python.org/file24625/issue14081-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14081>
_______________________________________

From report at bugs.python.org  Fri Feb 24 11:31:39 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 24 Feb 2012 10:31:39 +0000
Subject: [issue13909] Ordering of free variables in dis is dependent on dict
	ordering.
In-Reply-To: <1327879534.06.0.507724097117.issue13909@psf.upfronthosting.co.za>
Message-ID: <1330079499.21.0.713154951904.issue13909@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage: test needed -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13909>
_______________________________________

From report at bugs.python.org  Fri Feb 24 11:44:19 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 24 Feb 2012 10:44:19 +0000
Subject: [issue13973] urllib.parse is imported twice in xmlrpc.client
In-Reply-To: <1328775757.49.0.00418569487883.issue13973@psf.upfronthosting.co.za>
Message-ID: <E1S0sdN-0006TE-Fi@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a3e8f8d10dce by Ezio Melotti in branch 'default':
#13973: move a couple of imports at module level.  Patch by Tshepang Lekhonkhobe.
http://hg.python.org/cpython/rev/a3e8f8d10dce

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13973>
_______________________________________

From report at bugs.python.org  Fri Feb 24 11:45:08 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 24 Feb 2012 10:45:08 +0000
Subject: [issue13973] urllib.parse is imported twice in xmlrpc.client
In-Reply-To: <1328775757.49.0.00418569487883.issue13973@psf.upfronthosting.co.za>
Message-ID: <1330080308.33.0.954222819545.issue13973@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report and the patch.

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13973>
_______________________________________

From report at bugs.python.org  Fri Feb 24 11:46:16 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 24 Feb 2012 10:46:16 +0000
Subject: [issue8077] cgi handling of POSTed files is broken
In-Reply-To: <1267839820.97.0.586792235494.issue8077@psf.upfronthosting.co.za>
Message-ID: <1330080376.19.0.2011884469.issue8077@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> test needed
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8077>
_______________________________________

From report at bugs.python.org  Fri Feb 24 11:47:50 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 24 Feb 2012 10:47:50 +0000
Subject: [issue1112955] move_file()'s return value when dry_run=1 unclear
Message-ID: <1330080470.08.0.55956951709.issue1112955@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1112955>
_______________________________________

From report at bugs.python.org  Fri Feb 24 11:52:07 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 24 Feb 2012 10:52:07 +0000
Subject: [issue10131] deepcopying an xml.dom.minidom.Document generates an
	invalid XML document
In-Reply-To: <1287322940.78.0.0838139062813.issue10131@psf.upfronthosting.co.za>
Message-ID: <1330080727.83.0.694223553067.issue10131@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +eli.bendersky
stage: needs patch -> test needed
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10131>
_______________________________________

From report at bugs.python.org  Fri Feb 24 11:53:31 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 24 Feb 2012 10:53:31 +0000
Subject: [issue9262] IDLE: Use tabbed shell and edit windows
In-Reply-To: <1279128709.53.0.879340925848.issue9262@psf.upfronthosting.co.za>
Message-ID: <1330080811.86.0.74606418716.issue9262@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +patch
stage: needs patch -> patch review
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9262>
_______________________________________

From report at bugs.python.org  Fri Feb 24 11:54:36 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 24 Feb 2012 10:54:36 +0000
Subject: [issue12817] test_multiprocessing: io.BytesIO() requires bytearray
	buffers
In-Reply-To: <1314011611.8.0.941911218938.issue12817@psf.upfronthosting.co.za>
Message-ID: <1330080876.07.0.00824491840629.issue12817@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12817>
_______________________________________

From report at bugs.python.org  Fri Feb 24 12:04:59 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 24 Feb 2012 11:04:59 +0000
Subject: [issue1531415] parsetok.c emits warnings by writing to stderr
Message-ID: <1330081499.67.0.196025805085.issue1531415@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1531415>
_______________________________________

From report at bugs.python.org  Fri Feb 24 12:05:52 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 24 Feb 2012 11:05:52 +0000
Subject: [issue1116520] Prefix search is filesystem-centric
Message-ID: <1330081552.64.0.519604470327.issue1116520@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1116520>
_______________________________________

From report at bugs.python.org  Fri Feb 24 12:07:56 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 24 Feb 2012 11:07:56 +0000
Subject: [issue9056] Adding additional level of bookmarks and section numbers
	in python pdf documents.
In-Reply-To: <1277175637.31.0.472126376822.issue9056@psf.upfronthosting.co.za>
Message-ID: <1330081676.36.0.165842207392.issue9056@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> needs patch
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9056>
_______________________________________

From report at bugs.python.org  Fri Feb 24 12:12:56 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 24 Feb 2012 11:12:56 +0000
Subject: [issue12817] test_multiprocessing: io.BytesIO() requires bytearray
	buffers
In-Reply-To: <1314011611.8.0.941911218938.issue12817@psf.upfronthosting.co.za>
Message-ID: <1330081976.55.0.392146651383.issue12817@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The current interpretation in the PEP-3118 repo is that a request
without PyBUF_FORMAT means "implicit cast to unsigned bytes".

This makes the behavior of PyObject_AsWriteBuffer() correct, so I'm
closing this.

----------
resolution:  -> invalid
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12817>
_______________________________________

From report at bugs.python.org  Fri Feb 24 12:22:28 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 24 Feb 2012 11:22:28 +0000
Subject: [issue14061] Clean up archiving code in shutil
In-Reply-To: <1329705067.15.0.02936958618.issue14061@psf.upfronthosting.co.za>
Message-ID: <1330082548.06.0.495043369942.issue14061@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

I don't think there's any harm in testing that the exception message for
a .bz2 file contains the string "unknown archive format". It's unlikely
that we'll want to completely change the error message in future, and if
we do, it will be pretty easy and obvious to fix.


> * unpack_archive raises ValueError when you give an unsupported value to its format
>  parameter, but when it?s in autodetect mode and can?t find an unpacker for the file
>  extension, then it raises a ReadError.  Is it okay to change that to ValueError?

Sounds fine by me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14061>
_______________________________________

From report at bugs.python.org  Fri Feb 24 14:06:01 2012
From: report at bugs.python.org (wmg)
Date: Fri, 24 Feb 2012 13:06:01 +0000
Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes
	lag
In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za>
Message-ID: <1330088761.32.0.226700256438.issue6085@psf.upfronthosting.co.za>


Changes by wmg <wmgaca at gmail.com>:


----------
nosy: +wmgaca

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6085>
_______________________________________

From report at bugs.python.org  Fri Feb 24 14:26:56 2012
From: report at bugs.python.org (sbt)
Date: Fri, 24 Feb 2012 13:26:56 +0000
Subject: [issue14087] multiprocessing.Condition.wait_for missing
In-Reply-To: <1329922885.58.0.881756065062.issue14087@psf.upfronthosting.co.za>
Message-ID: <1330090016.89.0.0238332591266.issue14087@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> Shouldn't the `for` loop be outside the outer `with` block?

Yes.

> In Lib/multiprocessing/managers.py:
> Is there a good reason why the wait_for() proxy method can't simply be
> implemented as:
> return self._callmethod('wait_for', (predicate, timeout))?
> 
> (There may be, I just didn't check).

That would only work if predicate is picklable, which is unlikely to be the case.  (The lambda functions used in the unit tests are not picklable.)

> Finally, the documentation should be updated 
> (Doc/library/multiprocessing.rst).

Fixed in new patch.

> Otherwise, it would probably be better if you could submit a contributor 
> agreement (and also maybe update your name on the tracker), unless that's
> a problem for you?

I will try to submit it over the weekend.

----------
Added file: http://bugs.python.org/file24626/cond_wait_for.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14087>
_______________________________________

From report at bugs.python.org  Fri Feb 24 14:41:45 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 24 Feb 2012 13:41:45 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1330090905.77.0.325727368844.issue6884@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

There were bugs in two of the updated tests:

- test_glob_to_re() was doing two levels of escaping (r'\' -> r'\\\\')
  for its expected output when it should only do one (r'\' -> r'\\').

- test_process_template() was not converting some of its expected
  results to use the native directory separator.

I've attached a patch that fixes these issues. I also took the liberty of
changing the checks for whether the separator needs to be escaped - it's
better to escape everything except "/", just in case someone decides to
port Python to some platform using a weird directory separator that is
neither "/" nor r"\".

With my updated patch, all tests pass on both Windows and Linux, and I've
also manually verified that the buildout.cfg problem and the
sandbox/dummy.py problem (from issue 9691) are both fixed.

Please review (and commit, if my changes are OK).

----------
Added file: http://bugs.python.org/file24627/filelist-regex-v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Fri Feb 24 15:46:35 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 24 Feb 2012 14:46:35 +0000
Subject: [issue14106] Distutils manifest: recursive-(include|exclude) matches
	suffix instead of full filename
Message-ID: <1330094795.44.0.467789061974.issue14106@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

As I understand it, a MANIFEST.in directive:

    recursive-include foo bar.*

is meant to match files under foo for with names beginning with "bar.".
However, the actual regex that is generated for this line is:

    r'^foo/.*bar\.[^/]*\Z(?ms)'

which matches any filename under foo that contains "bar." anywhere in the
base filename. For example, if foo contains files bar.py and test_bar.py,
then the pattern will match both filenames. Is this the intended
behaviour? I would have expected it to only match bar.py.

If the desired behavior is what I expected (and not how it currently
works), then the desired regex is:

    r'^foo/(.*/)?bar\.[^/]*\Z(?ms)'

The attached patch (against 2.7) implements this change. It is dependent
on the fix for issue 6884. I have tested it on both Linux and Windows.

----------
files: recursive-include.diff
keywords: patch
messages: 154137
nosy: eric.araujo, nadeem.vawda, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: Distutils manifest: recursive-(include|exclude) matches suffix instead of full filename
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24628/recursive-include.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14106>
_______________________________________

From report at bugs.python.org  Fri Feb 24 15:47:24 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 24 Feb 2012 14:47:24 +0000
Subject: [issue14106] Distutils manifest: recursive-(include|exclude) matches
	suffix instead of full filename
In-Reply-To: <1330094795.44.0.467789061974.issue14106@psf.upfronthosting.co.za>
Message-ID: <1330094844.25.0.492893202659.issue14106@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
dependencies: +Impossible to include file in sdist that starts with 'build' on Win32
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14106>
_______________________________________

From report at bugs.python.org  Fri Feb 24 16:03:51 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 24 Feb 2012 15:03:51 +0000
Subject: [issue5438] test_bigmem.test_from_2G_generator uses more memory than
	expected
In-Reply-To: <1236475515.92.0.849329057425.issue5438@psf.upfronthosting.co.za>
Message-ID: <1330095831.75.0.94176341264.issue5438@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5438>
_______________________________________

From report at bugs.python.org  Fri Feb 24 16:16:21 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 24 Feb 2012 15:16:21 +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: <1330096581.52.0.540669768154.issue10181@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Thanks, Nick. I'll try to get it done this weekend.

I've uploaded Misc/NEWS and Doc/whatsnew/3.3.rst (my apologies to Antoine 
for plagiarizing the first sentence, I found it hard to come up with a 
better version).

I wasn't sure whether to put the "whatsnew" entry into the section
"Other Language Changes" or into the PEP section. I chose the latter,
since many new features have been added that are part of the PEP.

----------
Added file: http://bugs.python.org/file24629/issue10181-news.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Fri Feb 24 16:17:26 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 24 Feb 2012 15:17:26 +0000
Subject: [issue14107] Debian bigmem buildbot hanging in test_bigmem
Message-ID: <1330096646.48.0.414006184823.issue14107@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

On the debian bigmem  buildbot, test_bigmem hangs until it gets killed
by a timeout:

    http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/134/steps/test/logs/stdio
    http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/131/steps/test/logs/stdio
    http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/129/steps/test/logs/stdio
    http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/128/steps/test/logs/stdio
    http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/123/steps/test/logs/stdio
    http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/85/steps/test/logs/stdio

This has happened on every run I've checked that hasn't crashed before
reaching test_bigmem for some other reason (e.g. the recently-fixed zlib
bus error), as far back as the buildbot history goes.

Issue 5438 might be related.

----------
components: Tests
keywords: buildbot
messages: 154139
nosy: loewis, nadeem.vawda, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Debian bigmem buildbot hanging in test_bigmem
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14107>
_______________________________________

From report at bugs.python.org  Fri Feb 24 16:56:44 2012
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Fri, 24 Feb 2012 15:56:44 +0000
Subject: [issue14089] Patch to increase fractions lib test coverage
In-Reply-To: <1329934239.36.0.224119101932.issue14089@psf.upfronthosting.co.za>
Message-ID: <1330099004.14.0.9230308835.issue14089@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


Removed file: http://bugs.python.org/file24605/test_fractions.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14089>
_______________________________________

From report at bugs.python.org  Fri Feb 24 16:57:03 2012
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Fri, 24 Feb 2012 15:57:03 +0000
Subject: [issue14089] Patch to increase fractions lib test coverage
In-Reply-To: <1329934239.36.0.224119101932.issue14089@psf.upfronthosting.co.za>
Message-ID: <1330099023.86.0.379714861562.issue14089@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


Added file: http://bugs.python.org/file24630/test_fractions.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14089>
_______________________________________

From report at bugs.python.org  Fri Feb 24 16:59:11 2012
From: report at bugs.python.org (Meador Inge)
Date: Fri, 24 Feb 2012 15:59:11 +0000
Subject: [issue14095] type_new() removes __qualname__ from the input dictionary
In-Reply-To: <1329956865.57.0.697177106628.issue14095@psf.upfronthosting.co.za>
Message-ID: <1330099151.98.0.40027983947.issue14095@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

The change in error handling makes this a bit harder to review, but it otherwise looks OK if this is the intended behavior.  I am not sure that it is.

The original version:

   1. If __qualname__ was present in the original dictionary,
      then it was deleted.
   2. If __qualname__ was present in the original dictionary,
      then the qualname slot in the new type was left unitialized.

Why (1) was done I don't know.  (2) is obviously a bug.

The patched version:

   1. Sets the slot qualname to the __qualname__ from the original
      dictionary (if present).
   2. Copies the __qualname__ attribute from the original dictionary
      to the new dictionary (if present).
   3. Leaves the original dictionary alone.

The deletion and unitiliazed slot problems are gone, but I am not sure if (2) is needed.  Just fixing (1) and (3) seems more reasonable to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14095>
_______________________________________

From report at bugs.python.org  Fri Feb 24 17:05:25 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 24 Feb 2012 16:05:25 +0000
Subject: [issue14081] Allow "maxsplit" argument to str.split() to be passed as
	a keyword argument
In-Reply-To: <1329875650.41.0.375574316124.issue14081@psf.upfronthosting.co.za>
Message-ID: <1330099525.21.0.690863002559.issue14081@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14081>
_______________________________________

From report at bugs.python.org  Fri Feb 24 18:25:46 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 24 Feb 2012 17:25:46 +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: <1330104346.67.0.33461489946.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

PEP section makes sense - I plan to mark PEP 3118 as Final once you commit this (or you can do that yourself, for that matter).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Fri Feb 24 18:51:44 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 24 Feb 2012 17:51:44 +0000
Subject: [issue14103] argparse: add ability to create a bash_completion script
In-Reply-To: <1330031882.01.0.825351616002.issue14103@psf.upfronthosting.co.za>
Message-ID: <1330105904.63.0.163464537006.issue14103@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14103>
_______________________________________

From report at bugs.python.org  Fri Feb 24 19:04:54 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 24 Feb 2012 18:04:54 +0000
Subject: [issue14102] argparse: add ability to create a man page
In-Reply-To: <1330031760.56.0.8938390885.issue14102@psf.upfronthosting.co.za>
Message-ID: <1330106694.29.0.338949266265.issue14102@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14102>
_______________________________________

From report at bugs.python.org  Fri Feb 24 19:07:25 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 24 Feb 2012 18:07:25 +0000
Subject: [issue14108] test_shutil: failures in symlink tests
Message-ID: <1330106845.06.0.919301753215.issue14108@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

These two tests fail on Windows 7:

======================================================================                                      
FAIL: test_copymode_follow_symlinks (test.test_shutil.TestShutil)                                           
----------------------------------------------------------------------                                      
Traceback (most recent call last):                                                                          
  File "C:\Users\stefan\hg\master\lib\test\test_shutil.py", line 194, in test_copymode_follow_symlinks      
    self.assertEqual(os.stat(src).st_mode, os.stat(dst).st_mode)                                            
AssertionError: 33206 != 33060                                                                              
                                                                                                            
======================================================================                                      
FAIL: test_move_dangling_symlink (test.test_shutil.TestMove)                                                
----------------------------------------------------------------------                                      
Traceback (most recent call last):                                                                          
  File "C:\Users\stefan\hg\master\lib\test\test_shutil.py", line 59, in wrap                                
    return func(*args, **kwargs)                                                                            
  File "C:\Users\stefan\hg\master\lib\test\test_shutil.py", line 1137, in test_move_dangling_symlink        
    self.assertEqual(os.path.realpath(src), os.path.realpath(dst_link))                                     
AssertionError: 'c:\\users\\stefan\\appdata\\local\\temp\\tmp7a4jc3\\baz' != 'c:\\users\\stefan\\appdata\\lo
cal\\temp\\tmp9ucl3b\\quux'                                                                                 
- c:\users\stefan\appdata\local\temp\tmp7a4jc3\baz                                                          
?                                       ^^^^   ^^^                                                          
+ c:\users\stefan\appdata\local\temp\tmp9ucl3b\quux                                                         
?                                       ^^ + + ^^^^

----------
components: Tests
messages: 154142
nosy: skrah
priority: normal
severity: normal
status: open
title: test_shutil: failures in symlink tests
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14108>
_______________________________________

From report at bugs.python.org  Fri Feb 24 19:15:53 2012
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 24 Feb 2012 18:15:53 +0000
Subject: [issue14108] test_shutil: failures in symlink tests
In-Reply-To: <1330106845.06.0.919301753215.issue14108@psf.upfronthosting.co.za>
Message-ID: <1330107353.01.0.167026740967.issue14108@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14108>
_______________________________________

From report at bugs.python.org  Fri Feb 24 19:18:28 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 24 Feb 2012 18:18:28 +0000
Subject: [issue14108] test_shutil: failures in symlink tests
In-Reply-To: <1330106845.06.0.919301753215.issue14108@psf.upfronthosting.co.za>
Message-ID: <1330107508.53.0.823422794875.issue14108@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +eric.araujo, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14108>
_______________________________________

From report at bugs.python.org  Fri Feb 24 19:29:27 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Feb 2012 18:29:27 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1330108167.3.0.42277165928.issue2377@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, I have now done as much C code as I'm going to do for the __import__() function. It has gotten bootstrapped importlib within 10% of normal_startup against default.

That leaves (possibly) rewriting BuiltinImporter in C and then just good old fashioned optimizations of the Python code.

I'm going to continue to use the normal_startup benchmark as my gold standard benchmark and importlib.test.benchmark just for iterative testing that a change made an impact (until there is another Python 3 benchmark that measures startup time using a real-world app). With that in mind and taking a PyPy style approach, that means I should focus on top-level, non-package imports first (28 of them), followed by builtins (14), submodules (4), packages (2), and then extensions (2). And if you don't want to do the math, there are 50 imports when starting Python, of which only 9 seem to follow (and include) site.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Fri Feb 24 19:30:16 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 24 Feb 2012 18:30:16 +0000
Subject: [issue14109] test_lib2to3: failure on Windows 7
Message-ID: <1330108216.18.0.0457510512891.issue14109@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

This failure occurs on the Windows 7 buildbot:

[302/364] test_lib2to3
--- D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\lib2to3\tests\test_main.py	2012-02-13 21:57:29.273004000 -0500
+++ @	2012-02-24 11:59:54.408966500 -0500
@@ -42,7 +42,7 @@
             sys.stderr = save_stderr
 
     def test_unencodable_diff(self):
-        input_stream = io.StringIO("print 'nothing'\nprint u'?ber'\n")
+        input_stream = io.StringIO("print 'nothing'\nprint u'?ber'\n")
         out = io.BytesIO()
         out_enc = codecs.getwriter("ascii")(out)
         err = io.StringIO()

----------
components: Tests
messages: 154144
nosy: benjamin.peterson, skrah
priority: normal
severity: normal
status: open
title: test_lib2to3: failure on Windows 7
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14109>
_______________________________________

From report at bugs.python.org  Fri Feb 24 19:32:40 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Feb 2012 18:32:40 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1330108360.17.0.793281213971.issue2377@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Are you looking for reviews at this point?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Fri Feb 24 19:40:59 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 24 Feb 2012 18:40:59 +0000
Subject: [issue14109] test_lib2to3: output that looks like a failure on
	Windows 7
In-Reply-To: <1330108216.18.0.0457510512891.issue14109@psf.upfronthosting.co.za>
Message-ID: <1330108859.5.0.966663825609.issue14109@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Oops, this is just undesirable output. Is there any chance to fix
this?

----------
title: test_lib2to3: failure on Windows 7 -> test_lib2to3: output that looks like a failure on Windows 7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14109>
_______________________________________

From report at bugs.python.org  Fri Feb 24 19:42:35 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 24 Feb 2012 18:42:35 +0000
Subject: [issue14109] test_lib2to3: output that looks like a failure on
	Windows 7
In-Reply-To: <1330108216.18.0.0457510512891.issue14109@psf.upfronthosting.co.za>
Message-ID: <1330108955.53.0.927927847037.issue14109@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Yes, though, it's not high priority atm.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14109>
_______________________________________

From report at bugs.python.org  Fri Feb 24 20:05:31 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 24 Feb 2012 19:05:31 +0000
Subject: [issue14109] test_lib2to3: output that looks like a failure on
	Windows 7
In-Reply-To: <1330108216.18.0.0457510512891.issue14109@psf.upfronthosting.co.za>
Message-ID: <1330110331.2.0.0737290049622.issue14109@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14109>
_______________________________________

From report at bugs.python.org  Fri Feb 24 20:24:35 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 24 Feb 2012 19:24:35 +0000
Subject: [issue14110] FreeBSD: test_os fails if user is in the wheel group
Message-ID: <1330111475.14.0.550886598364.issue14110@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

On FreeBSD, if the user is a member of the group 'wheel', these
tests fail:


======================================================================
FAIL: test_setegid (test.test_os.PosixUidGidTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/stefan/hg/cpython/Lib/test/test_os.py", line 1090, in test_setegid
    self.assertRaises(os.error, os.setegid, 0)
AssertionError: OSError not raised by setegid

======================================================================
FAIL: test_setgid (test.test_os.PosixUidGidTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/stefan/hg/cpython/Lib/test/test_os.py", line 1078, in test_setgid
    self.assertRaises(os.error, os.setgid, 0)
AssertionError: OSError not raised by setgid

======================================================================
FAIL: test_setregid (test.test_os.PosixUidGidTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/stefan/hg/cpython/Lib/test/test_os.py", line 1110, in test_setregid
    self.assertRaises(os.error, os.setregid, 0, 0)
AssertionError: OSError not raised by setregid

----------
components: Tests
messages: 154148
nosy: skrah
priority: low
severity: normal
status: open
title: FreeBSD: test_os fails if user is in the wheel group
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14110>
_______________________________________

From report at bugs.python.org  Fri Feb 24 20:24:42 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Feb 2012 19:24:42 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1330108360.17.0.793281213971.issue2377@psf.upfronthosting.co.za>
Message-ID: <1330111267.3435.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, compilation fails here:

Python/import.c: In function ?PyImport_ImportModuleLevelObject?:
Python/import.c:2956:9: erreur: ?for? loop initial declarations are only
allowed in C99 mode
Python/import.c:2956:9: note: use option -std=c99 or -std=gnu99 to
compile your code
make: *** [Python/import.o] Erreur 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Fri Feb 24 20:47:19 2012
From: report at bugs.python.org (Larry A. Taylor)
Date: Fri, 24 Feb 2012 19:47:19 +0000
Subject: [issue14111] IDLE Debugger should handle interrupts
Message-ID: <1330112839.68.0.0096879566667.issue14111@psf.upfronthosting.co.za>


New submission from Larry A. Taylor <larry.taylor at bankofamerica.com>:

The attached script runs a long processing loop.

Start it in IDLE. Open the script and run it.

Press control-C. Result: message, KeyboardInterrupt with traceback message.

In shell window, turn on Debugger. Run the script.

Press control-C. Result: Restrat message shown in Python Shell. Debug Control shows no change.

Expected behavior: For keyboard interrupt, or for any uncaught exception, Debug Control should show the same information as if there was a breakpoint. For instance, the stack with line numbers, locals and globals.

Better: make a way to interrupt the program in a long loop or process, so that the programmer can tell -- live -- where the program is, and where most of the time is being used. Then use the regular buttons, Go, etc. to continue the process, possibly interrupted again.

Also: the IDLE Python Shell and Debug Control show no "running" indicator, so there is no easy way to tell if the program is still going.

----------
components: IDLE, Windows
files: debug-running-or-stopped.py
messages: 154150
nosy: ltaylor934
priority: normal
severity: normal
status: open
title: IDLE Debugger should handle interrupts
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file24631/debug-running-or-stopped.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14111>
_______________________________________

From report at bugs.python.org  Fri Feb 24 20:50:05 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 24 Feb 2012 19:50:05 +0000
Subject: [issue14112] tutorial intro talks of "shallow copy" concept without
	explanation
Message-ID: <1330113005.05.0.0872009811322.issue14112@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

Relevant line: http://hg.python.org/cpython/file/e2eccc906354/Doc/tutorial/introduction.rst#l487

When the concept is introduced, it appears like there's an assumption that the reader would know what it means. I'm curious if it's that common a term that it should be taken for granted, or if it deserves a definition.

----------
assignee: docs at python
components: Documentation
messages: 154151
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: tutorial intro talks of "shallow copy" concept without explanation
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14112>
_______________________________________

From report at bugs.python.org  Fri Feb 24 20:58:49 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 24 Feb 2012 19:58:49 +0000
Subject: [issue14097] Improve the "introduction" page of the tutorial
In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>
Message-ID: <1330113529.33.0.915593954155.issue14097@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14097>
_______________________________________

From report at bugs.python.org  Fri Feb 24 21:05:50 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Feb 2012 20:05:50 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1330113950.67.0.990820900422.issue2377@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Fixed the 'for' loop variable declaration. Surprised clang didn't warn me about that.

As for reviews, I'm totally happy to get them, but I also don't know if I have hit the performance point well enough for people to allow me to merge the code into default. I guess the real question is whether *you're* happy with the 10% slowdown in raw startup, Antoine, since you were the most vocal critic from a performance standpoint?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Fri Feb 24 21:10:45 2012
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 24 Feb 2012 20:10:45 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1330114245.26.0.905082129343.issue2377@psf.upfronthosting.co.za>


Changes by Alex Gaynor <alex.gaynor at gmail.com>:


----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Fri Feb 24 21:13:18 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 24 Feb 2012 20:13:18 +0000
Subject: [issue14113] Failure in test_strptime on Windows
Message-ID: <1330114398.55.0.713486121761.issue14113@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

Recent failures on one of the Windows XP buildbots:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6049/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6051/steps/test/logs/stdio

    FAIL: test_date_time (test.test_strptime.LocaleTime_Tests)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_strptime.py", line 91, in test_date_time
        "LC_date_time incorrect")
    AssertionError: False is not true : LC_date_time incorrect

----------
components: Tests, Windows
keywords: buildbot
messages: 154153
nosy: nadeem.vawda
priority: normal
severity: normal
stage: needs patch
status: open
title: Failure in test_strptime on Windows
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14113>
_______________________________________

From report at bugs.python.org  Fri Feb 24 21:15:30 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 24 Feb 2012 20:15:30 +0000
Subject: [issue14114] 2.7.3rc1 chm gives JS error
Message-ID: <1330114530.4.0.50026951866.issue14114@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

The 2.7.3rc1 chm give the following error when opened

Line: 1 Char: 1
The Value of the property "$" is null or undefined, not a function (translated from German)
Code: 0
URL: mk:@MSITStore:C:\Users\martin\27\python\Doc\build\htmlhelp\python273rc1.chm::/_static/copybutton.js

Clicking "yes" lets me proceed to the contents of the file.

----------
messages: 154154
nosy: loewis
priority: normal
severity: normal
status: open
title: 2.7.3rc1 chm gives JS error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14114>
_______________________________________

From report at bugs.python.org  Fri Feb 24 21:18:04 2012
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 24 Feb 2012 20:18:04 +0000
Subject: [issue14114] 2.7.3rc1 chm gives JS error
In-Reply-To: <1330114530.4.0.50026951866.issue14114@psf.upfronthosting.co.za>
Message-ID: <1330114684.63.0.499987458604.issue14114@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14114>
_______________________________________

From report at bugs.python.org  Fri Feb 24 21:26:24 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 24 Feb 2012 20:26:24 +0000
Subject: [issue14115] 2.7.3rc hangs on test_asynchat on 32-bit Windows
Message-ID: <1330115184.52.0.720295270361.issue14115@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

As the title says: test_asynchat appears to hang on Windows.

----------
messages: 154155
nosy: loewis
priority: normal
severity: normal
status: open
title: 2.7.3rc hangs on test_asynchat on 32-bit Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14115>
_______________________________________

From report at bugs.python.org  Fri Feb 24 21:30:09 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 24 Feb 2012 20:30:09 +0000
Subject: [issue14097] Improve the "introduction" page of the tutorial
In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>
Message-ID: <1330115409.43.0.974912214476.issue14097@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Ezio, your fix for 8 is definitely good. Space makes it cleaner, as well as compliant to PEP 8, which explicitly recommends to surround operators with spaces.

Note, however, that this should be applied in other places as well, not only the complex number samples. For example:

2+2
(50-5*6)/4

etc.

There's quite a bit of inconsistency in the samples. Some surround operators with spaces and some don't. I think converging on a single consistent, PEP 8 compliant convention of surrounding with spaces always throughout the tutorial is a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14097>
_______________________________________

From report at bugs.python.org  Fri Feb 24 21:33:20 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Feb 2012 20:33:20 +0000
Subject: [issue14115] 2.7.3rc hangs on test_asynchat on 32-bit Windows
In-Reply-To: <1330115184.52.0.720295270361.issue14115@psf.upfronthosting.co.za>
Message-ID: <1330115600.9.0.50582962494.issue14115@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +giampaolo.rodola
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14115>
_______________________________________

From report at bugs.python.org  Fri Feb 24 21:36:48 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Feb 2012 20:36:48 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1330113950.67.0.990820900422.issue2377@psf.upfronthosting.co.za>
Message-ID: <1330115594.3435.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> As for reviews, I'm totally happy to get them, but I also don't know
> if I have hit the performance point well enough for people to allow me
> to merge the code into default. I guess the real question is whether
> *you're* happy with the 10% slowdown in raw startup, Antoine, since
> you were the most vocal critic from a performance standpoint?

Well, it seems current performance is acceptable now :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Fri Feb 24 21:39:05 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Feb 2012 20:39:05 +0000
Subject: [issue14108] test_shutil: failures in symlink tests
In-Reply-To: <1330106845.06.0.919301753215.issue14108@psf.upfronthosting.co.za>
Message-ID: <1330115945.19.0.538594797494.issue14108@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's a duplicate of issue13837.

----------
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed
superseder:  -> test_shutil fails with symlinks enabled under Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14108>
_______________________________________

From report at bugs.python.org  Fri Feb 24 21:45:39 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 24 Feb 2012 20:45:39 +0000
Subject: [issue14097] Improve the "introduction" page of the tutorial
In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>
Message-ID: <1330116339.58.0.00811288041895.issue14097@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Comments on some of the suggestions:

1) Agreed
2) Can be combined with (3), I think. Just show the number example with the explanatory comments. They speak for themselves. No need for the SPAM and STRING assignments.
5) Yep. Can be replaced by "A value can be assigned to several variables in a single statement"
6) There's the tradeoff of rigor vs. simplicity here, since this is still a tutorial for beginners, right? What alternative would you propose?
7) Totally agree. I don't think complex numbers deserve more than a single trivial example and one sentence dedicated to them in the tutorial, if that...
8) Yes. See my previous message in this issue
9) "It differs from just writing the expression you want to write" is definitely confusing
10) Agree
11) This is kind-of mentioned later in the negative index part. It may be worth mentioning that a single index must be within bounds, but the explanation on degenerate slices has its place too, since it's a friendly feature of Python many rely on.
12) Agree
13) This is probably too arguable to be included. With Python's duck typing there *is* sometimes place for placing different objects in the same list, with the understanding that they all have some common behavior (for example, callables).
14) Agree

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14097>
_______________________________________

From report at bugs.python.org  Fri Feb 24 22:02:08 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Feb 2012 21:02:08 +0000
Subject: [issue13706] non-ascii fill characters no longer work in formatting
In-Reply-To: <1325630185.42.0.0487894537415.issue13706@psf.upfronthosting.co.za>
Message-ID: <1330117328.77.0.537965327631.issue13706@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> By the way, Python 3.2 fails also to handle
> non-ASCII thousands separator or non-ASCII
> decimal point: (...)

Hum, it is not trivial to redo the work on Python 3.2. I prefer to leave the code unchanged to not introduce a regression, and I wait until a Python 3.2 user complains (the bug exists since Python 3.0 and nobody complained).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13706>
_______________________________________

From report at bugs.python.org  Fri Feb 24 22:03:01 2012
From: report at bugs.python.org (sbt)
Date: Fri, 24 Feb 2012 21:03:01 +0000
Subject: [issue14116] Lock.__enter__() method returns True instead of self
Message-ID: <1330117381.1.0.499178307418.issue14116@psf.upfronthosting.co.za>


New submission from sbt <shibturn at gmail.com>:

The __enter__() methods of Lock, RLock, Semaphore and Condition in threading (and multiprocessing) all return True.  This seems to contradict the documentation for the context protocol which says

  contextmanager.__enter__()

    Enter the runtime context and return either this object or 
    another object related to the runtime context. The value 
    returned by this method is bound to the identifier in the
    as clause of with statements using this context manager.

    ...

I don't think True qualifies as "another object related to the runtime context".

It looks like an oversight caused by making __enter__() an alias for acquire().  Is it reasonable to change this for 3.3?  I tripped over the issue when I tried writing

  with Condition() as c:
    ...

----------
components: Library (Lib)
messages: 154161
nosy: sbt
priority: normal
severity: normal
status: open
title: Lock.__enter__() method returns True instead of self
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14116>
_______________________________________

From report at bugs.python.org  Fri Feb 24 22:04:21 2012
From: report at bugs.python.org (Jason Yeo)
Date: Fri, 24 Feb 2012 21:04:21 +0000
Subject: [issue14032] test_cmd_line_script prints undefined 'data' variable
In-Reply-To: <1329409071.29.0.619315923648.issue14032@psf.upfronthosting.co.za>
Message-ID: <1330117461.99.0.901699372106.issue14032@psf.upfronthosting.co.za>


Jason Yeo <jasonyeo88 at gmail.com> added the comment:

hi, 

*friendly ping* how's the review for this patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14032>
_______________________________________

From report at bugs.python.org  Fri Feb 24 22:08:46 2012
From: report at bugs.python.org (Jason Yeo)
Date: Fri, 24 Feb 2012 21:08:46 +0000
Subject: [issue14026] test_cmd_line_script should include more sys.argv checks
In-Reply-To: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za>
Message-ID: <1330117726.5.0.117925291057.issue14026@psf.upfronthosting.co.za>


Jason Yeo <jasonyeo88 at gmail.com> added the comment:

*friendly ping*, how's the review for this patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14026>
_______________________________________

From report at bugs.python.org  Fri Feb 24 22:11:13 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 24 Feb 2012 21:11:13 +0000
Subject: [issue4256] argparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1330117873.08.0.299101699751.issue4256@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Fri Feb 24 22:52:45 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Feb 2012 21:52:45 +0000
Subject: [issue14117] Turtledemo: exception and minor glitches.
Message-ID: <1330120365.77.0.428280648922.issue14117@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Win7, 3.2.2, python -m turtledemo in Command Prompt Window

After running clock example, hitting Stop results in following:
Clock face, including hands, is erased. Day and date are left (intentional?), and the following appears back in command prompt window.

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Programs\Python32\lib\tkinter\__init__.py", line 1399, in __call__
    return self.func(*args)
  File "C:\Programs\Python32\lib\tkinter\__init__.py", line 487, in callit
    func(*args)
  File "C:\Programs\Python32\lib\turtledemo\clock.py", line 116, in tick
    second_hand.setheading(6*sekunde)
  File "C:\Programs\Python32\lib\turtle.py", line 1936, in setheading
    self._rotate(angle)
  File "C:\Programs\Python32\lib\turtle.py", line 3279, in _rotate
    self._update()
  File "C:\Programs\Python32\lib\turtle.py", line 2660, in _update
    self._update_data()
  File "C:\Programs\Python32\lib\turtle.py", line 2646, in _update_data
    self.screen._incrementudc()
  File "C:\Programs\Python32\lib\turtle.py", line 1285, in _incrementudc
    raise Terminator
turtle.Terminator

Demo continues to run.

Paint: Left clicking mouse moves dot without painting. Right clicking changes mode so left clicking draws line. It also causes some filling of enclosed regions. This double action is slightly obscure. The prompt on the bottom of the screen says "Use mouse/keys or Stop" As near as I can tell, keys are inactive. So prompt could delete '/keys'.

Module doc strings that explain each demo should be wrapped so that they appear in the code window without scrolling. Or the left window could be wider, especially if the user widens the window. 800x600 screens are pretty rare these days. 

'Wikipedia' is a poor name for something just because it happened to be there. 'Rosette', for instance, would be better.

----------
components: Library (Lib)
messages: 154164
nosy: terry.reedy
priority: normal
severity: normal
status: open
title: Turtledemo: exception and minor glitches.
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14117>
_______________________________________

From report at bugs.python.org  Fri Feb 24 23:41:31 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Feb 2012 22:41:31 +0000
Subject: [issue14046] argparse: assertion failure if optional argument has
	square/round brackets in metavar
In-Reply-To: <1329542509.5.0.84021889574.issue14046@psf.upfronthosting.co.za>
Message-ID: <1330123291.28.0.807112865105.issue14046@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14046>
_______________________________________

From report at bugs.python.org  Sat Feb 25 00:38:06 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Fri, 24 Feb 2012 23:38:06 +0000
Subject: [issue14118] _pickle.c structure cleanup
Message-ID: <1330126686.15.0.366051703347.issue14118@psf.upfronthosting.co.za>


New submission from Merlijn van Deen <valhallasw at gmail.com>:

While working on #6784, I've looked at _pickle.c and found it quite... daunting: 6500 lines and 185kB. I have been working on a bit of cleanup, and I'd like some comments on this.

I'm working on adapting
_pickle.c into the following structure:

_pickle.c takes care of the module initialization
_pickle/*.c are helper files for this (global functions/definitions)
_pickle/PicklerObject contains all files that relate to the Pickler
class - initialization, all functions, etc, and
_pickle/PicklerObject/picklers/*.c contains all pickling functions,
split out into groups (corresponding to pickletools.StackObjects)

This should end in a tree where every .c module lists the relevant dependencies (and as such should be compilable on itself).

Currently, I'm at the point where PicklerObject roughly has the structure I want (although not every file is compilable on itself yet). As such, I feel this is the right moment to ask if it would be seen as an useful improvement in trunk, and to see if anyone has suggestions for improvements.

hg repos: https://bitbucket.org/valhallasw/cpython/src/0810ffadffa3/Modules/_pickle/PicklerObject (_pickle_clean branch)

----------
components: Extension Modules
hgrepos: 114
messages: 154165
nosy: valhallasw
priority: normal
severity: normal
status: open
title: _pickle.c structure cleanup
type: enhancement
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14118>
_______________________________________

From report at bugs.python.org  Sat Feb 25 00:43:43 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 24 Feb 2012 23:43:43 +0000
Subject: [issue14107] Debian bigmem buildbot hanging in test_bigmem
In-Reply-To: <1330096646.48.0.414006184823.issue14107@psf.upfronthosting.co.za>
Message-ID: <E1S14nd-00010V-MC@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4afcb25988c4 by Victor Stinner in branch 'default':
Issue #14107: fix bigmem tests on str.capitalize(), str.swapcase() and
http://hg.python.org/cpython/rev/4afcb25988c4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14107>
_______________________________________

From report at bugs.python.org  Sat Feb 25 00:52:48 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Feb 2012 23:52:48 +0000
Subject: [issue14118] _pickle.c structure cleanup
In-Reply-To: <1330126686.15.0.366051703347.issue14118@psf.upfronthosting.co.za>
Message-ID: <1330127568.07.0.89883274619.issue14118@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think this is going overboard. _pickle.c is long but it defines two classes which are closely related to each other. I don't really get the point of exploding it into a myriad of 30-line files, especially if it means I now have to keep all these tiny files open when I want to change something in the pickle module.

If you want to find a target for modularizing, I think posixmodule.c would be a far better candidate.

----------
nosy: +alexandre.vassalotti, pitrou
priority: normal -> low
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14118>
_______________________________________

From report at bugs.python.org  Sat Feb 25 00:53:11 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Feb 2012 23:53:11 +0000
Subject: [issue14107] Debian bigmem buildbot hanging in test_bigmem
In-Reply-To: <1330096646.48.0.414006184823.issue14107@psf.upfronthosting.co.za>
Message-ID: <1330127591.32.0.538762690764.issue14107@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I ran test_bigmem on my computer. The test pass but it is really slow.
----
$ ./python -m test -v -M 8G test_bigmem
(...
Ran 164 tests in 3228.227s

OK (skipped=44)
1 test OK.
----

One hour, whereas 44 tests are skipped. Skipped tests are the tests using the most quantity of memory, so I expect that they are even slower.

Do you need these tests using so much memory (and are really slow)?
---
test_capitalize (test.test_bigmem.StrTest) ... skipped 'not enough memory: 24.0G minimum needed'
test_encode_utf32 (test.test_bigmem.StrTest) ... skipped 'not enough memory: 9.0G minimum needed'
test_format (test.test_bigmem.StrTest) ... skipped 'not enough memory: 12.0G minimum needed'
test_repr_large (test.test_bigmem.StrTest) ... skipped 'not enough memory: 10.0G minimum needed'
test_split_large (test.test_bigmem.StrTest) ... skipped 'not enough memory: 20.0G minimum needed'
test_swapcase (test.test_bigmem.StrTest) ... skipped 'not enough memory: 24.0G minimum needed'
test_title (test.test_bigmem.StrTest) ... skipped 'not enough memory: 24.0G minimum needed'
test_translate (test.test_bigmem.StrTest) ... skipped 'not enough memory: 12.0G minimum needed'
test_split_large (test.test_bigmem.BytesTest) ... skipped 'not enough memory: 20.0G minimum needed'
test_compare (test.test_bigmem.TupleTest) ... skipped 'not enough memory: 32.0G minimum needed'
test_concat_large (test.test_bigmem.TupleTest) ... skipped 'not enough memory: 48.0G minimum needed'
test_concat_small (test.test_bigmem.TupleTest) ... skipped 'not enough memory: 24.0G minimum needed'
test_contains (test.test_bigmem.TupleTest) ... skipped 'not enough memory: 16.0G minimum needed'
test_from_2G_generator (test.test_bigmem.TupleTest) ... skipped 'not enough memory: 9.0G minimum needed'
test_from_almost_2G_generator (test.test_bigmem.TupleTest) ... skipped 'not enough memory: 9.0G minimum needed'
test_hash (test.test_bigmem.TupleTest) ... skipped 'not enough memory: 16.0G minimum needed'
test_index_and_slice (test.test_bigmem.TupleTest) ... skipped 'not enough memory: 16.0G minimum needed'
test_repeat_large (test.test_bigmem.TupleTest) ... skipped 'not enough memory: 48.0G minimum needed'
test_repeat_large_2 (test.test_bigmem.TupleTest) ... skipped 'not enough memory: 12.0G minimum needed'
test_repeat_small (test.test_bigmem.TupleTest) ... skipped 'not enough memory: 24.0G minimum needed'
test_repr_large (test.test_bigmem.TupleTest) ... skipped 'not enough memory: 22.0G minimum needed'
test_append (test.test_bigmem.ListTest) ... skipped 'not enough memory: 18.0G minimum needed'
test_compare (test.test_bigmem.ListTest) ... skipped 'not enough memory: 32.0G minimum needed'
test_concat_large (test.test_bigmem.ListTest) ... skipped 'not enough memory: 48.0G minimum needed'
test_concat_small (test.test_bigmem.ListTest) ... skipped 'not enough memory: 24.0G minimum needed'
test_contains (test.test_bigmem.ListTest) ... skipped 'not enough memory: 16.0G minimum needed'
test_count (test.test_bigmem.ListTest) ... skipped 'not enough memory: 16.0G minimum needed'
test_extend_large (test.test_bigmem.ListTest) ... skipped 'not enough memory: 32.0G minimum needed'
test_extend_small (test.test_bigmem.ListTest) ... skipped 'not enough memory: 16.0G minimum needed'
test_hash (test.test_bigmem.ListTest) ... skipped 'not enough memory: 16.0G minimum needed'
test_index (test.test_bigmem.ListTest) ... skipped 'not enough memory: 16.0G minimum needed'
test_index_and_slice (test.test_bigmem.ListTest) ... skipped 'not enough memory: 16.0G minimum needed'
test_inplace_concat_large (test.test_bigmem.ListTest) ... skipped 'not enough memory: 48.0G minimum needed'
test_inplace_concat_small (test.test_bigmem.ListTest) ... skipped 'not enough memory: 24.0G minimum needed'
test_inplace_repeat_large (test.test_bigmem.ListTest) ... skipped 'not enough memory: 32.0G minimum needed'
test_inplace_repeat_small (test.test_bigmem.ListTest) ... skipped 'not enough memory: 16.0G minimum needed'
test_insert (test.test_bigmem.ListTest) ... skipped 'not enough memory: 18.0G minimum needed'
test_pop (test.test_bigmem.ListTest) ... skipped 'not enough memory: 16.0G minimum needed'
test_remove (test.test_bigmem.ListTest) ... skipped 'not enough memory: 16.0G minimum needed'
test_repeat_large (test.test_bigmem.ListTest) ... skipped 'not enough memory: 48.0G minimum needed'
test_repeat_small (test.test_bigmem.ListTest) ... skipped 'not enough memory: 24.0G minimum needed'
test_repr_large (test.test_bigmem.ListTest) ... skipped 'not enough memory: 22.0G minimum needed'
test_reverse (test.test_bigmem.ListTest) ... skipped 'not enough memory: 16.0G minimum needed'
test_sort (test.test_bigmem.ListTest) ... skipped 'not enough memory: 16.0G minimum needed'
---

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14107>
_______________________________________

From report at bugs.python.org  Sat Feb 25 01:03:54 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 25 Feb 2012 00:03:54 +0000
Subject: [issue14107] Debian bigmem buildbot hanging in test_bigmem
In-Reply-To: <1330096646.48.0.414006184823.issue14107@psf.upfronthosting.co.za>
Message-ID: <1330128234.77.0.966000748931.issue14107@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> I ran test_bigmem on my computer. The test pass but it is really slow.

Is this with or without the fix you just pushed? How much RAM does your
system have? I tried running with "-M 4.5G" on my 8GB machine earlier
today, and it ate through all of my RAM plus 4GB of swap before the OOM
killer terminated it.


> Do you need these tests using so much memory (and are really slow)?

In general, I think it's important to exercise cases where 32-bit
truncation issues and the like might arise, because otherwise they'll lie
around undetected until they bite some unsuspecting user at an
inopportune moment. But I don't know much about those specific tests, so
I can't really offer much of an opinion here.

[Still, 48GB minimum? ?_? ]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14107>
_______________________________________

From report at bugs.python.org  Sat Feb 25 01:06:52 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 25 Feb 2012 00:06:52 +0000
Subject: [issue14107] Debian bigmem buildbot hanging in test_bigmem
In-Reply-To: <1330128234.77.0.966000748931.issue14107@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZPxnYDyGb75qNKTg1N1Qa+WP6LypoCS0RC+aXePGJj-g@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

>> I ran test_bigmem on my computer. The test pass but it is really slow.
>
> Is this with or without the fix you just pushed? How much RAM does your
> system have? I tried running with "-M 4.5G" on my 8GB machine earlier
> today, and it ate through all of my RAM plus 4GB of swap before the OOM
> killer terminated it.

My PC has 12 GB of RAM and no swap. I ran the test after my commit.

I tried to enable swap but writing to the swap does completly crash my
kernel. My / uses btrfs and btrfs doesn't look to support swap files,
even with a loopback device.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14107>
_______________________________________

From report at bugs.python.org  Sat Feb 25 01:10:06 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Sat, 25 Feb 2012 00:10:06 +0000
Subject: [issue14118] _pickle.c structure cleanup
In-Reply-To: <1330126686.15.0.366051703347.issue14118@psf.upfronthosting.co.za>
Message-ID: <1330128606.95.0.0950021715057.issue14118@psf.upfronthosting.co.za>


Merlijn van Deen <valhallasw at gmail.com> added the comment:

That makes sense. The goal was not so much cleaning up the module per se; rather, it was a result of trying to understand the general structure of _pickler.c specifically.

However, is there an intermediate level of 'modularization' you would propose? The idea is of course not to have 30 files open to make a small change, but rather have one or two reasonably small files open. My current approach was fine-grained on purpose - it's not that much work to recombine files.

I think it makes sense to split the PicklerObject into several parts:
  * the Pickler object (initialization/type/etc, maybe functions split off)
  * the actualy pickler implementation (dump/save/save_*) (but maybe in less files - see below)
  * the PicklerMemoProxy

for the picker implementation - specifically the picklers directory - my approach was to have a 'mirrored' directory for PicklerObject and UnPicklerObject: the methods to pickle and unpickle will be in the same files in the two directories (i.e. picklers/unicode.c will pickle str, unpicklers/unicode.c will unpickle them).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14118>
_______________________________________

From report at bugs.python.org  Sat Feb 25 01:12:21 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 25 Feb 2012 00:12:21 +0000
Subject: [issue14107] Debian bigmem buildbot hanging in test_bigmem
In-Reply-To: <1330096646.48.0.414006184823.issue14107@psf.upfronthosting.co.za>
Message-ID: <1330128741.64.0.125020683896.issue14107@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> My PC has 12 GB of RAM and no swap. I ran the test after my commit.

That explains. I ran it earlier (obviously), so it included a bunch of
those more-demanding tests, which must be where the OOM killer hit it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14107>
_______________________________________

From report at bugs.python.org  Sat Feb 25 01:15:25 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Feb 2012 00:15:25 +0000
Subject: [issue14049] execfile() fails on files that use global variables
	inside functions
In-Reply-To: <1329569998.87.0.931536345344.issue14049@psf.upfronthosting.co.za>
Message-ID: <1330128925.46.0.887599529886.issue14049@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Searching on 'exec NameError' shows that this issue is a duplicate of (behavior issue) #1167300 which contained an essentially identical example"

>>> exec """\
... x = 3
... def f():
...     print x
... f()
... """ in {}, {}

#1167300 was closed as a duplicate of (behavior issue) #991196, which in turn was closed as 'won't fix' (ie, works as it must). Doc issue #4831, which resulted in some doc changes, seems related to this but is not the same. I believe this issue is a duplicate of #13557, which has a patch. I will add my proposed change there.

Anyway, my comments:

In 3.2.2, this runs

#prog='''\
x = 1
def weird():
    y = x + 1
    return y
print(weird())
#'''
#exec(prog)

The same uncommented does also, as does adding ',{}' to the call.
Adding ',{},{}' gives the NameError.
With one named {} arg passed twice, as follows, it runs.

d = {}
exec(prog, d, d)

The reasons for these results are:
1. assignments are *always* to the local namespace.
2. normally, for module code, the local and global namespaces are the same.
3. in the example, 'x=1' is the same as "values['x']=1", while within the function, 'y=x+1' looks up x in gvalues.

This is the same explanation as given in #1167300.

----------
nosy: +terry.reedy
resolution:  -> duplicate
status: open -> closed
superseder:  -> exec of list comprehension fails on NameError
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14049>
_______________________________________

From report at bugs.python.org  Sat Feb 25 01:18:06 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Feb 2012 00:18:06 +0000
Subject: [issue13557] exec of list comprehension fails on NameError
In-Reply-To: <1323375954.63.0.637699438673.issue13557@psf.upfronthosting.co.za>
Message-ID: <1330129086.92.0.703470700926.issue13557@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Issues like this, about exec, have come up multiple times. I just closed #14049 as a duplicate of this, and listed there some other issues. So I think that the doc for exec (and execfile in 2.7) could be better still. I would like to see something like the following added, whether instead of or in addition to the current proposal -- perhaps after "If provided, locals can be any mapping object." (quote from the 3.2 exec entry)

"At module level, globals and locals are the same dictionary. If one passes two separate objects as globals and locals, the code will be executed as if it were embedded in a class definition."

To me, this is friendlier and less intimidating than 'free variable' and the Execution model doc chapter. It summarizes the essential problem with such exec calls.

To illustrate, the following gives the same NameError. and for the same reason, as exec(code,{},{}), where code is the quoted unindented version with the class line deleted.

class x:
    x = 1
    def incx():
        return x+1
    print(incx())

----------
nosy: +terry.reedy
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13557>
_______________________________________

From report at bugs.python.org  Sat Feb 25 01:19:02 2012
From: report at bugs.python.org (Nam Nguyen)
Date: Sat, 25 Feb 2012 00:19:02 +0000
Subject: [issue14119] Ability to adjust queue size in Executors
Message-ID: <1330129142.34.0.452763799677.issue14119@psf.upfronthosting.co.za>


New submission from Nam Nguyen <bitsink at gmail.com>:

I am running into a memory consumption issue with concurrent.futures module. Its Executors do not have a public API to adjust their queue size.  and the queues are created unbounded initially.

It would be helpful to have some public method or a parameter at construction time to limit this queue size.

----------
components: Library (Lib)
messages: 154175
nosy: Nam.Nguyen
priority: normal
severity: normal
status: open
title: Ability to adjust queue size in Executors
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14119>
_______________________________________

From report at bugs.python.org  Sat Feb 25 01:34:21 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Feb 2012 00:34:21 +0000
Subject: [issue14095] type_new() removes __qualname__ from the input dictionary
In-Reply-To: <1329956865.57.0.697177106628.issue14095@psf.upfronthosting.co.za>
Message-ID: <E1S15ae-0004xP-CR@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b83ae75beaca by Victor Stinner in branch 'default':
Close #14095: type.__new__() doesn't remove __qualname__ key from the class
http://hg.python.org/cpython/rev/b83ae75beaca

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14095>
_______________________________________

From report at bugs.python.org  Sat Feb 25 01:35:35 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Feb 2012 00:35:35 +0000
Subject: [issue14074] argparse does not allow nargs>1 for positional arguments
	but doesn't allow metavar to be a tuple
In-Reply-To: <1329845918.75.0.31962840333.issue14074@psf.upfronthosting.co.za>
Message-ID: <1330130135.66.0.398729183847.issue14074@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14074>
_______________________________________

From report at bugs.python.org  Sat Feb 25 01:37:03 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Feb 2012 00:37:03 +0000
Subject: [issue14076] sqlite3 module ignores placeholers in CREATE TRIGGER code
In-Reply-To: <1329853172.58.0.728674289337.issue14076@psf.upfronthosting.co.za>
Message-ID: <1330130223.88.0.573473046013.issue14076@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14076>
_______________________________________

From report at bugs.python.org  Sat Feb 25 01:40:28 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Feb 2012 00:40:28 +0000
Subject: [issue14089] Patch to increase fractions lib test coverage
In-Reply-To: <1329934239.36.0.224119101932.issue14089@psf.upfronthosting.co.za>
Message-ID: <1330130428.02.0.883898654612.issue14089@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/issue14089>
_______________________________________

From report at bugs.python.org  Sat Feb 25 01:44:41 2012
From: report at bugs.python.org (Nam Nguyen)
Date: Sat, 25 Feb 2012 00:44:41 +0000
Subject: [issue14119] Ability to adjust queue size in Executors
In-Reply-To: <1330129142.34.0.452763799677.issue14119@psf.upfronthosting.co.za>
Message-ID: <1330130681.48.0.972729560486.issue14119@psf.upfronthosting.co.za>


Nam Nguyen <bitsink at gmail.com> added the comment:

By the way, ProcessPoolExecutor actually sets its queue size to a reasonable number but ThreadPoolExecutor does not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14119>
_______________________________________

From report at bugs.python.org  Sat Feb 25 02:15:32 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Feb 2012 01:15:32 +0000
Subject: [issue14092] __name__ inconsistently applied in class definition
In-Reply-To: <1329953348.22.0.00582409575183.issue14092@psf.upfronthosting.co.za>
Message-ID: <1330132532.65.0.71379131172.issue14092@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is not a bug report, as Python works as documented. 
Double underscore names are defined as *reserved* for the interpreter, with the ones actually in use having defined meanings.

type.__new__ sets several internally used attributes on new classes. The attribute look-up mechanism for classes looks at them first before looking in __dict__, which is for attributes of both the class and its instances. Here is another example similar to yours.

>>> class C: __dict__ = 1

>>> C.__dict__
dict_proxy({'__dict__': 1, '__module__': '__main__', '__weakref__': <attribute '__weakref__' of 'C' objects>, '__doc__': None})
>>> C().__dict__
1

__dict__ is not writable, but __class__ is. You can already rename a class if you really want:

>>> C.__name__ = 'bizarre'
>>> C.__name__
'bizarre'

Conceptually, this seems the right way as one normally would not want the name of the class to be the default name for every instance.

>>> C().__name__
Traceback (most recent call last):
  File "<pyshell#12>", line 1, in <module>
    C().__name__
AttributeError: 'bizarre' object has no attribute '__name__'

If you really want instances to have that also, then also do as you did.

There are other class-only, not for instances, attributes:
__mro__ and __subclasses__ and perhaps others.

----------
nosy: +terry.reedy
resolution:  -> rejected
status: open -> closed
type: behavior -> enhancement
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14092>
_______________________________________

From report at bugs.python.org  Sat Feb 25 02:18:53 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Feb 2012 01:18:53 +0000
Subject: [issue14105] Breakpoints in debug lost if line is inserted; IDLE
In-Reply-To: <1330047327.02.0.291761854329.issue14105@psf.upfronthosting.co.za>
Message-ID: <1330132733.5.0.827941816904.issue14105@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/issue14105>
_______________________________________

From report at bugs.python.org  Sat Feb 25 04:04:14 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 25 Feb 2012 03:04:14 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1330139054.28.0.940964879032.issue2377@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Added file: http://bugs.python.org/file24632/c011ff345a78.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Sat Feb 25 04:08:02 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 25 Feb 2012 03:08:02 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1330139282.93.0.565840920399.issue2377@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Then if you want to give it a review that would be great!

I still need to solve the test_pydoc failure (either with Brian's patch to add a name attribute to ImportError or implement importlib.find_module()). Otherwise all other failures at the moment are because of mtime race conditions (as you know =) or exist in the default branch. And I still need to integrate rebuilding importlib.h into the Makefile, but that should be easy since it will probably be a separate command so you don't accidentally break import by busting importlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Sat Feb 25 06:30:18 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 05:30:18 +0000
Subject: [issue13557] exec of list comprehension fails on NameError
In-Reply-To: <1323375954.63.0.637699438673.issue13557@psf.upfronthosting.co.za>
Message-ID: <1330147818.97.0.474019400685.issue13557@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Stefan: This fell off my radar, sorry I haven?t reviewed your patch yet.

Terry: +1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13557>
_______________________________________

From report at bugs.python.org  Sat Feb 25 06:32:42 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 05:32:42 +0000
Subject: [issue14072] urlparse on tel: URI-s misses the scheme in some cases
In-Reply-To: <1329817524.78.0.223656665156.issue14072@psf.upfronthosting.co.za>
Message-ID: <1330147962.01.0.694827598211.issue14072@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

urlparse doesn?t actually implement generic parsing rules according to the most recent RFCs; it has hard-coded registries of supported schemes.  tel is not currently supported.  That said, it?s strange that the parsing differs in your two examples.

----------
components: +Library (Lib) -None
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14072>
_______________________________________

From report at bugs.python.org  Sat Feb 25 06:34:38 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 05:34:38 +0000
Subject: [issue14082] shutil doesn't copy extended attributes
In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za>
Message-ID: <1330148078.6.0.923585803731.issue14082@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> copy2() claims to work like "cp -p"
It probably does, for a behavior of ?cp -p? that predates extended attributes <wink>.

Do you think the best way is to always copy xattrs, add a new parameter, add a new copy function?

----------
nosy: +eric.araujo
title: shutil doesn't support extended attributes -> shutil doesn't copy extended attributes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14082>
_______________________________________

From report at bugs.python.org  Sat Feb 25 06:36:14 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 05:36:14 +0000
Subject: [issue14075] argparse: unused method?
In-Reply-To: <1329848199.77.0.390599674253.issue14075@psf.upfronthosting.co.za>
Message-ID: <1330148174.39.0.77698584666.issue14075@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Following Steven?s message, I will remove the unused function.

----------
assignee:  -> eric.araujo
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14075>
_______________________________________

From report at bugs.python.org  Sat Feb 25 06:36:59 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 05:36:59 +0000
Subject: [issue13974] packaging: test for set_platform()
In-Reply-To: <1328775875.69.0.230962367845.issue13974@psf.upfronthosting.co.za>
Message-ID: <1330148219.33.0.405072130002.issue13974@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

BTW I?m wondering if set_platform is really useful; no code currently uses it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13974>
_______________________________________

From report at bugs.python.org  Sat Feb 25 06:40:29 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 05:40:29 +0000
Subject: [issue14103] argparse: add ability to create a bash completion script
In-Reply-To: <1330031882.01.0.825351616002.issue14103@psf.upfronthosting.co.za>
Message-ID: <1330148429.97.0.116366894391.issue14103@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Closing as rejected for now.

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed
title: argparse: add ability to create a bash_completion script -> argparse: add ability to create a bash completion script

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14103>
_______________________________________

From report at bugs.python.org  Sat Feb 25 06:43:51 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 05:43:51 +0000
Subject: [issue4256] argparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1330148631.57.0.0305535060408.issue4256@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> zsh completion is much more powerful.
I beg to differ :)  bash completion can also list more that files, for example only .bz2 files when I complete the bunzip2 command, or Mercurial branch and tag names when I complete hg update, etc.  It all depends on the completion script.

I think that there may be enough common ground between the two shells that argparse could print out enough information for both systems.  I haven?t read the code of genzshcomp, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Sat Feb 25 06:45:21 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 05:45:21 +0000
Subject: [issue14106] Distutils manifest: recursive-(include|exclude) matches
	suffix instead of full filename
In-Reply-To: <1330094795.44.0.467789061974.issue14106@psf.upfronthosting.co.za>
Message-ID: <1330148721.89.0.976699410601.issue14106@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks, will look into it.

----------
assignee:  -> eric.araujo
components: +Distutils, Distutils2
nosy: +alexis
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14106>
_______________________________________

From report at bugs.python.org  Sat Feb 25 06:54:09 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 05:54:09 +0000
Subject: [issue14026] test_cmd_line_script should include more sys.argv checks
In-Reply-To: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za>
Message-ID: <1330149249.53.0.43305246363.issue14026@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I saw nothing wrong.  Give Nick a week to find time to review :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14026>
_______________________________________

From report at bugs.python.org  Sat Feb 25 07:05:34 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 06:05:34 +0000
Subject: [issue14102] argparse: add ability to create a man page
In-Reply-To: <1330031760.56.0.8938390885.issue14102@psf.upfronthosting.co.za>
Message-ID: <1330149934.36.0.956562587636.issue14102@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Alright :)  I?ve contacted the author of the blog article to ask him if we can reuse his code.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14102>
_______________________________________

From report at bugs.python.org  Sat Feb 25 07:33:05 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 25 Feb 2012 06:33:05 +0000
Subject: [issue14032] test_cmd_line_script prints undefined 'data' variable
In-Reply-To: <1329409071.29.0.619315923648.issue14032@psf.upfronthosting.co.za>
Message-ID: <1330151585.73.0.623528171973.issue14032@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14032>
_______________________________________

From report at bugs.python.org  Sat Feb 25 07:34:51 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 25 Feb 2012 06:34:51 +0000
Subject: [issue14026] test_cmd_line_script should include more sys.argv checks
In-Reply-To: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za>
Message-ID: <1330151691.85.0.382716035407.issue14026@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14026>
_______________________________________

From report at bugs.python.org  Sat Feb 25 07:41:03 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 06:41:03 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1330152063.07.0.190442341764.issue6884@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> - test_glob_to_re() was doing two levels of escaping (r'\' -> r'\\\\')
>   for its expected output when it should only do one (r'\' -> r'\\').
Fix merged.  I don?t fully understand why one place needs two escapes and the others just one.

> - test_process_template() was not converting some of its expected
>   results to use the native directory separator.
Overlooked paths fixed.

> I also took the liberty of changing the checks for whether the separator needs to be escaped
> - it's better to escape everything except "/", just in case someone decides to port Python to
> some platform using a weird directory separator that is neither "/" nor r"\".
I didn?t take that part.  If someone wants to port Python with a new style of os.sep or os.extsep, I?ll deal with it when they report that.

The buildout.cfg and VCS dirs issues are covered by unit tests for both filelist and sdist, but thanks for testing manually with a real setup.py too.  The third problem you mention (inclusion of unwanted module in a subdir) is also covered by test_filelist.

On a related subject, the code in sdist that excludes VCS dirs uses r'/|\\'; I thought that os.altsep was an alternate *accepted* separator, but not actually produced by OS calls.  IOW, I?m asking if os.walk (used to create filelist.allfiles) can ever give paths with '/' on Windows.  If not, then the regex is redundant, and I can clean it in packaging.  My patch removes the redundancy, just for curiosity, but I won?t actually commit that part to distutils.

----------
Added file: http://bugs.python.org/file24633/filelist-regex-bugs-v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sat Feb 25 07:51:00 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 06:51:00 +0000
Subject: [issue1112955] move_file()'s return value when dry_run=1 unclear
Message-ID: <1330152660.75.0.682867610658.issue1112955@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

My opinion about dry-run modes is that the goal is to be as close as possible to the real operation, but leave the world in a clean state.  Therefore, testing for file existence is okay (nevermind about modifying the last accessed time, it isn?t important IMO), but creating a file is not okay.  So I?m perfectly fine if calling the function with dry_run=1 will now not always succeed.  You want to see that error when running in dry-run mode.

I?ll improve the test and commit the patch.

packaging uses shutil.move directly, which does not return anything; I will check if packaging does not need it or if we have a regression and need to improve shutil.move in 3.3.

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1112955>
_______________________________________

From report at bugs.python.org  Sat Feb 25 07:59:45 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 06:59:45 +0000
Subject: [issue14097] Improve the "introduction" page of the tutorial
In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>
Message-ID: <1330153185.28.0.026728652164.issue14097@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Be careful with whitespace changes.  Sometimes not putting whitespace around an operator helps to see the grouping of operations, for example.  The important thing is ?Readability counts?, not ?Always put whitespace around operators?.  A huge part of understanding PEP 8 is to know when not to follow PEP 8 (PEP 20 is not called a Zen for no reason :)

About 5)-6): I really wish the docs wouldn?t use the term ?variable?, which means something else in most other programming languages and always cause beginners to stumble upon unexpected-for-them binding behavior.

A remark that?s probably culture-dependent: ?degenerate? nearly sounds like a racist insult to me (see 11).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14097>
_______________________________________

From report at bugs.python.org  Sat Feb 25 08:04:20 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 07:04:20 +0000
Subject: [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>
Message-ID: <1330153460.02.0.793070993256.issue13491@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Here?s a patch for 2.7.  I haven?t changed the text_factory example.

The second patch is for 3.2 and contains a few additional changes that I did in my first patch.

----------
Added file: http://bugs.python.org/file24634/sqlite-doc-tweaks-2.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13491>
_______________________________________

From report at bugs.python.org  Sat Feb 25 08:04:28 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 07:04:28 +0000
Subject: [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>
Message-ID: <1330153468.27.0.363271163883.issue13491@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file24635/sqlite-doc-tweaks-3.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13491>
_______________________________________

From report at bugs.python.org  Sat Feb 25 08:09:51 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 07:09:51 +0000
Subject: [issue13973] urllib.parse is imported twice in xmlrpc.client
In-Reply-To: <1328775757.49.0.00418569487883.issue13973@psf.upfronthosting.co.za>
Message-ID: <1330153791.2.0.00509705003471.issue13973@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/issue13973>
_______________________________________

From report at bugs.python.org  Sat Feb 25 08:16:25 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 07:16:25 +0000
Subject: [issue14081] Allow "maxsplit" argument to str.split() to be passed as
	a keyword argument
In-Reply-To: <1329875650.41.0.375574316124.issue14081@psf.upfronthosting.co.za>
Message-ID: <1330154185.08.0.36205305424.issue14081@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

LGTM.

(Nick: I think the author directly translated the regex function calls from other languages to using re in Python.)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14081>
_______________________________________

From report at bugs.python.org  Sat Feb 25 08:17:48 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 07:17:48 +0000
Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes
	lag
In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za>
Message-ID: <1330154268.22.0.726633870139.issue6085@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 to Antoine?s proposal of removal.

----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6085>
_______________________________________

From report at bugs.python.org  Sat Feb 25 08:18:42 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 07:18:42 +0000
Subject: [issue1116520] Prefix search is filesystem-centric
Message-ID: <1330154322.69.0.623919289515.issue1116520@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +carljm, eric.araujo
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1116520>
_______________________________________

From report at bugs.python.org  Sat Feb 25 08:22:57 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 07:22:57 +0000
Subject: [issue14116] Lock.__enter__() method returns True instead of self
In-Reply-To: <1330117381.1.0.499178307418.issue14116@psf.upfronthosting.co.za>
Message-ID: <1330154577.75.0.460301310781.issue14116@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

IIUC returning True is not incorrect, only useless.  In the stdlib I usually see ?with lock:?.  Can you tell what is the use case for accessing the condition object inside the context block?  Does it apply only to Condition or also to *Lock and Semaphore?

----------
nosy: +eric.araujo, ncoghlan, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14116>
_______________________________________

From report at bugs.python.org  Sat Feb 25 08:29:02 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 07:29:02 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>
Message-ID: <1330154942.58.0.500091370339.issue13447@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Good points.

New docstring:

  Tests for scripts in the Tools directory.

  This file contains regression tests for some of the scripts found in the
  Tools directory of a Python checkout or tarball, such as reindent.py.

When I commit I?ll also send to python-dev a reply to the python-checkins email to advertise the new file.

New skip message:

  test irrelevant for an installed Python

Better?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Sat Feb 25 08:35:36 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 07:35:36 +0000
Subject: [issue14112] tutorial intro talks of "shallow copy" concept without
	explanation
In-Reply-To: <1330113005.05.0.0872009811322.issue14112@psf.upfronthosting.co.za>
Message-ID: <1330155336.29.0.86229641689.issue14112@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think it?s a common English term (i.e. ?shallow water? to describe a small lake-like thing where you can go without swimming), but non-native speakers may not know it (I don?t remember if I knew it before learning Python, for example).

What about this:

 All slice operations return a new list containing the requested elements.  This
-means that the following slice returns a shallow copy of the list *a*::
+means that the following slice returns a shallow copy (see the documentation of
+the :mod:`copy` module for a definition) of the list *a*::

(BTW, you can use syntax like Doc/tutorial/introduction.rst:487 to have links generated; see http://docs.python.org/devguide/triaging#generating-special-links-in-a-comment ?also linked from the ?Comment? label in the form, but it isn?t obvious that it?s a link).

----------
nosy: +eric.araujo, ezio.melotti, terry.reedy
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14112>
_______________________________________

From report at bugs.python.org  Sat Feb 25 08:37:13 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 25 Feb 2012 07:37:13 +0000
Subject: [issue14114] 2.7.3rc1 chm gives JS error
In-Reply-To: <1330114530.4.0.50026951866.issue14114@psf.upfronthosting.co.za>
Message-ID: <1330155433.0.0.375945172258.issue14114@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

"$" refers to JQuery, and should be defined in http://docs.python.org/_static/jquery.js.
Maybe you have to import/include that file before http://docs.python.org/_static/copybutton.js?
There are also other js scripts there that use JQuery so I'm not sure why it's failing with the copybutton.

The copy button (the one on the top-right in the code examples) is a fairly new addition and it's not vital for the docs, so if we can't find a solution we can probably just skip that file and build the chm without copy button.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14114>
_______________________________________

From report at bugs.python.org  Sat Feb 25 08:41:29 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 25 Feb 2012 07:41:29 +0000
Subject: [issue14074] argparse allows nargs>1 for positional arguments but
	doesn't allow metavar to be a tuple
In-Reply-To: <1329845918.75.0.31962840333.issue14074@psf.upfronthosting.co.za>
Message-ID: <1330155689.02.0.374498996411.issue14074@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
title: argparse does not allow nargs>1 for positional arguments but doesn't allow metavar to be a tuple -> argparse allows nargs>1 for positional arguments but doesn't allow metavar to be a tuple

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14074>
_______________________________________

From report at bugs.python.org  Sat Feb 25 08:41:43 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 07:41:43 +0000
Subject: [issue14089] Patch to increase fractions lib test coverage
In-Reply-To: <1329934239.36.0.224119101932.issue14089@psf.upfronthosting.co.za>
Message-ID: <1330155703.96.0.77599672345.issue14089@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

LGTM

----------
nosy: +eric.araujo
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14089>
_______________________________________

From report at bugs.python.org  Sat Feb 25 09:00:18 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 25 Feb 2012 08:00:18 +0000
Subject: [issue14097] Improve the "introduction" page of the tutorial
In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>
Message-ID: <1330156818.65.0.362712962932.issue14097@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Be careful with whitespace changes.

Here I agree with you and disagree with the PEP 8 (specifically where it says that "hypot2 = x*x + y*y" and "c = (a+b) * (a-b)" are "wrong").

In
-   >>> 3+1j*3
+   >>> 3 + 1j * 3
I intentionally added spaces around all the operators to leave the expression ambiguous.  IIUC the point of that example is to show that even if 3+1j is a single entity, normal precedence rules still apply, so I didn't want the reader to make any assumptions about the precedence based on the whitespace (or even worse thing that the whitespace might define the precedence).

Additional comments and replies about the list:
 1) A user was confused about >>>, thought that was necessary to "define variables", that you had to always include it in your code.  The tutorial should make clear that this is used only in the interactive interpreter and not in regular code;
 2-3) what Eli said sounds good to me;
 5) "A value can be assigned to several variables simultaneously:" might lead to thing that "a = b = []" is the same as "a = []; b= []".  The term "variable" has a different meaning in other languages, but that doesn't mean we should refrain to use it -- we just have to specify what we mean with "variable" (this can be done later, saying that "both a and b will refer to the same list" should be enough here);
 6) here the idea is that is not the value to be assigned to the variable (like in C where the vars are like boxes and you can put values inside), but the variable that is used to refer to the object (so it's more like a label assigned to the object).  Again we can don't need to be too specific here yet, but we shouldn't say wrong things either.  See also http://python.net/crew/mwh/hacks/objectthink.html;
 11) presenting the error raised with the index first and the fact that slices are more "permissive" later sounds better to me;
 13) I'm not saying we should specifically tell users to put object of the same kind in a list, but just to avoid focusing on this aspect and use "realistic" examples.  Adding a note at the end saying that "lists can also contain objects of different types" should be enough;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14097>
_______________________________________

From report at bugs.python.org  Sat Feb 25 09:02:04 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 08:02:04 +0000
Subject: [issue12119] distutils and python -B
In-Reply-To: <1305822053.61.0.184404379566.issue12119@psf.upfronthosting.co.za>
Message-ID: <1330156924.49.0.220115081424.issue12119@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I thought about this and am not sure about my position.

I am 100% convinced that what packaging does is the right thing.  Modules like py_compile, compileall (in 3.2+) and packaging are able to compile with or without optimization depending on options that are given to them, independently from the optimization level of the calling Python.

distutils however depends on the calling Python?s -B and -O options, and I just don?t think there is much value in fixing this bug and causing obscure bugs for people who?ve been using -B to control distutils for the past months.

Antoine, you?re a pragmatist and a fixer of bugs.  Arfrever, you?re using this misfeature.  I?d like to know your opinion.

----------
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12119>
_______________________________________

From report at bugs.python.org  Sat Feb 25 09:06:16 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Sat, 25 Feb 2012 08:06:16 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>
Message-ID: <1330157176.49.0.531282873686.issue13447@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

Hi ?ric,
some questions:

1)if test_tools is going to be the test for all the Tools (at least
until it grows to much), shoudn't be be module doc something like ???Tests for scripts in Tools/**???

2)is the SkipTest ?reindent? specific? 

Cheers,

francis

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Sat Feb 25 09:07:25 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 25 Feb 2012 08:07:25 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1330157245.34.0.217800195625.issue6884@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

There are some minor errors in your v3 patch. I've attached a v4 that fixes
them (as usual, tested on Windows and Linux):

 - s/special/sep/ in glob_to_re()
 - Add missing l(.) to filenames in test_process_template under 'graft d'


>> - test_glob_to_re() was doing two levels of escaping (r'\' -> r'\\\\')
>>   for its expected output when it should only do one (r'\' -> r'\\').
> Fix merged.  I don?t fully understand why one place needs two escapes and the others just one.

The places that use one level of escaping are the ones that deal with the
regex string directly. In glob_to_re() itself, the string you're building
is a regex replacement pattern that *operates on* the regex that gets
returned, so it needs one level of escaping for when the output regex is
actually applied, and a second one for the immediate call to re.sub().
When re.sub is called, it eats one level of the escaping, and operates on
a string with one level, returning a string with one level.


>> I also took the liberty of changing the checks for whether the separator needs to be escaped
>> - it's better to escape everything except "/", just in case someone decides to port Python to
>> some platform using a weird directory separator that is neither "/" nor r"\".
> I didn?t take that part.  If someone wants to port Python with a new style of os.sep or os.extsep, I?ll deal with it when they report that.

If you want to leave it as it is, that's your choice. But I do think it's
better to make this Do The Right Thing now, given how easy it is.


> On a related subject, the code in sdist that excludes VCS dirs uses r'/|\\'; I thought that os.altsep was an alternate *accepted* separator, but not actually produced by OS calls.  IOW, I?m asking if os.walk (used to create filelist.allfiles) can ever give paths with '/' on Windows.  If not, then the regex is redundant, and I can clean it in packaging.  My patch removes the redundancy, just for curiosity, but I won?t actually commit that part to distutils.

Well, as far as I can make out, the current implementation always uses
r'\' to join paths. But it won't convert existing '/'s in the start
path to r'\'s, so you might still end up encountering both separators
(assuming the initial path is something you get from the user somewhere
along the line).

(These remarks are not specific to os.walk, but are relevant to anything
based on os.path.join - for example, distutils.filelist.findall and
packaging.manifest._findall)

----------
Added file: http://bugs.python.org/file24636/filelist-regex-v4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sat Feb 25 09:08:27 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 08:08:27 +0000
Subject: [issue13340] list.index does not accept None as start or stop
In-Reply-To: <1320398584.03.0.145013152611.issue13340@psf.upfronthosting.co.za>
Message-ID: <1330157307.47.0.800226664572.issue13340@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
priority: high -> normal
stage: committed/rejected -> commit review
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13340>
_______________________________________

From report at bugs.python.org  Sat Feb 25 09:09:04 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sat, 25 Feb 2012 08:09:04 +0000
Subject: [issue4256] argparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1330148631.57.0.0305535060408.issue4256@psf.upfronthosting.co.za>
Message-ID: <4F489717.4090502@in.waw.pl>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

ZSH can just present it in a prettier way, and also includes slightly
more info (the short explanations, ordering).

 > could print out enough information for both systems.
Exactly.

ZSH can use bash completion, but then it doesn't display the extra info. 
It would be nice to keep those optional features in mind to avoid 
limiting the exported information to that useful for bash.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Sat Feb 25 09:09:40 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 25 Feb 2012 08:09:40 +0000
Subject: [issue14112] tutorial intro talks of "shallow copy" concept without
	explanation
In-Reply-To: <1330113005.05.0.0872009811322.issue14112@psf.upfronthosting.co.za>
Message-ID: <1330157380.77.0.852681869193.issue14112@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Even if they know the meaning of "shallow" (which is not a really common word AFAICT), they might not know what it means in this context.

Adding an entry to glossary might be a better solution.

In this context I think the best solution would be to actually show the implication of having a shallow copy with another short example (hijacking the reader to some other page where they can find some in-depth description of what "shallow" might do more harm than good).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14112>
_______________________________________

From report at bugs.python.org  Sat Feb 25 09:10:23 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 25 Feb 2012 08:10:23 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1330157423.05.0.337465638202.issue6884@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

>> - test_glob_to_re() was doing two levels of escaping (r'\' -> r'\\\\')
>>   for its expected output when it should only do one (r'\' -> r'\\').
> Fix merged.  I don?t fully understand why one place needs two escapes and the others just one.

I agree that this code is confusing, though. Perhaps we should add a
comment in glob_to_re():

    # Warning - manipulating a regex with a regex. Here be dragons.

;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sat Feb 25 09:21:43 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 08:21:43 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1330158103.36.0.921812324107.issue6884@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks a bunch.  I?ll offer you cookies when we meet :)

>> Fix merged.  I don?t fully understand why one place needs two escapes and the others just one.
> The places that use one level of escaping are the ones that deal with the regex string directly.
> In glob_to_re() itself, the string you're building is a regex replacement pattern that *operates on*
> the regex that gets returned
Makes sense.  I?ve added a comment as you suggested (although an unfunny one, without dragons; I don?t like ?you?re not supposed to understand this?-like comments).

>>> I also took the liberty of changing the checks for whether the separator needs to be escaped
>>> - it's better to escape everything except "/", just in case someone decides to port Python to
>>> some platform using a weird directory separator that is neither "/" nor r"\".
>> I didn?t take that part.  If someone wants to port Python with a new style of os.sep or os.extsep,
>> I?ll deal with it when they report that.
> If you want to leave it as it is, that's your choice. But I do think it's better to make this Do The
> Right Thing now, given how easy it is.
I?d be okay with some cleanup in packaging, but for distutils I want the minimal patch.

> Well, as far as I can make out, the current implementation always uses r'\' to join paths. But it
> won't convert existing '/'s in the start path to r'\'s, so you might still end up encountering both
> separators (assuming the initial path is something you get from the user somewhere along the line).
Hm, it should come from the manifest template, i.e. using '/' that get translated to os.sep.  I?ll remove the regex redundancy in packaging, we have rather good tests for manifest and sdist now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sat Feb 25 09:21:48 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 25 Feb 2012 08:21:48 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>
Message-ID: <1330158108.47.0.46419088971.issue13447@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

[?ric]
> New docstring:
>
>   Tests for scripts in the Tools directory.
>
>   This file contains regression tests for some of the scripts found in the
>   Tools directory of a Python checkout or tarball, such as reindent.py.
>
> When I commit I?ll also send to python-dev a reply to the python-checkins email to advertise the new file.
>
> New skip message:
>
>   test irrelevant for an installed Python
>
> Better?

Sounds good to me.

[Francisco]
> 1)if test_tools is going to be the test for all the Tools (at least
> until it grows to much), shoudn't be be module doc something like ???Tests for scripts in Tools/**???

I think ?ric's suggestion in msg154197 is fine.

> 2)is the SkipTest ?reindent? specific? 

No, it's common to all of the Tools scripts. When you install Python, the
Tools directory is not copied into the install destination. So if you're
using an installed copy of Python (either from running "make install", or
from a binary installer), the scripts won't exist. In this case, we
(obviously) can't test them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Sat Feb 25 09:25:21 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 08:25:21 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>
Message-ID: <1330158321.63.0.45859982325.issue13447@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> if test_tools is going to be the test for all the Tools (at least until it grows to much),
Seriously, we don?t care about the size of test files.  test_argparse.py is 4777 lines long :)

> shoudn't be be module doc something like ???Tests for scripts in Tools/**???
I find this wording worse than mine, sorry.

> is the SkipTest ?reindent? specific? 
The SkipTest is raised at the top level of the module.  No test from test_tools will be able to run outside of an uninstalled build.  Maybe you are asking that because my message uses the singular, i.e. ?test irrelevant etc.? and not ?tests??  In this instance, the singular ?test? refers to test_tools, viewed as one test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Sat Feb 25 09:33:20 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 25 Feb 2012 08:33:20 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1330158800.65.0.150378145727.issue6884@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

>>> Fix merged.  I don?t fully understand why one place needs two escapes and the others just one.
>> The places that use one level of escaping are the ones that deal with the regex string directly.
>> In glob_to_re() itself, the string you're building is a regex replacement pattern that *operates on*
>> the regex that gets returned
> Makes sense.  I?ve added a comment as you suggested (although an unfunny one, without dragons; I don?t like ?you?re not supposed to understand this?-like comments).

Hmm yeah, I had just meant the dragons bit as a joke... I wouldn't want
people to get the impression that the code should be treated as magic.


>>> I didn?t take that part.  If someone wants to port Python with a new style of os.sep or os.extsep,
>>> I?ll deal with it when they report that.
>> If you want to leave it as it is, that's your choice. But I do think it's better to make this Do The
>> Right Thing now, given how easy it is.
> I?d be okay with some cleanup in packaging, but for distutils I want the minimal patch.

That's fine by me.


>> Well, as far as I can make out, the current implementation always uses r'\' to join paths. But it
>> won't convert existing '/'s in the start path to r'\'s, so you might still end up encountering both
>> separators (assuming the initial path is something you get from the user somewhere along the line).
> Hm, it should come from the manifest template, i.e. using '/' that get translated to os.sep.  I?ll remove the regex redundancy in packaging, we have rather good tests for manifest and sdist now.

I was thinking that maybe findall()'s 'dir' argument could be specified
by the user as a command-line flag or something. But looking through
the sdist code, it seems that it always uses the current directory. So
your change shouldn't be a problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sat Feb 25 09:34:18 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Sat, 25 Feb 2012 08:34:18 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1330158321.63.0.45859982325.issue13447@psf.upfronthosting.co.za>
Message-ID: <4F489D59.2020603@email.de>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

Sorry, my fault: I meant "Test for Tools" instead of """Tests for 
reindent.py.""" (Im not talking about the skip message but the test 
documentation or the first line 0,0...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Sat Feb 25 09:40:21 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 08:40:21 +0000
Subject: [issue8171] bdist_wininst builds wrongly for --plat-name=win-amd64
In-Reply-To: <1268913911.34.0.452575740724.issue8171@psf.upfronthosting.co.za>
Message-ID: <1330159221.65.0.674731442967.issue8171@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ll look into this when I get to set up a Windows VM and learn more about wininst.

----------
assignee: tarek -> eric.araujo
components: +Distutils2
nosy: +alexis, eric.araujo
stage: patch review -> test needed
versions: +3rd party, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8171>
_______________________________________

From report at bugs.python.org  Sat Feb 25 09:40:39 2012
From: report at bugs.python.org (Andi Albrecht)
Date: Sat, 25 Feb 2012 08:40:39 +0000
Subject: [issue14102] argparse: add ability to create a man page
In-Reply-To: <1330031760.56.0.8938390885.issue14102@psf.upfronthosting.co.za>
Message-ID: <1330159239.32.0.538307191415.issue14102@psf.upfronthosting.co.za>


Changes by Andi Albrecht <albrecht.andi at gmail.com>:


----------
nosy: +andialbrecht

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14102>
_______________________________________

From report at bugs.python.org  Sat Feb 25 09:41:08 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 08:41:08 +0000
Subject: [issue8170] Wrong Paths for distutils build --plat-name=win-amd64
In-Reply-To: <1268913333.33.0.305416760988.issue8170@psf.upfronthosting.co.za>
Message-ID: <1330159268.13.0.590989906265.issue8170@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Martin, Mark, can either of you comment on this?

----------
nosy: +eric.araujo, loewis, mhammond -terry.reedy
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8170>
_______________________________________

From report at bugs.python.org  Sat Feb 25 09:41:15 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 08:41:15 +0000
Subject: [issue8171] bdist_wininst builds wrongly for --plat-name=win-amd64
In-Reply-To: <1268913911.34.0.452575740724.issue8171@psf.upfronthosting.co.za>
Message-ID: <1330159275.05.0.580955302478.issue8171@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy:  -terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8171>
_______________________________________

From report at bugs.python.org  Sat Feb 25 09:45:20 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 25 Feb 2012 08:45:20 +0000
Subject: [issue14120] ARM Ubuntu 3.x buildbot failing test_dbm
Message-ID: <1330159520.1.0.928033022024.issue14120@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

The ARM Ubuntu 3.x buildbot often fails test_dbm:

http://www.python.org/dev/buildbot/all/builders/ARM%20Ubuntu%203.x/builds/364/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/ARM%20Ubuntu%203.x/builds/367/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/ARM%20Ubuntu%203.x/builds/368/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/ARM%20Ubuntu%203.x/builds/372/steps/test/logs/stdio

    ======================================================================
    ERROR: test_anydbm_creation (test.test_dbm.TestCase-dbm.ndbm)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_dbm.py", line 70, in test_anydbm_creation
        self.read_helper(f)
      File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_dbm.py", line 111, in read_helper
        self.assertEqual(self._dict[key], f[key.encode("ascii")])
    KeyError: b'0'

    ======================================================================
    ERROR: test_anydbm_modification (test.test_dbm.TestCase-dbm.ndbm)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_dbm.py", line 85, in test_anydbm_modification
        self.read_helper(f)
      File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_dbm.py", line 111, in read_helper
        self.assertEqual(self._dict[key], f[key.encode("ascii")])
    KeyError: b'0'

    ======================================================================
    ERROR: test_anydbm_read (test.test_dbm.TestCase-dbm.ndbm)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_dbm.py", line 91, in test_anydbm_read
        self.read_helper(f)
      File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_dbm.py", line 111, in read_helper
        self.assertEqual(self._dict[key], f[key.encode("ascii")])
    KeyError: b'0'

The stdio logs also show possibly-related output on stderr:

    test test_dbm failed
    @test_27319_tmp.db: unable to flush: No such file or directory
    @test_27319_tmp.db: unable to flush: No such file or directory

This is printed before the error tracebacks, but I assume it actually
happens afterwards (which is entirely possible if stderr is line-buffered
and stdout is not).

----------
components: Tests
keywords: buildbot
messages: 154215
nosy: nadeem.vawda
priority: normal
severity: normal
stage: needs patch
status: open
title: ARM Ubuntu 3.x buildbot failing test_dbm
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14120>
_______________________________________

From report at bugs.python.org  Sat Feb 25 09:55:21 2012
From: report at bugs.python.org (Christian Schilling)
Date: Sat, 25 Feb 2012 08:55:21 +0000
Subject: [issue14076] sqlite3 module ignores placeholers in CREATE TRIGGER code
In-Reply-To: <1329853172.58.0.728674289337.issue14076@psf.upfronthosting.co.za>
Message-ID: <1330160121.64.0.818991273998.issue14076@psf.upfronthosting.co.za>


Changes by Christian Schilling <initcrash at googlemail.com>:


----------
nosy: +Christian.Schilling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14076>
_______________________________________

From report at bugs.python.org  Sat Feb 25 09:57:06 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 08:57:06 +0000
Subject: [issue14102] argparse: add ability to create a man page
In-Reply-To: <1330031760.56.0.8938390885.issue14102@psf.upfronthosting.co.za>
Message-ID: <1330160226.93.0.00326763250718.issue14102@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Andi, the author of the blog post, will work on a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14102>
_______________________________________

From report at bugs.python.org  Sat Feb 25 10:12:01 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 25 Feb 2012 09:12:01 +0000
Subject: [issue14121] add a convenience C-API function for unpacking iterables
Message-ID: <1330161121.09.0.794717935446.issue14121@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

In the context of better interfacing of PyPy with Cython, it appears that simple looking things like PyTuple_GET_ITEM() are often rather involved in PyPy's C-API implementation. However, since functions/macros like these are used very frequently, this has an effect on the achievable performance.

It occurred to me that there are cases that involve many C-API calls where the intention is simply to unpack a sequence (or iterable) of known length, often just 2 or 3 items. Argument unpacking is one such situation (for which there are appropriate C-API functions), dict item iteration or iteration over enumerate() are other well known cases (at least in Python space). As the one obvious way to handle the general use case, I propose the following addition of a convenience function to the C-API:

int PyIter_Unpack(PyObject* iterable, Py_ssize_t min_unpack, Py_ssize_t max_unpack, ...)

As indicated by the names, it's meant to unpack any iterable or iterator, really, i.e. it would fall back to iteration if the iterable is neither a tuple nor list, for which special handling code makes the most sense. I thought about naming it PySequence_Unpack(), but that would imply that it should reject unordered (or, for safety, any unknown) iterables and non-sequence iterator as input, which IMHO would complicate matters more than it would help. A warning about unordered iterables in the documentation should be enough. I would expect that most users would actually know the type of sequence that they are processing.

The "max_unpack" parameter gives the number of varargs that follows, which are all either of type PyObject** or NULL, the latter indicating that the value is not of interest. Non-NULL pointers will receive a new reference to the item at the corresponding index.

The "min_unpack" parameter is made available for error checking. If less items are found in the iterable, the function sets a ValueError and returns -1. Assignments may or may not have taken place at this point, but no owned references are passed back in this case. If, on successful unpacking, the number of unpacked items is smaller than "max_unpack", all remaining item pointers will be set to NULL. Users who do not care about the number of items would pass 0 and those who know the exact length would pass that as both "min_unpack" and "max_unpack".

There is one case I'm not sure about yet, and that's how to handle the case of finding more items than "max_unpack" requests. I think it's just as convenient in some cases to automatically raise an exception, as it is in other cases to just ignore them. I think a way to solve this could be to not raise an exception, but to return 0 when all items were processed and 1 when there are remaining items. In this case, users who care could check the result and if they consider left-over items an error, clean up the returned references and raise an error manually. Alternatively, the function could return the number of unpacked items, but that may involve more work on the user side in order to find out what needs to be done. The drawback of a tristate return with and without errors set is that the straight forward "if (PyIter_Unpack(...))" check is no longer enough to correctly detect and propagate errors. Also, when passing an iterator, the function would have to eat one more value in order to determine the return code. That may not be what the caller wants.

Maybe an additional flag parameter ("check_size") could solve this. If true, the function will check the size of sequences and report longer sequences as errors, and for iterators, will unpack the next item and report it as error if available. If false, additional values will be ignored for sequences and no attempt will be made for iterators to unpack more items than requested.


Because of the questions above, and because this addition involves a certain redundancy with what's there already (namely the argument and tuple unpacking functions which do not work on lists or arbitrary iterables and/or raise the wrong exceptions), I'm asking for comments before writing up a patch. Any thoughts on this?

----------
components: Interpreter Core
messages: 154217
nosy: scoder
priority: normal
severity: normal
status: open
title: add a convenience C-API function for unpacking iterables
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14121>
_______________________________________

From report at bugs.python.org  Sat Feb 25 10:18:30 2012
From: report at bugs.python.org (Tim Golden)
Date: Sat, 25 Feb 2012 09:18:30 +0000
Subject: [issue14112] tutorial intro talks of "shallow copy" concept without
	explanation
In-Reply-To: <1330157380.77.0.852681869193.issue14112@psf.upfronthosting.co.za>
Message-ID: <4F48A758.2010102@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

On 25/02/2012 08:09, Ezio Melotti wrote:
> Even if they know the meaning of "shallow" (which is not a really common word AFAICT)

FWIW it's pretty much the only way of saying what it means.
I've no idea how many people used it last year or anything,
but if I needed to express the concept of the opposite of
deep I would struggle to find another word. Except, perhaps,
the doublespeak-like "not deep". Undeep? Double-plus undeep?

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14112>
_______________________________________

From report at bugs.python.org  Sat Feb 25 10:20:55 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 25 Feb 2012 09:20:55 +0000
Subject: [issue14112] tutorial intro talks of "shallow copy" concept without
	explanation
In-Reply-To: <1330113005.05.0.0872009811322.issue14112@psf.upfronthosting.co.za>
Message-ID: <1330161655.2.0.376542446905.issue14112@psf.upfronthosting.co.za>


Ramchandra Apte <maniandram01 at gmail.com> added the comment:

+1 for ?ric Araujo's idea.

----------
nosy: +ramchandra.apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14112>
_______________________________________

From report at bugs.python.org  Sat Feb 25 10:31:30 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 25 Feb 2012 09:31:30 +0000
Subject: [issue14114] 2.7.3rc1 chm gives JS error
In-Reply-To: <1330114530.4.0.50026951866.issue14114@psf.upfronthosting.co.za>
Message-ID: <1330162290.17.0.0157831149715.issue14114@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

In the generated htmlhelp\index.html, there is a line

    <script type="text/javascript" src="_static/copybutton.js"></script>

That's the only script tag in that file; jquery is not loaded at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14114>
_______________________________________

From report at bugs.python.org  Sat Feb 25 10:34:50 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 25 Feb 2012 09:34:50 +0000
Subject: [issue14114] 2.7.3rc1 chm gives JS error
In-Reply-To: <1330114530.4.0.50026951866.issue14114@psf.upfronthosting.co.za>
Message-ID: <1330162490.77.0.985247292467.issue14114@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

For the record: this issue blocks 3.2 as well.

----------
nosy: +benjamin.peterson, georg.brandl
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14114>
_______________________________________

From report at bugs.python.org  Sat Feb 25 10:41:46 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 25 Feb 2012 09:41:46 +0000
Subject: [issue14081] Allow "maxsplit" argument to str.split() to be passed as
	a keyword argument
In-Reply-To: <1329875650.41.0.375574316124.issue14081@psf.upfronthosting.co.za>
Message-ID: <1330162906.36.0.861111287771.issue14081@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Ezio: I spotted an extraneous '[' hanging around in the updated doc signature for split, but otherwise looked fine.

?ric: you're probably right, but I was sending them a note to suggest a simpler alternative, only to discover that the obvious approach of "maxsplit=1" didn't actually work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14081>
_______________________________________

From report at bugs.python.org  Sat Feb 25 10:45:32 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 25 Feb 2012 09:45:32 +0000
Subject: [issue14114] 2.7.3rc1 chm gives JS error
In-Reply-To: <1330114530.4.0.50026951866.issue14114@psf.upfronthosting.co.za>
Message-ID: <1330163132.84.0.839894623342.issue14114@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

18bbfed9aafa is the changeset that introduced the copy button.
Maybe the part in the "extrahead" (in Doc/tools/sphinxext/layout.html, see also first chunk of the diff) block shouldn't be included in chm?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14114>
_______________________________________

From report at bugs.python.org  Sat Feb 25 10:46:05 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Sat, 25 Feb 2012 09:46:05 +0000
Subject: [issue14082] shutil doesn't copy extended attributes
In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za>
Message-ID: <1330163165.39.0.616681764219.issue14082@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

I'd tend to always copy xattrs ? it seems that's what the user would expect to happen. A new parameter to _forbid_ it might make sense. However, I feel that there are already enough parameters in place. :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14082>
_______________________________________

From report at bugs.python.org  Sat Feb 25 10:49:54 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 25 Feb 2012 09:49:54 +0000
Subject: [issue14116] Lock.__enter__() method returns True instead of self
In-Reply-To: <1330117381.1.0.499178307418.issue14116@psf.upfronthosting.co.za>
Message-ID: <1330163394.71.0.305559291953.issue14116@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

"with Lock() as lock:" doesn't make any sense - you need to share the lock with other threads or code for it be useful, which means you can't create it inline in the with statement header. Instead, you have to store it somewhere else (usually as a closure reference or a module, class or instance attribute) and then merely use it in the with statement to acquire and release it appropriately.

Absent a compelling use case, I'm inclined to reject this one - when there's no specifically useful value to return from __enter__, None, True or False are all reasonable alternatives.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14116>
_______________________________________

From report at bugs.python.org  Sat Feb 25 10:51:24 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 25 Feb 2012 09:51:24 +0000
Subject: [issue14114] 2.7.3rc1 chm gives JS error
In-Reply-To: <1330114530.4.0.50026951866.issue14114@psf.upfronthosting.co.za>
Message-ID: <1330163484.79.0.510253874358.issue14114@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Either that, or jquery should be included as well. I wonder why the life version has

    <script type="text/javascript" src="_static/jquery.js"></script>

but the htmlhelp version does not. Not including the copy button seems safe, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14114>
_______________________________________

From report at bugs.python.org  Sat Feb 25 10:51:25 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 25 Feb 2012 09:51:25 +0000
Subject: [issue14112] tutorial intro talks of "shallow copy" concept without
	explanation
In-Reply-To: <1330155336.29.0.86229641689.issue14112@psf.upfronthosting.co.za>
Message-ID: <CAA77j2AE1ZMGuU3Bo_iVCL2R_puMrvq7-Z4gft7vza6zY7MYBA@mail.gmail.com>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

On Sat, Feb 25, 2012 at 09:35, ?ric Araujo <report at bugs.python.org> wrote:
> What about this:
>
> ?All slice operations return a new list containing the requested elements. ?This
> -means that the following slice returns a shallow copy of the list *a*::
> +means that the following slice returns a shallow copy (see the documentation of
> +the :mod:`copy` module for a definition) of the list *a*::

That's kool, though I like Ezio's idea of putting it on a glossary
(and then linking to it) even more.

> (BTW, you can use syntax like Doc/tutorial/introduction.rst:487 to have links generated; see http://docs.python.org/devguide/triaging#generating-special-links-in-a-comment ?also linked from the ?Comment? label in the form, but it isn?t obvious that it?s a link).

Thanks for the pointer. Note however that I chose my approach because
it shows the info at a specific revision, in case the content changes
later on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14112>
_______________________________________

From report at bugs.python.org  Sat Feb 25 10:54:36 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 25 Feb 2012 09:54:36 +0000
Subject: [issue14112] tutorial intro talks of "shallow copy" concept without
	explanation
In-Reply-To: <1330113005.05.0.0872009811322.issue14112@psf.upfronthosting.co.za>
Message-ID: <1330163676.52.0.0512165248649.issue14112@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> FWIW it's pretty much the only way of saying what it means.

However, even using "not deep" here would still be ambiguous.  What's a deep copy?  What's a non-deep copy?
Using "shallow" might be a problem, but the real problem is that regardless of the wording, the reader might not know what this is all about.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14112>
_______________________________________

From report at bugs.python.org  Sat Feb 25 10:56:52 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 25 Feb 2012 09:56:52 +0000
Subject: [issue14114] 2.7.3rc1 chm gives JS error
In-Reply-To: <1330114530.4.0.50026951866.issue14114@psf.upfronthosting.co.za>
Message-ID: <1330163812.42.0.971496057215.issue14114@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

JQuery and the other scripts (like sidebar.js) are part of Sphinx, whereas the copy button is something that was added to our instances only, by changing the template.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14114>
_______________________________________

From report at bugs.python.org  Sat Feb 25 11:20:25 2012
From: report at bugs.python.org (Thomas Leonard)
Date: Sat, 25 Feb 2012 10:20:25 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1197387663.32.0.0598513497038.issue1589@psf.upfronthosting.co.za>
Message-ID: <1330165225.74.0.0740009393964.issue1589@psf.upfronthosting.co.za>


Thomas Leonard <talex5 at gmail.com> added the comment:

Just to add a couple of data points to argue in favour of a secure-by-default behaviour:

0install.net:

http://secunia.com/advisories/47935 (spoofing attack due to certificate names not being validated)

Mozilla is recommending people avoid using Python's built-in SSL:

https://github.com/mozilla/browserid/wiki/Security-Considerations-when-Implementing-BrowserID

I find it hard to believe that anyone would be able to write an SSL client in Python currently without introducing some vulnerability. There are too many traps to fall into. Here are the three I know about:

1. Not specifying any trusted CAs means trust everyone (where for most software it would mean either trust no-one or trust only well-known CAs).

2. Specifiying a single trusted CA means also trust all known CAs (on MacOS X at least).

3. Unless you manually enable hostname checking, the attacker only needs a valid SSL certificate for their own site, not for the site they're spoofing.

----------
nosy: +Thomas.Leonard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Sat Feb 25 11:24:44 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 25 Feb 2012 10:24:44 +0000
Subject: [issue14082] shutil doesn't copy extended attributes
In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za>
Message-ID: <1330165484.93.0.271249015079.issue14082@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I'm also in favor of adding extended attributes to copy2:
"""
Similar to shutil.copy(), but metadata is copied as well 
"""

extended attributes are metadata. And there are already too many copy functions...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14082>
_______________________________________

From report at bugs.python.org  Sat Feb 25 11:27:38 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Sat, 25 Feb 2012 10:27:38 +0000
Subject: [issue14082] shutil doesn't copy extended attributes
In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za>
Message-ID: <1330165658.16.0.338820301547.issue14082@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

If nobody objects, I'd cook up a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14082>
_______________________________________

From report at bugs.python.org  Sat Feb 25 11:28:59 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 25 Feb 2012 10:28:59 +0000
Subject: [issue14118] _pickle.c structure cleanup
In-Reply-To: <1330126686.15.0.366051703347.issue14118@psf.upfronthosting.co.za>
Message-ID: <1330165739.23.0.982873091135.issue14118@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm -1 on splitting the file. This is C, splitting it up will make it *harder* to understand, as you have to search across multiple files to find anything.

If you want to make it more readable, I propose that you
a) put a comment in the top explaining how the file is structured
b) put

/*****************************************************************/

  section headers between logical groups of functions.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14118>
_______________________________________

From report at bugs.python.org  Sat Feb 25 11:33:26 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 25 Feb 2012 10:33:26 +0000
Subject: [issue14046] argparse: assertion failure if optional argument has
	square/round brackets in metavar
In-Reply-To: <1329542509.5.0.84021889574.issue14046@psf.upfronthosting.co.za>
Message-ID: <1330166006.02.0.529371270976.issue14046@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Yes, this is a known bug (Issue 11874). Patches welcome.

----------
resolution:  -> duplicate
superseder:  -> argparse assertion failure with brackets in metavars

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14046>
_______________________________________

From report at bugs.python.org  Sat Feb 25 11:44:05 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Feb 2012 10:44:05 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1330166645.61.0.0981822664507.issue6884@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Be sure to notify me when you have committed a fix, as changes made now in the 3.2 branch will *not* show up in the final release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sat Feb 25 11:45:07 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 25 Feb 2012 10:45:07 +0000
Subject: [issue14074] argparse allows nargs>1 for positional arguments but
	doesn't allow metavar to be a tuple
In-Reply-To: <1329845918.75.0.31962840333.issue14074@psf.upfronthosting.co.za>
Message-ID: <1330166707.83.0.0260807537141.issue14074@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Looks like the problem is that "_format_action_invocation" is not being as careful with the different possibilities for metavar as "_format_args" is.  Patches welcome!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14074>
_______________________________________

From report at bugs.python.org  Sat Feb 25 12:04:17 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Sat, 25 Feb 2012 11:04:17 +0000
Subject: [issue14118] _pickle.c structure cleanup
In-Reply-To: <1330126686.15.0.366051703347.issue14118@psf.upfronthosting.co.za>
Message-ID: <1330167857.4.0.198939589353.issue14118@psf.upfronthosting.co.za>


Merlijn van Deen <valhallasw at gmail.com> added the comment:

See https://bitbucket.org/valhallasw/cpython/src/ee0d2beaf6a4/Modules/_pickle.c for a rough structure overview - which maybe also explains why I thought restructuring made sense in the first place.

However, I'm not the person who has to maintain the module. If you're not interested, I'll just split out the module until I feel comfortable editing stuff, make my patch for #6784 and backport it to the 6500-line version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14118>
_______________________________________

From report at bugs.python.org  Sat Feb 25 12:25:29 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Feb 2012 11:25:29 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <1234474743.76.0.794318305676.issue5231@psf.upfronthosting.co.za>
Message-ID: <E1S1Fkm-0004N3-55@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3f9b3b6f7ff0 by Stefan Krah in branch 'default':
- Issue #10181: New memoryview implementation fixes multiple ownership
http://hg.python.org/cpython/rev/3f9b3b6f7ff0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5231>
_______________________________________

From report at bugs.python.org  Sat Feb 25 12:25:29 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Feb 2012 11:25:29 +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: <E1S1Fkm-0004N3-5B@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3f9b3b6f7ff0 by Stefan Krah in branch 'default':
- Issue #10181: New memoryview implementation fixes multiple ownership
http://hg.python.org/cpython/rev/3f9b3b6f7ff0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7433>
_______________________________________

From report at bugs.python.org  Sat Feb 25 12:25:31 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Feb 2012 11:25:31 +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: <E1S1Fkm-0004N3-4x@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3f9b3b6f7ff0 by Stefan Krah in branch 'default':
- Issue #10181: New memoryview implementation fixes multiple ownership
http://hg.python.org/cpython/rev/3f9b3b6f7ff0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sat Feb 25 12:25:31 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Feb 2012 11:25:31 +0000
Subject: [issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous
	arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <E1S1Fkm-0004N3-5L@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3f9b3b6f7ff0 by Stefan Krah in branch 'default':
- Issue #10181: New memoryview implementation fixes multiple ownership
http://hg.python.org/cpython/rev/3f9b3b6f7ff0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Sat Feb 25 12:25:32 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Feb 2012 11:25:32 +0000
Subject: [issue8305] memoview[0] creates an invalid view if ndim != 1
In-Reply-To: <1270308282.65.0.542260907353.issue8305@psf.upfronthosting.co.za>
Message-ID: <E1S1Fkm-0004N3-5G@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3f9b3b6f7ff0 by Stefan Krah in branch 'default':
- Issue #10181: New memoryview implementation fixes multiple ownership
http://hg.python.org/cpython/rev/3f9b3b6f7ff0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8305>
_______________________________________

From report at bugs.python.org  Sat Feb 25 12:25:32 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Feb 2012 11:25:32 +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: <E1S1Fkm-0004N3-5R@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3f9b3b6f7ff0 by Stefan Krah in branch 'default':
- Issue #10181: New memoryview implementation fixes multiple ownership
http://hg.python.org/cpython/rev/3f9b3b6f7ff0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9990>
_______________________________________

From report at bugs.python.org  Sat Feb 25 12:41:26 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 25 Feb 2012 11:41:26 +0000
Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes
	lag
In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za>
Message-ID: <1330170086.59.0.104723085983.issue6085@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> +1 to Antoine?s proposal of removal.

Agreed.

Here's a patch.

Do note, however, that it's a behavior change: the address_string()
method is documented to return a resolved hostname (when possible).

----------
keywords: +needs review
stage: test needed -> patch review
Added file: http://bugs.python.org/file24637/server_resolve.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6085>
_______________________________________

From report at bugs.python.org  Sat Feb 25 13:48:34 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 25 Feb 2012 12:48:34 +0000
Subject: [issue14120] ARM Ubuntu 3.x buildbot failing test_dbm
In-Reply-To: <1330159520.1.0.928033022024.issue14120@psf.upfronthosting.co.za>
Message-ID: <1330174114.84.0.117021222783.issue14120@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Also failing on 3.2:

http://www.python.org/dev/buildbot/all/builders/ARM%20Ubuntu%203.2/builds/227/steps/test/logs/stdio

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14120>
_______________________________________

From report at bugs.python.org  Sat Feb 25 13:59:51 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 25 Feb 2012 12:59:51 +0000
Subject: [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>
Message-ID: <1330174791.0.0.52448599369.issue13491@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Both patches look good to me. The text_factory example is OK on 2.7 because the OptimizedUnicode flag works correctly there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13491>
_______________________________________

From report at bugs.python.org  Sat Feb 25 14:08:14 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 25 Feb 2012 13:08:14 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
In-Reply-To: <1329868289.43.0.901396663923.issue12801@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM33cvpaWUJzhGMfAm09-gsoJX5pq+WcZN650iM_SjkZ9Q@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

>  - os.realpath() uses canonicalize_file_name() if available, or use realpath() with a buffer of MAXPATHLEN bytes

MAXPATHLEN is not necessarily defined (e.g. on the Hurd): if it's not
defined, it is set either to MAX_PATH (if it's defined an greater than
1024), or arbitrarily to 1024.
Thus, we can't pass it to realpath(3), since we don't know for sure
that realpath(3) won't return a string greater than MAXPATHLEN, which
could result in a buffer overflow.

Also, there's the problem that realpath(3) returns ENOENT, whereas
os.path.realpath() doesn't:

without patch:
$ python -c "import os; os.path.realpath('/nosuchfile')"

with patch:
$ ./python -c "import os; os.path.realpath('/nosuchfile')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/cf/python/cpython/Lib/posixpath.py", line 385, in realpath
    return os.realpath(filename)
FileNotFoundError: [Errno 2] No such file or directory: '/nosuchfile'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12801>
_______________________________________

From report at bugs.python.org  Sat Feb 25 14:17:26 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 25 Feb 2012 13:17:26 +0000
Subject: [issue14113] Failure in test_strptime on Windows
In-Reply-To: <1330114398.55.0.713486121761.issue14113@psf.upfronthosting.co.za>
Message-ID: <1330175846.95.0.9479382606.issue14113@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Also failing on the Windows 7 bot:

http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/4453/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14113>
_______________________________________

From report at bugs.python.org  Sat Feb 25 15:05:53 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Feb 2012 14:05:53 +0000
Subject: [issue14113] Failure in test_strptime on Windows
In-Reply-To: <1330114398.55.0.713486121761.issue14113@psf.upfronthosting.co.za>
Message-ID: <E1S1IFz-0002hI-JF@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d5aa731bae5e by Nadeem Vawda in branch 'default':
Use assertEqual in test_strptime for better failure messages (cf. issue #14113).
http://hg.python.org/cpython/rev/d5aa731bae5e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14113>
_______________________________________

From report at bugs.python.org  Sat Feb 25 15:33:17 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 25 Feb 2012 14:33:17 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1330180397.69.0.181552010167.issue14080@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I've trouble debugging this: Is the new version of importlib already
being used? I'm stepping through the offending pep3147 import, which
should correspond to this line in test_dot.py:

   m = __import__('pep3147')
   

Until here Python/import.c is used:

find_module_path (fullname='pep3147', name='pep3147', path='.', path_hooks=[<type at remote 0x843020>], 
    path_importer_cache=
    {'/home/stefan/pydev/cpython-imp/Lib/collections': None, '': None, '/home/stefan/pydev/cpython-imp/Lib/unittest': None, '/home/stefan/pydev/cpython-imp/Lib/multiprocessing': None, '/usr/local/lib/python3.3/site-packages/setuptools-0.6c11-py3.3.egg-info': <imp.NullImporter at remote 0x7ffff7f6f0b0>, '/home/stefan/pydev/cpython-imp/Lib/importlib': None, '/home/stefan/pydev/cpython-imp/Lib/plat-linux': <_FileFinder(_cache_refresh=0, _path_cache={'TYPES.py', 'regen', 'DLFCN.py', 'IN.py', 'CDROM.py'}, path='/home/stefan/pydev/cpython-imp/Lib/plat-linux', _path_mtime=<float at remote 0xa6a838>, modules=[('.cpython-33m.so', <type at remote 0xab5450>), ('.abi3.so', <type at remote 0xab5450>), ('.so', <type at remote 0xab5450>), ('.py', <type at remote 0xab4a40>), ('.pyc', <type at remote 0xab4dc0>)], packages=[('.py', <type at remote 0xab4a40>), ('.pyc', <type at remote 0xab4dc0>)], _relaxed_path_cache={'types.py', 'regen', 'dlfcn.py', 'in.py', 'cdrom.py'}) at remote 0x7ffff37d8b50>, '.': <_FileFinder(_cache_refresh=...(truncated), p_path=0x7fffffff7f80, 
    p_loader=0x7fffffff80b8, p_fd=0x7fffffff7f98) at Python/import.c:1811
1811            if (importer == NULL) {
(gdb) n
1816            if (importer != Py_None) {
(gdb) n
1818                loader = _PyObject_CallMethodId(importer,



After descending further and further into the eval loop, all
of a sudden this appears:


3426        retval = PyEval_EvalFrameEx(f,0);
(gdb) s
PyEval_EvalFrameEx (f=
    Frame 0xafec40, for file /home/stefan/pydev/cpython-imp/Lib/importlib/_bootstrap.py, line 773, in find_module (self=<_FileFinder(_cache_refresh=0, _path_cache=set(), path='.', _path_mtime=<float at remote 0xa6a8b0>, modules=[('.cpython-33m.so', <type at remote 0xab5450>), ('.abi3.so', <type at remote 0xab5450>), ('.so', <type at remote 0xab5450>), ('.py', <type at remote 0xab4a40>), ('.pyc', <type at remote 0xab4dc0>)], packages=[('.py', <type at remote 0xab4a40>), ('.pyc', <type at remote 0xab4dc0>)], _relaxed_path_cache=set()) at remote 0x7ffff4128390>, fullname='pep3147'), 
    throwflag=0) at Python/ceval.c:808


Is this expected?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Sat Feb 25 15:39:10 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 25 Feb 2012 14:39:10 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1330180750.61.0.141932504502.issue14080@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Sat Feb 25 15:41:00 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 14:41:00 +0000
Subject: [issue14082] shutil doesn't copy extended attributes
In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za>
Message-ID: <1330180860.69.0.977935834128.issue14082@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Sounds good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14082>
_______________________________________

From report at bugs.python.org  Sat Feb 25 15:41:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 14:41:07 +0000
Subject: [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>
Message-ID: <1330180867.36.0.591070549869.issue13491@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: docs at python -> petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13491>
_______________________________________

From report at bugs.python.org  Sat Feb 25 15:51:51 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 14:51:51 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1330181511.5.0.19088865644.issue6884@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ll commit the 2.7 patch, see how buildbots fare, then commit the 3.2 version (also attached in case someone wants to test it).

----------
Added file: http://bugs.python.org/file24638/filelist-regex-bugs-3.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sat Feb 25 15:54:53 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Feb 2012 14:54:53 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1330180397.69.0.181552010167.issue14080@psf.upfronthosting.co.za>
Message-ID: <1330181477.3400.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Is this expected?

Looks rather strange to me, it means we have importlib importers on
sys.path_importer_cache. Still, the fact that path == '.' above (in
_FileFinder as well as find_module_path) makes it difficult to
understand the later failure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Sat Feb 25 15:57:18 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 14:57:18 +0000
Subject: [issue14112] tutorial intro talks of "shallow copy" concept without
	explanation
In-Reply-To: <1330113005.05.0.0872009811322.issue14112@psf.upfronthosting.co.za>
Message-ID: <1330181838.48.0.151165691339.issue14112@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

A link to a glossary may be better than a link to the top of the copy module.  I wonder if we could use glossary markup in the copy module docs instead of adding terms to the global glossary.

Tim: I like ?undeep?, it?s used to describe a geographical feature of a river in The Lord of the Rings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14112>
_______________________________________

From report at bugs.python.org  Sat Feb 25 16:11:22 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 25 Feb 2012 15:11:22 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1330182682.89.0.389474540491.issue6884@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

3.2 patch looks good on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sat Feb 25 16:14:01 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Feb 2012 15:14:01 +0000
Subject: [issue9691] sdist includes files that are not in MANIFEST.in
In-Reply-To: <1282822249.86.0.974734126224.issue9691@psf.upfronthosting.co.za>
Message-ID: <E1S1JJv-00005q-Kf@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 47788c90f80b by ?ric Araujo in branch '2.7':
Fix long-standing bugs with MANIFEST.in parsing on Windows (#6884).
http://hg.python.org/cpython/rev/47788c90f80b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9691>
_______________________________________

From report at bugs.python.org  Sat Feb 25 16:14:01 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Feb 2012 15:14:01 +0000
Subject: [issue13193] packaging.tests.test_manifest and
	distutils.tests.test_filelist failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <E1S1JJv-00005q-Js@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 47788c90f80b by ?ric Araujo in branch '2.7':
Fix long-standing bugs with MANIFEST.in parsing on Windows (#6884).
http://hg.python.org/cpython/rev/47788c90f80b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Sat Feb 25 16:14:02 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Feb 2012 15:14:02 +0000
Subject: [issue14004] Distutils filelist selects too many files on Windows
In-Reply-To: <1329166628.27.0.616152401371.issue14004@psf.upfronthosting.co.za>
Message-ID: <E1S1JJv-00005q-Ka@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 47788c90f80b by ?ric Araujo in branch '2.7':
Fix long-standing bugs with MANIFEST.in parsing on Windows (#6884).
http://hg.python.org/cpython/rev/47788c90f80b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14004>
_______________________________________

From report at bugs.python.org  Sat Feb 25 16:14:02 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Feb 2012 15:14:02 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <E1S1JJv-00005q-KT@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 47788c90f80b by ?ric Araujo in branch '2.7':
Fix long-standing bugs with MANIFEST.in parsing on Windows (#6884).
http://hg.python.org/cpython/rev/47788c90f80b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sat Feb 25 16:25:09 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Feb 2012 15:25:09 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>
Message-ID: <E1S1JUh-00013E-RG@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 020364d3e359 by ?ric Araujo in branch '2.7':
Add test file for scripts in Tools (#13447).
http://hg.python.org/cpython/rev/020364d3e359

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Sat Feb 25 16:32:25 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Feb 2012 15:32:25 +0000
Subject: [issue13193] packaging.tests.test_manifest and
	distutils.tests.test_filelist failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <E1S1Jbk-0001iT-FW@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 73aa4c9305b3 by ?ric Araujo in branch '3.2':
Fix long-standing bugs with MANIFEST.in parsing on Windows (#6884).
http://hg.python.org/cpython/rev/73aa4c9305b3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Sat Feb 25 16:32:26 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Feb 2012 15:32:26 +0000
Subject: [issue14004] Distutils filelist selects too many files on Windows
In-Reply-To: <1329166628.27.0.616152401371.issue14004@psf.upfronthosting.co.za>
Message-ID: <E1S1Jbk-0001iT-Fn@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 73aa4c9305b3 by ?ric Araujo in branch '3.2':
Fix long-standing bugs with MANIFEST.in parsing on Windows (#6884).
http://hg.python.org/cpython/rev/73aa4c9305b3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14004>
_______________________________________

From report at bugs.python.org  Sat Feb 25 16:32:27 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Feb 2012 15:32:27 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <E1S1Jbk-0001iT-Fi@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 73aa4c9305b3 by ?ric Araujo in branch '3.2':
Fix long-standing bugs with MANIFEST.in parsing on Windows (#6884).
http://hg.python.org/cpython/rev/73aa4c9305b3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sat Feb 25 16:32:27 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Feb 2012 15:32:27 +0000
Subject: [issue9691] sdist includes files that are not in MANIFEST.in
In-Reply-To: <1282822249.86.0.974734126224.issue9691@psf.upfronthosting.co.za>
Message-ID: <E1S1Jbk-0001iT-Fs@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 73aa4c9305b3 by ?ric Araujo in branch '3.2':
Fix long-standing bugs with MANIFEST.in parsing on Windows (#6884).
http://hg.python.org/cpython/rev/73aa4c9305b3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9691>
_______________________________________

From report at bugs.python.org  Sat Feb 25 16:40:46 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 25 Feb 2012 15:40:46 +0000
Subject: [issue13637] binascii.a2b_* functions could accept unicode strings
In-Reply-To: <1324312244.97.0.383716057437.issue13637@psf.upfronthosting.co.za>
Message-ID: <1330184446.84.0.97816173211.issue13637@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Discussion resolved in favor of patch.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13637>
_______________________________________

From report at bugs.python.org  Sat Feb 25 16:41:16 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 25 Feb 2012 15:41:16 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <1324386392.48.0.968435833624.issue13641@psf.upfronthosting.co.za>
Message-ID: <1330184476.39.0.0715138499074.issue13641@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Sat Feb 25 16:42:05 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 15:42:05 +0000
Subject: [issue1531415] parsetok.c emits warnings by writing to stderr
Message-ID: <1330184525.52.0.815139018775.issue1531415@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1531415>
_______________________________________

From report at bugs.python.org  Sat Feb 25 17:00:18 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 16:00:18 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>
Message-ID: <1330185618.01.0.502359399632.issue13447@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi Mark.  You?re the author of Tools/parser/test_unparse.py; any objection if I move it to the new Lib/test/test_tools.py file, so that all tests for Tools are in one place?

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Sat Feb 25 17:09:58 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 25 Feb 2012 16:09:58 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1330186198.77.0.0984848109662.issue14080@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

OK, I stepped in parallel through the non-failing and the failing
versions. The first divergence is when _path_mtime is compared.
The comparison in the good version returns 'False', the one in the
bad version returns 'True':

Good version (Fedora 16):

(gdb) p w
$148 = '_path_mtime'
(gdb) n
2278                x = PyObject_GetAttr(v, w);
(gdb) p v
$149 = 
    <_FileFinder(_relaxed_path_cache=set(), path='.', packages=[('.py', <type at remote 0xab4bc0>), ('.pyc', <type at remote 0xab4f40>)], _path_cache=set(), _cache_refresh=0, _path_mtime=<float at remote 0xa6a7d0>, modules=[('.cpython-33m.so', <type at remote 0xab55d0>), ('.abi3.so', <type at remote 0xab55d0>), ('.so', <type at remote 0xab55d0>), ('.py', <type at remote 0xab4bc0>), ('.pyc', <type at remote 0xab4f40>)]) at remote 0x7ffff4128310>
(gdb) n
2279                Py_DECREF(v);
(gdb) p x
$150 = <float at remote 0xa6a7d0>
(gdb) n
2280                SET_TOP(x);
(gdb) n
2281                if (x != NULL) DISPATCH();
(gdb) n
2284            TARGET(COMPARE_OP)
(gdb) n
2285                w = POP();
(gdb) n
2286                v = TOP();
(gdb) n
2287                x = cmp_outcome(oparg, v, w);
(gdb) n
2288                Py_DECREF(v);
(gdb) p w
$151 = <float at remote 0xa6a7d0>
(gdb) p v
$152 = <float at remote 0xa6a6f8>
(gdb) p x
$153 = False
(gdb) 


Bad version (Ubuntu):

(gdb) p w
$154 = '_path_mtime'
(gdb) p v
$155 = <float at remote 0xa66090>
(gdb) n
2278                x = PyObject_GetAttr(v, w);
(gdb) p v
$156 = 
    <_FileFinder(_relaxed_path_cache=set(), packages=[('.py', <type at remote 0xaaff60>), ('.p
yc', <type at remote 0xab02e0>)], _path_mtime=<float at remote 0xa66120>, modules=[('.cpython-
33m.so', <type at remote 0xab0970>), ('.abi3.so', <type at remote 0xab0970>), ('.so', <type at
 remote 0xab0970>), ('.py', <type at remote 0xaaff60>), ('.pyc', <type at remote 0xab02e0>)], 
path='.', _cache_refresh=0, _path_cache=set()) at remote 0x7ffff2b7f6d0>
(gdb) n
2279                Py_DECREF(v);
(gdb) p x
$157 = <float at remote 0xa66120>
(gdb) n
2280                SET_TOP(x);
(gdb) n
2281                if (x != NULL) DISPATCH();
(gdb) n
2284            TARGET(COMPARE_OP)
(gdb) n
2285                w = POP();
(gdb) n
2286                v = TOP();
(gdb) n
2287                x = cmp_outcome(oparg, v, w);
(gdb) n
2288                Py_DECREF(v);
(gdb) p w
$158 = <float at remote 0xa66120>
(gdb) p v
$159 = <float at remote 0xa66090>
(gdb) p x
$160 = True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Sat Feb 25 17:27:43 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 25 Feb 2012 16:27:43 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1330187263.66.0.813568257833.issue14080@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

So I think the good version proceeds to refresh the _path_cache:

<_FileFinder(_relaxed_path_cache={'pep3147'}, packages=[('.py', <type at remote 0xaaff60>), ('.pyc', <type at remote 0xab02e0>)], _path_mtime=<float at remote 0xa66120>, modules=[('.cpython-33m.so', <type at remote 0xab0970>), ('.abi3.so', <type at remote 0xab0970>), ('.so', <type at remote 0xab0970>), ('.py', <type at remote 0xaaff60>), ('.pyc', <type at remote 0xab02e0>)], path='.', _cache_refresh=0, _path_cache={'pep3147'}) at remote 0x7ffff2b7f6d0>


And the bad version still contains an empty set:
  
<_FileFinder(_relaxed_path_cache=set(), path='.', packages=[('.py', <type at remote 0xab4bc0>), ('.pyc', <type at remote 0xab4f40>)], _path_cache=set(), _cache_refresh=0, _path_mtime=<float at remote 0xa6a7d0>, modules=[('.cpython-33m.so', <type at remote 0xab55d0>), ('.abi3.so', <type at remote 0xab55d0>), ('.so', <type at remote 0xab55d0>), ('.py', <type at remote 0xab4bc0>), ('.pyc', <type at remote 0xab4f40>)]) at remote 0x7ffff4128310>



This probably means that the case split occurs in  Lib/importlib/_bootstrap.py:780 ...


    if mtime != self._path_mtime or _cache_refresh != self._cache_refresh:
            self._fill_cache()
            self._path_mtime = mtime
            self._cache_refresh = _cache_refresh

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Sat Feb 25 17:29:23 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 16:29:23 +0000
Subject: [issue14075] argparse: unused method?
In-Reply-To: <1329848199.77.0.390599674253.issue14075@psf.upfronthosting.co.za>
Message-ID: <1330187363.88.0.910611096049.issue14075@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hm, I was about to commit this and did a double-take.  Are we 100% sure that nobody in the whole wide world of Python does not override this function?  Shouldn?t we first send a DeprecationWarning in 3.3 and remove later?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14075>
_______________________________________

From report at bugs.python.org  Sat Feb 25 17:35:33 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 16:35:33 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1330187733.23.0.159593800976.issue6884@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Most buildbots are green, one has a test_subprocess failure, others are still building, but I have to go soon.  Release managers, please graft this fix when the bots are all green.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sat Feb 25 17:46:58 2012
From: report at bugs.python.org (Yaniv Aknin)
Date: Sat, 25 Feb 2012 16:46:58 +0000
Subject: [issue3445] Ignore missing attributes in functools.update_wrapper
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1330188418.87.0.740171414756.issue3445@psf.upfronthosting.co.za>


Yaniv Aknin <yaniv.aknin at gmail.com> added the comment:

Shouldn't this be fixed in 2.7 as well?

It's a bug, it's in the wild, and it's causing people to do ugly (and maybe not 100% reliable) things like https://code.djangoproject.com/browser/django/trunk/django/utils/decorators.py#L68

----------
nosy: +Yaniv.Aknin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3445>
_______________________________________

From report at bugs.python.org  Sat Feb 25 17:50:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Feb 2012 16:50:07 +0000
Subject: [issue3445] Ignore missing attributes in functools.update_wrapper
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1330188607.9.0.139838385633.issue3445@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/issue3445>
_______________________________________

From report at bugs.python.org  Sat Feb 25 17:59:53 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 25 Feb 2012 16:59:53 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1330189193.32.0.150795755914.issue14080@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

And indeed, with this patch ...

diff --git a/Lib/importlib/_bootstrap.py b/Lib/importlib/_bootstrap.py
--- a/Lib/importlib/_bootstrap.py
+++ b/Lib/importlib/_bootstrap.py
@@ -777,6 +777,8 @@
             mtime = _os.stat(self.path).st_mtime
         except OSError:
             mtime = -1
+        if fullname == 'pep3147':
+            print(mtime, self._path_mtime)
         if mtime != self._path_mtime or _cache_refresh != self._cache_refresh:
             self._fill_cache()
             self._path_mtime = mtime


Good version:

[stefan at fedora-16-amd64 cpython]$ ./python -m test test_dot
[1/1] test_dot
1330188705.3170006 1330188705.3100004
Warning -- sys.path was modified by test_dot


Bad version:

$ ./python -m test test_dot
[1/1] test_dot
1330188676.0 1330188676.0
Warning -- sys.path was modified by test_dot
test test_dot crashed -- Traceback (most recent call last):
  File "/home/stefan/pydev/cpython-imp/Lib/test/regrtest.py", line 1214, in runtest_inner
    the_package = __import__(abstest, globals(), locals(), [])
  File "/home/stefan/pydev/cpython-imp/Lib/test/test_dot.py", line 20, in <module>
    assert m.__file__ == expected___file__
AssertionError

1 test failed:
    test_dot



It looks like os.stat.st_mtime returns full seconds here on Ubuntu:

Python 3.3.0a0 (default:3f9b3b6f7ff0, Feb 25 2012, 17:42:23) 
[GCC 4.4.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.stat("./python").st_mtime
1330189060.0
>>> 










Nanoseconds, anyone? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Sat Feb 25 18:07:13 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Feb 2012 17:07:13 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1330189193.32.0.150795755914.issue14080@psf.upfronthosting.co.za>
Message-ID: <1330189417.3400.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le samedi 25 f?vrier 2012 ? 16:59 +0000, Stefan Krah a ?crit :
> Bad version:
> 
> $ ./python -m test test_dot
> [1/1] test_dot
> 1330188676.0 1330188676.0

This might be what triggers the issue, but it's not the cause. Even with
a bad mtime, the __file__ should still be the right one, so there must
be something else.

> It looks like os.stat.st_mtime returns full seconds here on Ubuntu:

It probably depends on the filesystem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Sat Feb 25 18:25:22 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 25 Feb 2012 17:25:22 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1330189417.3400.4.camel@localhost.localdomain>
Message-ID: <20120225172521.GA26645@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Antoine Pitrou <report at bugs.python.org> wrote:
> This might be what triggers the issue, but it's not the cause. Even with
> a bad mtime, the __file__ should still be the right one, so there must
> be something else.

It definitely triggers the issue because the problem also occurs on Fedora
if I use:

    if fullname != 'pep3147' and (mtime != self._path_mtime or _cache_refresh != self._cache_refresh):
        ...

But you're right, the real problem should be elsewhere. At least with
the line above everyone should be able to reproduce the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Sat Feb 25 18:26:53 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Feb 2012 17:26:53 +0000
Subject: [issue14114] 2.7.3rc1 chm gives JS error
In-Reply-To: <1330114530.4.0.50026951866.issue14114@psf.upfronthosting.co.za>
Message-ID: <E1S1LOW-0004Va-GU@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 64b9ff3c91bb by Ezio Melotti in branch '2.7':
#14114: don't include copybutton.js in the htmlhelp output.
http://hg.python.org/cpython/rev/64b9ff3c91bb

New changeset 7f651187b25c by Ezio Melotti in branch '3.2':
#14114: don't include copybutton.js in the htmlhelp output.
http://hg.python.org/cpython/rev/7f651187b25c

New changeset 39ddcc5c7fb9 by Ezio Melotti in branch 'default':
#14114: merge with 3.2.
http://hg.python.org/cpython/rev/39ddcc5c7fb9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14114>
_______________________________________

From report at bugs.python.org  Sat Feb 25 18:28:19 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 25 Feb 2012 17:28:19 +0000
Subject: [issue14114] 2.7.3rc1 chm gives JS error
In-Reply-To: <1330114530.4.0.50026951866.issue14114@psf.upfronthosting.co.za>
Message-ID: <1330190899.47.0.925859675654.issue14114@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Should be fixed now, let me know if it works.
(Thanks Georg for the help.)

----------
stage:  -> committed/rejected
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14114>
_______________________________________

From report at bugs.python.org  Sat Feb 25 18:29:07 2012
From: report at bugs.python.org (=?utf-8?q?F=C3=A9lix-Antoine_Fortin?=)
Date: Sat, 25 Feb 2012 17:29:07 +0000
Subject: [issue14122] operator: div() instead of truediv() in documention
	since 3.1.2
Message-ID: <1330190947.0.0.577940760696.issue14122@psf.upfronthosting.co.za>


New submission from F?lix-Antoine Fortin <felixantoinefortin+python at gmail.com>:

A small regression was introduced by the changeset 57209 in the documentation of the operator module.

In the abstract operations table in section 9.3.1 the first of two lines
on Division, the associated function should be : truediv() instead of div(), since operator.div() no longer exists in Python 3. In changeset 57209, this corresponds to the line 408 of the file Doc/library/operator.rst.

I have included the patch for the changeset 57209.

----------
assignee: docs at python
components: Documentation
files: operator_div.patch
keywords: patch
messages: 154277
nosy: docs at python, felixantoinefortin
priority: normal
severity: normal
status: open
title: operator: div() instead of truediv() in documention since 3.1.2
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file24639/operator_div.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14122>
_______________________________________

From report at bugs.python.org  Sat Feb 25 18:51:41 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 25 Feb 2012 17:51:41 +0000
Subject: [issue14122] operator: div() instead of truediv() in documention
	since 3.1.2
In-Reply-To: <1330190947.0.0.577940760696.issue14122@psf.upfronthosting.co.za>
Message-ID: <1330192301.82.0.22073694279.issue14122@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> patch review
type:  -> enhancement
versions:  -Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14122>
_______________________________________

From report at bugs.python.org  Sat Feb 25 19:16:35 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 25 Feb 2012 18:16:35 +0000
Subject: [issue14118] _pickle.c structure cleanup
In-Reply-To: <1330126686.15.0.366051703347.issue14118@psf.upfronthosting.co.za>
Message-ID: <1330193795.54.0.397901750363.issue14118@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the effort, but I'm rejecting this now. I'm not fundamentally opposed to restructing this code, but I do think that your change would be a slight loss of readability. If you absolutely cannot stand working with such a large code, please try to find supporters of a change on python-dev.

Wrt. your actual approach: this is somewhat uncoommon. If you have many files, you'd rather expect them to be integrated in the build process (i.e. with Makefile and VS project file changes) rather than recursive includes.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14118>
_______________________________________

From report at bugs.python.org  Sat Feb 25 19:32:30 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Feb 2012 18:32:30 +0000
Subject: [issue14120] ARM Ubuntu 3.x buildbot failing test_dbm
In-Reply-To: <1330159520.1.0.928033022024.issue14120@psf.upfronthosting.co.za>
Message-ID: <1330194750.65.0.771976257922.issue14120@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/issue14120>
_______________________________________

From report at bugs.python.org  Sat Feb 25 19:35:40 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 25 Feb 2012 18:35:40 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1330189417.3400.4.camel@localhost.localdomain>
Message-ID: <20120225183538.GA26857@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

What happens is that if self._fill_cache() is called, cache_module='pep3147'
and cache={'pep3147'}. Then 'cache_module in cache' is true and the function
returns:

    loader('pep3147', './pep3147/__init__.py')

Otherwise, find_module() returns None, control is handed back to
find_module_path() ...

    loader = _PyObject_CallMethodId(importer, &PyId_find_module, "O", fullname)

... and then to find_module_path_list(), where the search continues:

    for (i = 0; i < npath; i++) {
        path = PyList_GetItem(search_path_list, i);
        ...

search_path_list = ['.', '', ... ], but now i==1, so the dot is disregarded
and '' is used as the path, leading to the dotless result.

I don't know the contract for importlib's find_module, but it seems to me
that either find_module should handle this case or we have an unwanted
interaction between C and Python code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Sat Feb 25 19:41:23 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Feb 2012 18:41:23 +0000
Subject: [issue13999] Queue references in multiprocessing doc points to Queue
	module and not to self
In-Reply-To: <1329072364.23.0.444581618774.issue13999@psf.upfronthosting.co.za>
Message-ID: <E1S1MYb-0003RV-Ta@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5d4f2f994f75 by Sandro Tosi in branch '2.7':
Issue #13999: refer to multiprocessing.Queue when needed
http://hg.python.org/cpython/rev/5d4f2f994f75

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13999>
_______________________________________

From report at bugs.python.org  Sat Feb 25 19:41:53 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Feb 2012 18:41:53 +0000
Subject: [issue13999] Queue references in multiprocessing doc points to Queue
	module and not to self
In-Reply-To: <1329072364.23.0.444581618774.issue13999@psf.upfronthosting.co.za>
Message-ID: <1330195313.11.0.379348471728.issue13999@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13999>
_______________________________________

From report at bugs.python.org  Sat Feb 25 19:48:48 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Feb 2012 18:48:48 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <20120225183538.GA26857@sleipnir.bytereef.org>
Message-ID: <1330195511.3400.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> What happens is that if self._fill_cache() is called, cache_module='pep3147'
> and cache={'pep3147'}. Then 'cache_module in cache' is true and the function
> returns:
> 
>     loader('pep3147', './pep3147/__init__.py')
> 
> Otherwise, find_module() returns None, control is handed back to
> find_module_path() ...

Ah, thanks. So the test needs to be fixed to call
importlib.invalidate_caches() after creating the module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Sat Feb 25 20:36:22 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Sat, 25 Feb 2012 19:36:22 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2 and
	python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1330198582.52.0.139892163557.issue6784@psf.upfronthosting.co.za>


Merlijn van Deen <valhallasw at gmail.com> added the comment:

Ok, this is my first attempt at the Pickler part of the C implementation. I'll have to adapt the python implementation to match this one.

All BytestrPicklerTests in test_bytestrpickle.py pass, and ./python -m test -G -v test_pickle passes.

Comments on style etc. are very welcome.

----------
Added file: http://bugs.python.org/file24640/BytestrPickler_c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Sat Feb 25 21:48:49 2012
From: report at bugs.python.org (Christine Jones)
Date: Sat, 25 Feb 2012 20:48:49 +0000
Subject: [issue14123] Doc change re old and new string formatting
Message-ID: <1330202928.96.0.727285588049.issue14123@psf.upfronthosting.co.za>


New submission from Christine Jones <silly.english.knights at gmail.com>:

Change to this http://docs.python.org/py3k/library/stdtypes.html as suggested by Nick Coghlan here http://www.gossamer-threads.com/lists/python/dev/969817

"The formatting operations described here are modelled on C's printf()
syntax. They only support formatting of certain builtin types, and the
use of a binary operator means that care may be needed in order to
format tuples and dictionaries correctly. As the new string formatting
syntax is more powerful, flexible, extensible and handles tuples and
dictionaries naturally, it is recommended for new code. However, there
are no current plans to deprecate printf-style formatting."

----------
assignee: docs at python
components: Documentation
messages: 154283
nosy: docs at python, telephonebook
priority: normal
severity: normal
status: open
title: Doc change re old and new string formatting

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14123>
_______________________________________

From report at bugs.python.org  Sat Feb 25 21:56:03 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Sat, 25 Feb 2012 20:56:03 +0000
Subject: [issue14124] _pickle.c comment/documentation improvement
Message-ID: <1330203362.98.0.289163571674.issue14124@psf.upfronthosting.co.za>


New submission from Merlijn van Deen <valhallasw at gmail.com>:

As suggested by loewis in msg154233, I created some documentation to help people get started with _pickle.c.

----------
assignee: docs at python
components: Documentation, Extension Modules
files: _pickle_c_doc.diff
keywords: patch
messages: 154284
nosy: docs at python, valhallasw
priority: normal
severity: normal
status: open
title: _pickle.c comment/documentation improvement
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file24641/_pickle_c_doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14124>
_______________________________________

From report at bugs.python.org  Sat Feb 25 21:56:39 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Sat, 25 Feb 2012 20:56:39 +0000
Subject: [issue14124] _pickle.c comment/documentation improvement
In-Reply-To: <1330203362.98.0.289163571674.issue14124@psf.upfronthosting.co.za>
Message-ID: <1330203399.76.0.422615271027.issue14124@psf.upfronthosting.co.za>


Changes by Merlijn van Deen <valhallasw at gmail.com>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14124>
_______________________________________

From report at bugs.python.org  Sat Feb 25 22:04:24 2012
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 25 Feb 2012 21:04:24 +0000
Subject: [issue14123] Doc change re old and new string formatting
In-Reply-To: <1330202928.96.0.727285588049.issue14123@psf.upfronthosting.co.za>
Message-ID: <1330203864.82.0.61073506947.issue14123@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14123>
_______________________________________

From report at bugs.python.org  Sat Feb 25 22:09:41 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Sat, 25 Feb 2012 21:09:41 +0000
Subject: [issue14123] Doc change re old and new string formatting
In-Reply-To: <1330202928.96.0.727285588049.issue14123@psf.upfronthosting.co.za>
Message-ID: <1330204181.22.0.519129263851.issue14123@psf.upfronthosting.co.za>


Changes by Glenn Linderman <v+python at g.nevcal.com>:


----------
nosy: +v+python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14123>
_______________________________________

From report at bugs.python.org  Sat Feb 25 23:11:24 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 25 Feb 2012 22:11:24 +0000
Subject: [issue14112] tutorial intro talks of "shallow copy" concept without
	explanation
In-Reply-To: <1330113005.05.0.0872009811322.issue14112@psf.upfronthosting.co.za>
Message-ID: <1330207884.28.0.757357127524.issue14112@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

"shallow copy" and "deep copy" are both standard computer science terms by no means unique to or invented by Python.  We should be cautious about documentation bloat and trying to redefine standard terms.

http://en.wikipedia.org/wiki/Object_copy#Shallow_copy

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14112>
_______________________________________

From report at bugs.python.org  Sat Feb 25 23:30:54 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 25 Feb 2012 22:30:54 +0000
Subject: [issue14120] ARM Ubuntu 3.x buildbot failing test_dbm
In-Reply-To: <1330194750.7.0.914455492745.issue14120@psf.upfronthosting.co.za>
Message-ID: <20120225173048.1e54a1dc@resist.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

I was missing libgdbm-dev on that machine.  I just installed it and am running
the buildbottests by hand.  Let's see if that fixes things.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14120>
_______________________________________

From report at bugs.python.org  Sat Feb 25 23:47:31 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 25 Feb 2012 22:47:31 +0000
Subject: [issue14125] Windows: failures in refleak mode
Message-ID: <1330210051.4.0.773065627544.issue14125@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

The following tests fail on Windows in refleak mode. I used
24ca28cc9c9c as a reference point. Build is x64. Summary:

test_concurrent_futures, test_datetime, test_multiprocessing, test_strftime and test_time are leaking.



C:\Users\stefan\hg\master\PCbuild>amd64\python_d.exe -m test -uall -R :: test_multiprocessing              
[1/1] test_multiprocessing                                                                                 
beginning 9 repetitions                                                                                    
123456789                                                                                                  
.........                                                                                                  
test_multiprocessing leaked [3, 3, 3, 3] references, sum=12                                                
Warning -- multiprocessing.process._dangling was modified by test_multiprocessing                          
1 test failed:                                                                                             
    test_multiprocessing                                                                                   
[172456 refs]


C:\Users\stefan\hg\master\PCbuild>amd64\python_d.exe -m test -uall -R :: test_concurrent_futures           
[1/1] test_concurrent_futures                                                                              
beginning 9 repetitions                                                                                    
123456789                                                                                                  
.........                                                                                                  
test_concurrent_futures leaked [1524, 1518, 1524, 1524] references, sum=6090                               
1 test failed:                                                                                             
    test_concurrent_futures                                                                                
[170398 refs]                                                                                              
                     

C:\Users\stefan\hg\master\PCbuild>amd64\python_d.exe -m test -uall -R :: test_datetime                     
[1/1] test_datetime                                                                                        
beginning 9 repetitions                                                                                    
123456789                                                                                                  
.........                                                                                                  
test_datetime leaked [20, 20, 20, 20] references, sum=80                                                   
1 test failed:                                                                                             
    test_datetime                                                                                          
[191763 refs]                                                                                            



C:\Users\stefan\hg\master\PCbuild>amd64\python_d.exe -m test -uall -R :: test_strftime                     
[1/1] test_strftime                                                                                        
beginning 9 repetitions                                                                                    
123456789                                                                                                  
.........                                                                                                  
test_strftime leaked [2761, 2761, 2761, 2761] references, sum=11044                                        
1 test failed:                                                                                             
    test_strftime                                                                                          
[170275 refs]                                                                                          


C:\Users\stefan\hg\master\PCbuild>amd64\python_d.exe -m test -uall -R :: test_time                         
[1/1] test_time                                                                                            
beginning 9 repetitions                                                                                    
123456789                                                                                                  
.........                                                                                                  
test_time leaked [1, 1, 1, 1] references, sum=4                                                            
1 test failed:                                                                                             
    test_time                                                                                              
[144556 refs]

----------
messages: 154287
nosy: skrah
priority: normal
severity: normal
status: open
title: Windows: failures in refleak mode
type: resource usage
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14125>
_______________________________________

From report at bugs.python.org  Sun Feb 26 00:29:27 2012
From: report at bugs.python.org (Alex Gaynor)
Date: Sat, 25 Feb 2012 23:29:27 +0000
Subject: [issue14126] Speed up list comprehensions by preallocating the list
	where possible
Message-ID: <1330212567.11.0.0699848649478.issue14126@psf.upfronthosting.co.za>


New submission from Alex Gaynor <alex.gaynor at gmail.com>:

This adds a new opcode which for certain list comprehensions (ones with no if statements and only a single comprehension), preallocates the list to the appropriate size.

Patch is against 2.7, because it was a bit easier.  On:


def f():
    for i in range(10000):
        [j for j in range(10000)]

f()


Here's the speedup:


alex at alex-gaynor-laptop:/tmp$ # Fresh 2.7 branch
alex at alex-gaynor-laptop:/tmp$ time ~/projects/cpython/python t.py 

real	0m6.418s
user	0m6.408s
sys	0m0.004s
alex at alex-gaynor-laptop:/tmp$ time ~/projects/cpython/python t.py 

real	0m5.670s
user	0m5.648s
sys	0m0.008s
alex at alex-gaynor-laptop:/tmp$ time ~/projects/cpython/python t.py 

real	0m5.688s
user	0m5.672s
sys	0m0.008s
alex at alex-gaynor-laptop:/tmp$ time ~/projects/cpython/python t.py 

real	0m5.688s
user	0m5.676s
sys	0m0.004s
alex at alex-gaynor-laptop:/tmp$ time ~/projects/cpython/python t.py 

real	0m5.690s
user	0m5.684s
sys	0m0.000s
alex at alex-gaynor-laptop:/tmp$ 
alex at alex-gaynor-laptop:/tmp$ 
alex at alex-gaynor-laptop:/tmp$ # With patch
alex at alex-gaynor-laptop:/tmp$ time ~/projects/cpython/python t.py 

real	0m6.085s
user	0m6.064s
sys	0m0.008s
alex at alex-gaynor-laptop:/tmp$ time ~/projects/cpython/python t.py 

real	0m5.728s
user	0m5.720s
sys	0m0.004s
alex at alex-gaynor-laptop:/tmp$ time ~/projects/cpython/python t.py 

real	0m5.783s
user	0m5.772s
sys	0m0.004s
alex at alex-gaynor-laptop:/tmp$ time ~/projects/cpython/python t.py 

real	0m4.730s
user	0m4.716s
sys	0m0.008s
alex at alex-gaynor-laptop:/tmp$ time ~/projects/cpython/python t.py 

real	0m4.691s
user	0m4.680s
sys	0m0.004s

----------
components: Interpreter Core
files: preallocate.diff
keywords: patch
messages: 154288
nosy: alex
priority: normal
severity: normal
status: open
title: Speed up list comprehensions by preallocating the list where possible
versions: Python 3.4
Added file: http://bugs.python.org/file24642/preallocate.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14126>
_______________________________________

From report at bugs.python.org  Sun Feb 26 00:34:47 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Feb 2012 23:34:47 +0000
Subject: [issue14126] Speed up list comprehensions by preallocating the list
	where possible
In-Reply-To: <1330212567.11.0.0699848649478.issue14126@psf.upfronthosting.co.za>
Message-ID: <1330212887.7.0.495379203082.issue14126@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/issue14126>
_______________________________________

From report at bugs.python.org  Sun Feb 26 00:49:46 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 25 Feb 2012 23:49:46 +0000
Subject: [issue14123] Doc change re old and new string formatting
In-Reply-To: <1330202928.96.0.727285588049.issue14123@psf.upfronthosting.co.za>
Message-ID: <1330213786.03.0.84647119798.issue14123@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14123>
_______________________________________

From report at bugs.python.org  Sun Feb 26 01:02:10 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 26 Feb 2012 00:02:10 +0000
Subject: [issue14112] tutorial intro talks of "shallow copy" concept without
	explanation
In-Reply-To: <1330207884.28.0.757357127524.issue14112@psf.upfronthosting.co.za>
Message-ID: <CAA77j2CpdqJCfp3aDPpEB5f6tZ6h5w1ktGamTkMQHJ8qcOK-Dw@mail.gmail.com>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

On Sun, Feb 26, 2012 at 00:11, Ned Deily <report at bugs.python.org> wrote:
> "shallow copy" and "deep copy" are both standard computer science terms by no means unique to or invented by Python. ?We should be cautious about documentation bloat and trying to redefine standard terms.
>
> http://en.wikipedia.org/wiki/Object_copy#Shallow_copy

Do they mean exactly the same thing in Python as what Wikipedia says?
In that case, are links to Wikipedia allowed?

Anyways, some explanation (or link) would be needed since many people
without a background in computer science are going to read the
tutorial. I think the term is not common enough that it can be taken
for granted that newbies to Python (readers of the tutorial) will know
it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14112>
_______________________________________

From report at bugs.python.org  Sun Feb 26 01:03:53 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 26 Feb 2012 00:03:53 +0000
Subject: [issue14123] Indicate that there are no current plans to deprecate
	printf-style formatting
In-Reply-To: <1330202928.96.0.727285588049.issue14123@psf.upfronthosting.co.za>
Message-ID: <1330214633.57.0.47379506339.issue14123@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
title: Doc change re old and new string formatting -> Indicate that there are no current plans to deprecate printf-style formatting

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14123>
_______________________________________

From report at bugs.python.org  Sun Feb 26 01:12:04 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Feb 2012 00:12:04 +0000
Subject: [issue14112] tutorial intro talks of "shallow copy" concept without
	explanation
In-Reply-To: <1330113005.05.0.0872009811322.issue14112@psf.upfronthosting.co.za>
Message-ID: <1330215124.9.0.232389966166.issue14112@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

'Shallow' is a common English word: "Stay in shallow water until you learn to swim!" But that is not the issue here.

I think the underlying issue is that the first sentence "All slice operations return a new list containing the requested elements." is wrong. Python lists, like shopping lists, do not 'contain' objects. Both contain references to objects (copies of their identifieres) and thereby define an abstract collection. A shallow copy of a collection object copies references (ids). A deep copy also copies objects themselves. (The Wikipedia article says much the same, but to me much less clearly.) 

If we start with a true sentence "Slice operations return a new list containing references to a subsequence of the original elements." or "Slice operations return a new list that defines a subsequence of the original sequence of objects", then I do not think more *needs* to be said. We could optionally add "Since no objects are copied, slices are shallow copies." both to emphasize that no objects are copied and to introduced the notion of shallow copy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14112>
_______________________________________

From report at bugs.python.org  Sun Feb 26 01:27:20 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 26 Feb 2012 00:27:20 +0000
Subject: [issue14075] argparse: unused method?
In-Reply-To: <1329848199.77.0.390599674253.issue14075@psf.upfronthosting.co.za>
Message-ID: <1330216040.58.0.509055771935.issue14075@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

It's undocumented, and it begins with an underscore, but it would certainly be safer to deprecate it first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14075>
_______________________________________

From report at bugs.python.org  Sun Feb 26 01:49:30 2012
From: report at bugs.python.org (Geoffrey Spear)
Date: Sun, 26 Feb 2012 00:49:30 +0000
Subject: [issue14075] argparse: unused method?
In-Reply-To: <1329848199.77.0.390599674253.issue14075@psf.upfronthosting.co.za>
Message-ID: <1330217370.76.0.199929059236.issue14075@psf.upfronthosting.co.za>


Geoffrey Spear <geoffspear at gmail.com> added the comment:

If people do override this provate method, would they really bother calling super() to get the essentially no-op functionality of the superclass method? 

FWIW, Google Code and github both seem to be free of any such code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14075>
_______________________________________

From report at bugs.python.org  Sun Feb 26 03:07:58 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Feb 2012 02:07:58 +0000
Subject: [issue14112] tutorial intro talks of "shallow copy" concept without
	explanation
In-Reply-To: <1330113005.05.0.0872009811322.issue14112@psf.upfronthosting.co.za>
Message-ID: <1330222078.03.0.703239054724.issue14112@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, the shallow/deep terminology is not unique to Python and is commonly used in computer science.

In my experience teaching Python, the terms are somewhat self-descriptive and only become perplexing when someone over-explains them.

That said, a glossary entry is appropriate.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14112>
_______________________________________

From report at bugs.python.org  Sun Feb 26 03:16:28 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Feb 2012 02:16:28 +0000
Subject: [issue14126] Speed up list comprehensions by preallocating the list
	where possible
In-Reply-To: <1330212567.11.0.0699848649478.issue14126@psf.upfronthosting.co.za>
Message-ID: <1330222588.43.0.735125137148.issue14126@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
priority: normal -> low
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14126>
_______________________________________

From report at bugs.python.org  Sun Feb 26 03:34:47 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Feb 2012 02:34:47 +0000
Subject: [issue14123] Indicate that there are no current plans to deprecate
	printf-style formatting
In-Reply-To: <1330202928.96.0.727285588049.issue14123@psf.upfronthosting.co.za>
Message-ID: <1330223687.71.0.839921136201.issue14123@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?d like to make a patch with Nick?s text and a few examples.

----------
assignee: docs at python -> eric.araujo
nosy: +eric.araujo, ncoghlan
stage:  -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14123>
_______________________________________

From report at bugs.python.org  Sun Feb 26 03:47:39 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Feb 2012 02:47:39 +0000
Subject: [issue13770] python3 & json: add ensure_ascii documentation
In-Reply-To: <1326300131.17.0.750918490995.issue13770@psf.upfronthosting.co.za>
Message-ID: <1330224459.89.0.154590865656.issue13770@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

json in 2.7 works a bit differently; ensure_ascii is already documented there.  Closing, please reopen if the new doc is not to your satisfaction.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13770>
_______________________________________

From report at bugs.python.org  Sun Feb 26 03:49:08 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Feb 2012 02:49:08 +0000
Subject: [issue13467] Typo in doc for library/sysconfig
In-Reply-To: <1322102306.14.0.426447482004.issue13467@psf.upfronthosting.co.za>
Message-ID: <E1S1UAc-0003kO-H7@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c78b41fa5258 by ?ric Araujo in branch '2.7':
Fix typo (#13467)
http://hg.python.org/cpython/rev/c78b41fa5258

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13467>
_______________________________________

From report at bugs.python.org  Sun Feb 26 03:49:08 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Feb 2012 02:49:08 +0000
Subject: [issue2945] bdist_rpm does not list dist files (should effect upload)
In-Reply-To: <1211466871.95.0.658180804984.issue2945@psf.upfronthosting.co.za>
Message-ID: <E1S1UAc-0003kO-CL@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f606d722ca23 by ?ric Araujo in branch '2.7':
Stop ignoring RPMs in distutils' upload command (#2945).
http://hg.python.org/cpython/rev/f606d722ca23

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2945>
_______________________________________

From report at bugs.python.org  Sun Feb 26 03:49:09 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Feb 2012 02:49:09 +0000
Subject: [issue13716] distutils doc contains lots of XXX
In-Reply-To: <1325790136.17.0.881224521536.issue13716@psf.upfronthosting.co.za>
Message-ID: <E1S1UAc-0003kO-HE@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e853ea9efc6e by ?ric Araujo in branch '2.7':
Hide or remove user-visible XXX notes from distutils doc (#13716).
http://hg.python.org/cpython/rev/e853ea9efc6e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13716>
_______________________________________

From report at bugs.python.org  Sun Feb 26 03:49:09 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Feb 2012 02:49:09 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <E1S1UAc-0003kO-Gz@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7c22281e967c by ?ric Araujo in branch '2.7':
Improve interlinking of archiving/compression modules docs.
http://hg.python.org/cpython/rev/7c22281e967c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Sun Feb 26 03:49:56 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Feb 2012 02:49:56 +0000
Subject: [issue1040439] Missing documentation on how to link with libpython
Message-ID: <1330224596.07.0.137920948192.issue1040439@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is there any reason not to backport to 2.7?  (Yes, I?m volunteering.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040439>
_______________________________________

From report at bugs.python.org  Sun Feb 26 03:58:54 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Feb 2012 02:58:54 +0000
Subject: [issue3445] Ignore missing attributes in functools.update_wrapper
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1330225134.0.0.663815324416.issue3445@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Well, Nick judged that this was not a bug per se, but rather a request for enhancement, thus it was only committed to 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3445>
_______________________________________

From report at bugs.python.org  Sun Feb 26 04:06:38 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Feb 2012 03:06:38 +0000
Subject: [issue14075] argparse: unused method?
In-Reply-To: <1329848199.77.0.390599674253.issue14075@psf.upfronthosting.co.za>
Message-ID: <1330225598.39.0.259560450092.issue14075@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> It's undocumented, and it begins with an underscore, but it would certainly be safer
> to deprecate it first.

Ah, somehow I misunderstood your earlier comment and thought _get_args had been publicized.  Removing is safe then.

Geoffrey:
> If people do override this provate method, would they really bother calling super()
> to get the essentially no-op functionality of the superclass method? 
No, but they would expect __repr__ to use their _get_args, which it won?t after the removal (see the patch).

> FWIW, Google Code and github both seem to be free of any such code.
Thanks for checking.  It?s only a fraction of all code out there, but it?s an indicator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14075>
_______________________________________

From report at bugs.python.org  Sun Feb 26 04:07:49 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Feb 2012 03:07:49 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <E1S1USi-0005hi-3e@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 937b1613d0e6 by ?ric Araujo in branch 'default':
Port the #6884 fix to packaging
http://hg.python.org/cpython/rev/937b1613d0e6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sun Feb 26 04:07:49 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Feb 2012 03:07:49 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>
Message-ID: <E1S1USi-0005hi-3X@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2887f5a97075 by ?ric Araujo in branch '3.2':
Add test file for scripts in Tools (#13447).
http://hg.python.org/cpython/rev/2887f5a97075

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Sun Feb 26 04:12:54 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Feb 2012 03:12:54 +0000
Subject: [issue2945] bdist_rpm does not list dist files (should effect upload)
In-Reply-To: <1211466871.95.0.658180804984.issue2945@psf.upfronthosting.co.za>
Message-ID: <1330225974.51.0.979390196916.issue2945@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Fixed in 2.7 too, thanks to you both.  If you have the time to run the tests, it would be great to get a confirmation (I?m not sure we have a buildbot with rpm installed for 2.7).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2945>
_______________________________________

From report at bugs.python.org  Sun Feb 26 04:20:39 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Feb 2012 03:20:39 +0000
Subject: [issue13447] Add tests for some scripts in Tools/scripts
In-Reply-To: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>
Message-ID: <1330226439.59.0.413578598821.issue13447@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I meant "Test for Tools" instead of """Tests for reindent.py.""" 
Looks like you missed the message where I wrote how I changed s/reindent.py/scripts in the Tools directory/

Committed!  Now we can tackle all these nasty pygettext and msgfmt bugs, and I will also add tests for the fixes that were done the last months.

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Sun Feb 26 04:21:50 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Feb 2012 03:21:50 +0000
Subject: [issue13716] distutils doc contains lots of XXX
In-Reply-To: <1325790136.17.0.881224521536.issue13716@psf.upfronthosting.co.za>
Message-ID: <1330226510.83.0.645283472171.issue13716@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Done.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13716>
_______________________________________

From report at bugs.python.org  Sun Feb 26 04:37:04 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Feb 2012 03:37:04 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1330227424.87.0.200680666874.issue6884@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve ported the fix to packaging without testing, the buildbots will shout at me if I made a mistake.  For distutils2 however I have no tester and no bot, so could someone test this patch?  (repo is at http://hg.python.org/distutils2)

BTW if someone knows about a continuous integration service which provides Windows and Mac OS X VMs I?m all ears.

----------
Added file: http://bugs.python.org/file24643/fix-distutils2-manifest-bugs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sun Feb 26 07:28:12 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Feb 2012 06:28:12 +0000
Subject: [issue13224] Change str(x) to return only the (qual)name for some
	types
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1330237692.01.0.0805282530587.issue13224@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ping: I?d like opinions on the request in my last message;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Sun Feb 26 08:32:35 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 26 Feb 2012 07:32:35 +0000
Subject: [issue14107] Debian bigmem buildbot hanging in test_bigmem
In-Reply-To: <1330096646.48.0.414006184823.issue14107@psf.upfronthosting.co.za>
Message-ID: <1330241555.71.0.408656669467.issue14107@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

The buildbot still isn't happy:

    http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/144/steps/test/logs/stdio

Also, I ran the test on my own machine and noticed two tests that are
still exceeding their nominal peak memory usage:

- test_encode_utf7: expected 4.8G, actual 7.2G

- test_unicode_repr: expected 4.8G, actual 5.6G

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14107>
_______________________________________

From report at bugs.python.org  Sun Feb 26 08:40:08 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Feb 2012 07:40:08 +0000
Subject: [issue14081] Allow "maxsplit" argument to str.split() to be passed as
	a keyword argument
In-Reply-To: <1329875650.41.0.375574316124.issue14081@psf.upfronthosting.co.za>
Message-ID: <E1S1YiF-0001af-6F@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset db968ac2b82c by Ezio Melotti in branch 'default':
#14081: The sep and maxsplit parameter to str.split, bytes.split, and bytearray.split may now be passed as keyword arguments.
http://hg.python.org/cpython/rev/db968ac2b82c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14081>
_______________________________________

From report at bugs.python.org  Sun Feb 26 08:44:15 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 26 Feb 2012 07:44:15 +0000
Subject: [issue14081] Allow "maxsplit" argument to str.split() to be passed as
	a keyword argument
In-Reply-To: <1329875650.41.0.375574316124.issue14081@psf.upfronthosting.co.za>
Message-ID: <1330242255.49.0.790654078143.issue14081@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed!
Thanks for the reviews and for spotting the extra '['.
(While suggesting the use of maxsplit, be aware that str.split uses -1 as default value, whereas re.split uses 0.)

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14081>
_______________________________________

From report at bugs.python.org  Sun Feb 26 09:03:00 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Feb 2012 08:03:00 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <E1S1Z4N-00031L-95@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b299c4f31ff2 by Nick Coghlan in branch 'default':
Close issue #6210: Implement PEP 409
http://hg.python.org/cpython/rev/b299c4f31ff2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Sun Feb 26 09:04:31 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 26 Feb 2012 08:04:31 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1330243471.08.0.972077964498.issue6210@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Sun Feb 26 09:07:21 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 26 Feb 2012 08:07:21 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
In-Reply-To: <1313884051.29.0.336736419117.issue12801@psf.upfronthosting.co.za>
Message-ID: <1330243641.46.0.188944388804.issue12801@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/issue12801>
_______________________________________

From report at bugs.python.org  Sun Feb 26 09:08:07 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 26 Feb 2012 08:08:07 +0000
Subject: [issue14082] shutil doesn't copy extended attributes
In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za>
Message-ID: <1330243687.02.0.701008812758.issue14082@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/issue14082>
_______________________________________

From report at bugs.python.org  Sun Feb 26 09:13:40 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Feb 2012 08:13:40 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1330244020.81.0.0872191502631.issue6210@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks, I can?t wait to use that in my code!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Sun Feb 26 09:49:49 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 26 Feb 2012 08:49:49 +0000
Subject: [issue14097] Improve the "introduction" page of the tutorial
In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>
Message-ID: <1330246189.45.0.173614555011.issue14097@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Regarding the use of the name "variable", could it be replaced by just "name" ? That might make sense since the error for undefined "names" is usually NameError. However, note that the current documentation has a /huge/ amount of mentions for "variable", so we may be too late to the party.

?ric - the word "degenerate" is considered offensive in a couple of languages I speak, but the docs are written in English, so the important point is whether this word is offensive *in English*. If not, I see no reason to drop it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14097>
_______________________________________

From report at bugs.python.org  Sun Feb 26 10:23:22 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 26 Feb 2012 09:23:22 +0000
Subject: [issue14127] os.stat and os.utime: allow preserving exact metadata
Message-ID: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

Following on from Guido's rejection of PEP 410:
http://mail.python.org/pipermail/python-dev/2012-February/116837.html

This bug is the proposed hammering-out space for how to preserve exact metadata for st_atime / st_mtime between os.stat and os.utime.

(Yes, there's already #11457 -- but that went pretty far down the rabbit hole of Decimal.  I thought maybe a fresh start would be best.)

----------
components: Library (Lib)
messages: 154316
nosy: larry
priority: normal
severity: normal
status: open
title: os.stat and os.utime: allow preserving exact metadata
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14127>
_______________________________________

From report at bugs.python.org  Sun Feb 26 10:30:20 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 26 Feb 2012 09:30:20 +0000
Subject: [issue14128] _elementtree should expose types and factory functions
	consistently with ElementTree
Message-ID: <1330248620.3.0.71621144947.issue14128@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

Element, XMLParser and TreeBuilder are types in ElementTree, but factory functions in _elementtree. The latter should be modified to be consistent with the former.

----------
assignee: eli.bendersky
components: Library (Lib)
messages: 154317
nosy: eli.bendersky, flox, scoder
priority: high
severity: normal
stage: needs patch
status: open
title: _elementtree should expose types and factory functions consistently with ElementTree
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14128>
_______________________________________

From report at bugs.python.org  Sun Feb 26 10:36:00 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 26 Feb 2012 09:36:00 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1330248960.52.0.924119942351.issue6884@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> For distutils2 however I have no tester and no bot, so could someone test this patch?

I'll take a look at it.


> BTW if someone knows about a continuous integration service which provides Windows and Mac OS X VMs I?m all ears.

Not sure about a CI service, but if you want Windows for your own machine
I believe you can get a free MSDN subscription:

    http://mail.python.org/pipermail/python-committers/2011-August/001788.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sun Feb 26 10:43:00 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 26 Feb 2012 09:43:00 +0000
Subject: [issue14127] os.stat and os.utime: allow preserving exact metadata
In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za>
Message-ID: <1330249380.09.0.180670547793.issue14127@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Guido proposed st_atime_ns et al.  I'll make an alternate proposal.

I'd like to avoid tying ourselves to ns resolution.  As MvL said: "I don't want to deal with this issue *again* in my lifetime".

If all we want is to facilitate copying the exact metadata from os.stat to os.utime, then we don't really care about conveniently modifying the timestamp.  So I propose we use MvL's suggestion of a tuple of ints.  Either (numerator, denominator) or (seconds, fractional_numerator, fractional_denominator).  (These are mentioned in PEP 410 under the heading "Tuple of ints" as options A and B respectively.)  Name the fields with the suffix "_exact" (e.g. st_mtime_exact).  os.stat and its ilk produce it; os.utime and its ilk consume it.  If people want to monkey with the values and do math, let 'em--consenting adults.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14127>
_______________________________________

From report at bugs.python.org  Sun Feb 26 10:44:39 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 26 Feb 2012 09:44:39 +0000
Subject: [issue14128] _elementtree should expose types and factory functions
	consistently with ElementTree
In-Reply-To: <1330248620.3.0.71621144947.issue14128@psf.upfronthosting.co.za>
Message-ID: <1330249479.95.0.996603286661.issue14128@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/issue14128>
_______________________________________

From report at bugs.python.org  Sun Feb 26 10:54:57 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Feb 2012 09:54:57 +0000
Subject: [issue14123] Indicate that there are no current plans to deprecate
	printf-style formatting
In-Reply-To: <1330202928.96.0.727285588049.issue14123@psf.upfronthosting.co.za>
Message-ID: <E1S1aoh-0001gI-CA@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 80069bbae26d by Gregory P. Smith in branch '3.2':
Issue #14123: Explicitly mention that old style % string formatting has caveats
http://hg.python.org/cpython/rev/80069bbae26d

New changeset 98a1855ebfe1 by Gregory P. Smith in branch 'default':
Issue #14123: Explicitly mention that old style % string formatting has caveats but is not going away any time soon.
http://hg.python.org/cpython/rev/98a1855ebfe1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14123>
_______________________________________

From report at bugs.python.org  Sun Feb 26 11:21:32 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 26 Feb 2012 10:21:32 +0000
Subject: [issue14128] _elementtree should expose types and factory functions
	consistently with ElementTree
In-Reply-To: <1330248620.3.0.71621144947.issue14128@psf.upfronthosting.co.za>
Message-ID: <4F4A06F6.5030106@users.sourceforge.net>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Note that Element is also a factory function in lxml.etree, and people have
been living with this quite happily. I don't see a reason to change either
side. There is a dedicated function iselement(obj) for exactly the purpose
of testing if something is an Element object. isinstance() is not the right
way to do it and inheritance is not portable. (the right type to inherit
from in lxml is actually called ElementBase)

I'm fine with changing the other two (XMLParser and TreeBuilder), if only
for consistency.

Stefan

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14128>
_______________________________________

From report at bugs.python.org  Sun Feb 26 11:28:56 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 26 Feb 2012 10:28:56 +0000
Subject: [issue14128] _elementtree should expose types and factory functions
	consistently with ElementTree
In-Reply-To: <1330248620.3.0.71621144947.issue14128@psf.upfronthosting.co.za>
Message-ID: <1330252136.36.0.22555303651.issue14128@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

In the pydev discussion once Martin raised this problem it was agreed that this is a regression in 3.3 that should be fixed, since there is code out there that relies on subclassing Element. This would make the Python and C implementations of ET more consistent, which can't be a bad thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14128>
_______________________________________

From report at bugs.python.org  Sun Feb 26 11:30:34 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 26 Feb 2012 10:30:34 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1330104346.67.0.33461489946.issue10181@psf.upfronthosting.co.za>
Message-ID: <20120226102704.GA32450@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Nick Coghlan <report at bugs.python.org> wrote:
> PEP section makes sense - I plan to mark PEP 3118 as Final once you commit
> this (or you can do that yourself, for that matter).

Array features are complete except for multi-dimensional indexing and slicing.
I think it would be nice to add those in a separate issue; it's not a lot of
additional code and it doesn't interfere with the current code.

The overall array handling scheme is sound. Life would be a bit easier
if contiguity flags were a mandatory part of the Py_buffer structure
that the exporter has to fill in.

Then there is an open issue (#3132) for expanding the struct module syntax,
where the wording in some sections of the PEP led to a bit of head-scratching. :)

In another issue (#13072) the question came up whether the proposed 'u' and 'w'
formats still make sense after PEP-393 (I think they do, they should map to
UCS-2 and UCS-4).

We need to decide what to do about 2.7 and 3.2. It's pretty difficult by
now to separate the bug fixes from the features. I could follow the example
of CPU manufacturers: start with the whole feature set and disable as much
as possible.

Another problem for 2.7 and 3.2 is that the 'B' format would still need to
accept bytes instead of ints. Or can we change that as a bug fix?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Feb 26 11:42:24 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 26 Feb 2012 10:42:24 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1330252944.52.0.536955551968.issue2394@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I think this issue is now superseded by #10181 and #3132.

----------
nosy: +skrah
resolution:  -> duplicate
stage: test needed -> committed/rejected
status: open -> pending
superseder:  -> Problems with Py_buffer management in memoryobject.c (and elsewhere?)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Sun Feb 26 11:42:35 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 26 Feb 2012 10:42:35 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1330252955.66.0.558070606286.issue2394@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Sun Feb 26 12:08:58 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 26 Feb 2012 11:08:58 +0000
Subject: [issue14129] Corrections for the "extending" doc
Message-ID: <1330254538.51.0.802028199864.issue14129@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

I'm now carefully reading through the "extending" documentation pages. This issue will record various problems I find on the way, with the intention of fixing them eventually.

----------
assignee: eli.bendersky
components: Documentation
keywords: easy
messages: 154325
nosy: eli.bendersky
priority: low
severity: normal
status: open
title: Corrections for the "extending" doc
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14129>
_______________________________________

From report at bugs.python.org  Sun Feb 26 12:09:32 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 26 Feb 2012 11:09:32 +0000
Subject: [issue14129] Corrections for the "extending" doc
In-Reply-To: <1330254538.51.0.802028199864.issue14129@psf.upfronthosting.co.za>
Message-ID: <1330254572.23.0.252814776979.issue14129@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

extending.html has a reference to "Demo/embed/demo.c" which no longer exists in the source distribution

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14129>
_______________________________________

From report at bugs.python.org  Sun Feb 26 12:34:32 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 26 Feb 2012 11:34:32 +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: <1330256072.2.0.974536733204.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Aw, I guess I was too optimistic in thinking this was the last gap before we could declare it Final...

+1 on creating a new feature request for NumPy style multi-dimensional indexing and slicing support on memoryview (I'm assuming that's what you meant).

As far as your last question goes, I'm not sure we *can* salvage this in 2.7/3.2. We do have the option of throwing our hands up in the air and saying "Sorry, we couldn't figure out how to fix it without completely rewriting it. Take a look at 3.3 if you want to see how it's *supposed* to work."

I hesitate to suggest this (since I'm not volunteering to do the work) but perhaps it would be worth packaging up the 3.3. memoryview and publishing it on PyPI for the benefit of 3.2 and 2.7?

May also be worth bringing up on python-dev to see if anyone else has any bright ideas. Myself, I'm not seeing any real choices beyond "won't fix", "backport 3.3 version and remove/disable the new features", "backport 3.3 version, new features and all" and "publish a full featured version on PyPI".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Feb 26 12:37:21 2012
From: report at bugs.python.org (Adam Groszer)
Date: Sun, 26 Feb 2012 11:37:21 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1330227424.87.0.200680666874.issue6884@psf.upfronthosting.co.za>
Message-ID: <4F4A196D.9070301@gmail.com>


Adam Groszer <agroszer at gmail.com> added the comment:

Hello,

On Sun, 26 Feb 2012 03:37:06 +0000 you wrote:

> BTW if someone knows about a continuous integration service which provides Windows and Mac OS X VMs I?m all ears.

ZTK (Zope toolkit) ended up with renting a windows (server) VM.
http://winbot.zope.org/
There we run a buildbot that does the windows releases of some packages 
(zope.interface, zope.proxy, etc) and runs the tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sun Feb 26 12:48:36 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 26 Feb 2012 11:48:36 +0000
Subject: [issue14128] _elementtree should expose types and factory functions
	consistently with ElementTree
In-Reply-To: <1330248620.3.0.71621144947.issue14128@psf.upfronthosting.co.za>
Message-ID: <1330256916.66.0.325207678729.issue14128@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +effbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14128>
_______________________________________

From report at bugs.python.org  Sun Feb 26 12:55:24 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 26 Feb 2012 11:55:24 +0000
Subject: [issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's
	doctype() method missing
In-Reply-To: <1329193190.72.0.667201124226.issue14007@psf.upfronthosting.co.za>
Message-ID: <1330257324.57.0.945578681739.issue14007@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

the class versus factory issue is gone to issue 14128.

The current issue is only about the doctype() method missing in the C implementation.

I propose to drop this deprecated method from the Python version, instead of implementing the deprecated method in the C version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14007>
_______________________________________

From report at bugs.python.org  Sun Feb 26 12:55:51 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 26 Feb 2012 11:55:51 +0000
Subject: [issue14107] Debian bigmem buildbot hanging in test_bigmem
In-Reply-To: <1330096646.48.0.414006184823.issue14107@psf.upfronthosting.co.za>
Message-ID: <1330257351.04.0.329686909156.issue14107@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

"""
Thread 0x00002ba588709700:
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/support.py", line 1168 in consumer
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/threading.py", line 682 in run
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/threading.py", line 729 in _bootstrap_inner
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/threading.py", line 702 in _bootstrap

Current thread 0x00002ba57b2d4260:
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/support.py", line 1198 in stop
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/support.py", line 1240 in wrapper
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/case.py", line 385 in _executeTestPart
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/case.py", line 440 in run
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/case.py", line 492 in __call__
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/suite.py", line 105 in run
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/suite.py", line 67 in __call__
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/suite.py", line 105 in run
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/suite.py", line 67 in __call__
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/runner.py", line 168 in run
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/support.py", line 1369 in _run_suite
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/support.py", line 1403 in run_unittest
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/test_bigmem.py", line 1252 in test_main
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/regrtest.py", line 1221 in runtest_inner
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/regrtest.py", line 907 in runtest
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/regrtest.py", line 710 in main
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/__main__.py", line 13 in <module>
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/runpy.py", line 73 in _run_code
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/runpy.py", line 160 in _run_module_as_main
"""

There's a problem with the _file_watchdog thread:
if the pipe gets full (because the consumer thread doesn't get to run
often enough), the watchdog thread will block on the write() to the
pipe.
Then, the main thread tries to stop the watchdog:

"""
static void
cancel_file_watchdog(void)
{
    /* Notify cancellation */
    PyThread_release_lock(watchdog.cancel_event);

    /* Wait for thread to join */
    PyThread_acquire_lock(watchdog.running, 1);
    PyThread_release_lock(watchdog.running);

    /* The main thread should always hold the cancel_event lock */
    PyThread_acquire_lock(watchdog.cancel_event, 1);
}
"""

The `cancel_event` lock is released, but the watchdog thread is stuck
on the write().
The only thing that could wake it up is a read() from the consumer
thread, but the main thread - the one calling cancel_file_watchdog()
- blocks when acquiring the `running` lock: since the GIL is not
released, the consumer thread can't run, so it doesn't drain the pipe,
and game over...

"""
            /* We can't do anything if the consumer is too slow, just bail out  */
            if (write(watchdog.wfd, (void *) &x, sizeof(x)) < sizeof(x))
               break;
            if (write(watchdog.wfd, data, data_len) < data_len)
               break;
"""

AFAICT, this can't happen, because the write end of the pipe is not in
non-blocking mode (which would solve this issue).

Otherwise, there are two things I don't understand:
1. IIUC, the goal of the watchdog thread is to collect memory
consumption in a timely manner: that's now the case, but since the
information is printed in a standard thread, it doesn't bring any improvement (because it can be delayed for arbitrarily long), or am I
missing something?
2. instead of using a thread and the faulthandler infrastructure to run
GIL-less, why not simply use a subprocess? It could then simply
parse /proc/<PID>/statm at a regular interval, and print stats to
stdout. It would also solve point 1.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14107>
_______________________________________

From report at bugs.python.org  Sun Feb 26 12:56:42 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 26 Feb 2012 11:56:42 +0000
Subject: [issue14128] _elementtree should expose types and factory functions
	consistently with ElementTree
In-Reply-To: <1330248620.3.0.71621144947.issue14128@psf.upfronthosting.co.za>
Message-ID: <1330257402.55.0.890776543367.issue14128@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

For the record, the relevant mailing list discussion can be found here:

http://thread.gmane.org/gmane.comp.python.devel/129429/focus=129794

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14128>
_______________________________________

From report at bugs.python.org  Sun Feb 26 13:00:13 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 26 Feb 2012 12:00:13 +0000
Subject: [issue13238] Add shell command helpers to subprocess module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1330257613.84.0.50545496396.issue13238@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

For a different take on this concept:
http://julialang.org/manual/running-external-programs/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Sun Feb 26 13:02:40 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 26 Feb 2012 12:02:40 +0000
Subject: [issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's
	doctype() method missing
In-Reply-To: <1329193190.72.0.667201124226.issue14007@psf.upfronthosting.co.za>
Message-ID: <1330257760.43.0.994270756846.issue14007@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Florent,

The deprecation should be probably raised separately on pydev. From the recent discussions on this and similar topics, I doubt that removal of these methods will be accepted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14007>
_______________________________________

From report at bugs.python.org  Sun Feb 26 13:05:38 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 26 Feb 2012 12:05:38 +0000
Subject: [issue14127] os.stat and os.utime: allow preserving exact metadata
In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za>
Message-ID: <1330257938.5.0.117670139763.issue14127@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

OTOH, it seems that Guido is very much in favor of hard-coding ns resolution in the API, claiming that expectations of even finer resolution are academic. While I still disagree (the *very* same argument was brought up for ms resolution ten years ago), I think that practicality beats purity here: people apparently can deal with an fixed scale much better than with a floating one. So it may be better to meet the apparent intuition of the majority than follow the purity route.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14127>
_______________________________________

From report at bugs.python.org  Sun Feb 26 13:19:34 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 26 Feb 2012 12:19:34 +0000
Subject: [issue14107] Debian bigmem buildbot hanging in test_bigmem
In-Reply-To: <1330257351.04.0.329686909156.issue14107@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0-Mr+Jeh_7NSJArTui4mBcpgzQXHwMdtiE6uNuR03uPw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> 1. IIUC, the goal of the watchdog thread is to collect memory
> consumption in a timely manner: that's now the case, but since the
> information is printed in a standard thread, it doesn't bring any improvement (because it can be delayed for arbitrarily long), or am I
> missing something?

Scratch that. It does bring an improvement for a post facto analysis
(I thought at first it was used in a pseudo-realtime way).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14107>
_______________________________________

From report at bugs.python.org  Sun Feb 26 13:20:55 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 26 Feb 2012 12:20:55 +0000
Subject: [issue14130] memoryview: add multi-dimensional indexing and slicing
Message-ID: <1330258855.41.0.545433436542.issue14130@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
assignee: skrah
nosy: ncoghlan, pitrou, pv, skrah, teoliphant
priority: normal
severity: normal
stage: needs patch
status: open
title: memoryview: add multi-dimensional indexing and slicing
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14130>
_______________________________________

From report at bugs.python.org  Sun Feb 26 13:23:27 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 26 Feb 2012 12:23:27 +0000
Subject: [issue14130] memoryview: add multi-dimensional indexing and slicing
Message-ID: <1330259007.41.0.197339877072.issue14130@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

The PEP-3118 authors originally planned to have support for multi-dimensional indexing and slicing in memoryview.

Since memoryview now already has the capabilities of multi-dimensional
list representations and comparisons, this would be a nice addition
to the feature set.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14130>
_______________________________________

From report at bugs.python.org  Sun Feb 26 13:23:58 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 26 Feb 2012 12:23:58 +0000
Subject: [issue14130] memoryview: add multi-dimensional indexing and slicing
In-Reply-To: <1330259007.41.0.197339877072.issue14130@psf.upfronthosting.co.za>
Message-ID: <1330259038.52.0.0601739535173.issue14130@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
components: +Interpreter Core
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14130>
_______________________________________

From report at bugs.python.org  Sun Feb 26 13:26:35 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 26 Feb 2012 12:26:35 +0000
Subject: [issue1116520] Prefix search is filesystem-centric
Message-ID: <1330259195.91.0.797390968696.issue1116520@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yeah, I'm pretty sure the bootstrap mechanism needs to be able to get hold of os.py directly so it can be injected into the importlib._bootstrap namespace.

However, it may be worth figuring out and documenting the bare minimum that has to exist on the filesystem in order for importlib to get going.

It's even possible that Brett freezes enough into the interpreter binary that the required set has shrunk to zero.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1116520>
_______________________________________

From report at bugs.python.org  Sun Feb 26 13:29:31 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 26 Feb 2012 12:29:31 +0000
Subject: [issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's
	doctype() method missing
In-Reply-To: <1329193190.72.0.667201124226.issue14007@psf.upfronthosting.co.za>
Message-ID: <1330259371.76.0.546520713334.issue14007@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I understand the point about compatibility.
However it is slightly different here, because the method is already deprecated in Python 2.7 and 3.2, with a warning in the documentation and a DeprecationWarning at runtime.
This method was never available in the C version, and the documentation is clear about the recommended way of writing a custom doctype handler.
Arguably, it is not the most popular feature of ElementTree.

I am not opposed to adding the deprecated method in the C implementation, but it will need someone to do the patch, taking care of raising the deprecation warning correctly, and taking care of the case where XMLParser is subclassed. Is it worth the hassle?


Please not that contrary to what is stated in the first message (msg153328), the doctype() method is not defined on the default TreeBuilder (Python) class. The documentation suggests to add it on custom TreeBuilder implementations.

----------
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14007>
_______________________________________

From report at bugs.python.org  Sun Feb 26 13:33:05 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 26 Feb 2012 12:33:05 +0000
Subject: [issue14131] test_threading failure on WIndows 7 3.x buildbot
Message-ID: <1330259585.57.0.540126008704.issue14131@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/4458/steps/test/logs/stdio

Appears to be new, but also isn't obviously related to any recent checkins that I noticed.

(the Win7 buildbot for trunk isn't in a good place, with regular test_packaging and test_strptime values, too).

----------
keywords: buildbot
messages: 154339
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: test_threading failure on WIndows 7 3.x buildbot
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14131>
_______________________________________

From report at bugs.python.org  Sun Feb 26 13:58:51 2012
From: report at bugs.python.org (Peter Kleiweg)
Date: Sun, 26 Feb 2012 12:58:51 +0000
Subject: [issue7562] Custom order for the subcommands of build
In-Reply-To: <1261492513.72.0.435888181618.issue7562@psf.upfronthosting.co.za>
Message-ID: <1330261131.32.0.345971525295.issue7562@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/issue7562>
_______________________________________

From report at bugs.python.org  Sun Feb 26 14:00:38 2012
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sun, 26 Feb 2012 13:00:38 +0000
Subject: [issue8706] accept keyword arguments on all base type methods and
	builtins
In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>
Message-ID: <1330261238.26.0.00706693818434.issue8706@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I don't know if this is exactly what you want, but this is an early patch.

----------
keywords: +patch
nosy: +gruszczy
Added file: http://bugs.python.org/file24644/8706.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8706>
_______________________________________

From report at bugs.python.org  Sun Feb 26 14:09:12 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 26 Feb 2012 13:09:12 +0000
Subject: [issue14129] Corrections for the "extending" doc
In-Reply-To: <1330254538.51.0.802028199864.issue14129@psf.upfronthosting.co.za>
Message-ID: <1330261752.13.0.726577230685.issue14129@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

"A PyObject is not a very magnificent object - it just contains the refcount and a pointer to the object?s ?type object?."

Too chatty and should be replaced by a more pragmatic explanation, or shortened.

----------
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14129>
_______________________________________

From report at bugs.python.org  Sun Feb 26 14:12:15 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 26 Feb 2012 13:12:15 +0000
Subject: [issue14129] Corrections for the "extending" doc
In-Reply-To: <1330254538.51.0.802028199864.issue14129@psf.upfronthosting.co.za>
Message-ID: <1330261935.34.0.978965894667.issue14129@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

"in this case, nothing more than every Python object contains"

There's a grammar error lurking somewhere in there...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14129>
_______________________________________

From report at bugs.python.org  Sun Feb 26 14:13:34 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 26 Feb 2012 13:13:34 +0000
Subject: [issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's
	doctype() method missing
In-Reply-To: <1329193190.72.0.667201124226.issue14007@psf.upfronthosting.co.za>
Message-ID: <1330262014.37.0.140768267503.issue14007@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This last feature (doctype handler on custom TreeBuilder) does not have tests...

So, it is certainly broken with the C implementation.

----------
stage: needs patch -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14007>
_______________________________________

From report at bugs.python.org  Sun Feb 26 14:26:31 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 26 Feb 2012 13:26:31 +0000
Subject: [issue14129] Corrections for the "extending" doc
In-Reply-To: <1330254538.51.0.802028199864.issue14129@psf.upfronthosting.co.za>
Message-ID: <1330262791.47.0.293996851318.issue14129@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

This is not strictly in the extending doc, but linked from it:

http://docs.python.org/dev/c-api/type.html#PyType_GenericNew

The PyType_GenericNew API function is not documented

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14129>
_______________________________________

From report at bugs.python.org  Sun Feb 26 14:31:31 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 26 Feb 2012 13:31:31 +0000
Subject: [issue14107] Debian bigmem buildbot hanging in test_bigmem
In-Reply-To: <1330257351.04.0.329686909156.issue14107@psf.upfronthosting.co.za>
Message-ID: <1330262872.3345.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> """
>             /* We can't do anything if the consumer is too slow, just bail out  */
>             if (write(watchdog.wfd, (void *) &x, sizeof(x)) < sizeof(x))
>                break;
>             if (write(watchdog.wfd, data, data_len) < data_len)
>                break;
> """
> 
> AFAICT, this can't happen, because the write end of the pipe is not in
> non-blocking mode (which would solve this issue).

I think my original plan was to put it in non-blocking mode, but I must
have forgotten in the end.

> 2. instead of using a thread and the faulthandler infrastructure to run
> GIL-less, why not simply use a subprocess? It could then simply
> parse /proc/<PID>/statm at a regular interval, and print stats to
> stdout. It would also solve point 1.

I can't think of any drawback off the top of my head, so that sounds
reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14107>
_______________________________________

From report at bugs.python.org  Sun Feb 26 14:33:46 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 26 Feb 2012 13:33:46 +0000
Subject: [issue14129] Corrections for the "extending" doc
In-Reply-To: <1330254538.51.0.802028199864.issue14129@psf.upfronthosting.co.za>
Message-ID: <1330263226.36.0.749330540116.issue14129@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

"Let?s expend "

Typo

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14129>
_______________________________________

From report at bugs.python.org  Sun Feb 26 14:44:29 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 26 Feb 2012 13:44:29 +0000
Subject: [issue14129] Corrections for the "extending" doc
In-Reply-To: <1330254538.51.0.802028199864.issue14129@psf.upfronthosting.co.za>
Message-ID: <1330263869.5.0.679597461847.issue14129@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

"The new method calls the tp_alloc slot to allocate memory"

tp_alloc needs formatting here, similarly to the way it's done in other places

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14129>
_______________________________________

From report at bugs.python.org  Sun Feb 26 14:55:01 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 26 Feb 2012 13:55:01 +0000
Subject: [issue14129] Corrections for the "extending" doc
In-Reply-To: <1330254538.51.0.802028199864.issue14129@psf.upfronthosting.co.za>
Message-ID: <1330264501.98.0.782182019666.issue14129@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

"but in this cased"

Typo

[this and the past couple of comments refer to the newtypes.html doc]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14129>
_______________________________________

From report at bugs.python.org  Sun Feb 26 14:58:49 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 26 Feb 2012 13:58:49 +0000
Subject: [issue14129] Corrections for the "extending" doc
In-Reply-To: <1330254538.51.0.802028199864.issue14129@psf.upfronthosting.co.za>
Message-ID: <1330264729.35.0.653620872893.issue14129@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Noddy_name in the full code listing (included from noddy2.c) is different from the Noddy_name that is actually explained later

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14129>
_______________________________________

From report at bugs.python.org  Sun Feb 26 15:13:31 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 26 Feb 2012 14:13:31 +0000
Subject: [issue14131] test_threading failure on WIndows 7 3.x buildbot
In-Reply-To: <1330259585.57.0.540126008704.issue14131@psf.upfronthosting.co.za>
Message-ID: <1330265611.4.0.185099578118.issue14131@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Strange, I can't reproduce this on Windows 7 with exactly the same
command line:

python_d  -Wd -E -bb ../lib/test/regrtest.py -uall -rwW -n -r --randseed=8022149

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14131>
_______________________________________

From report at bugs.python.org  Sun Feb 26 15:22:33 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 26 Feb 2012 14:22:33 +0000
Subject: [issue14131] test_threading failure on WIndows 7 3.x buildbot
In-Reply-To: <1330259585.57.0.540126008704.issue14131@psf.upfronthosting.co.za>
Message-ID: <1330266153.31.0.1509379309.issue14131@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +db3l

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14131>
_______________________________________

From report at bugs.python.org  Sun Feb 26 15:32:32 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 26 Feb 2012 14:32:32 +0000
Subject: [issue14131] test_threading failure on WIndows 7 3.x buildbot
In-Reply-To: <1330259585.57.0.540126008704.issue14131@psf.upfronthosting.co.za>
Message-ID: <1330266752.55.0.903425123627.issue14131@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

This is rather curious. It looks like the assertion includes a (generous)
fudge factor in case the timing code is inaccurate, but then the actual
time taken is *just* short enough to make it fail.


> (the Win7 buildbot for trunk isn't in a good place, with regular test_packaging and test_strptime values, too).

I can't find any recent failures of test_packaging; do you mean test_imp?

I've opened issue 14113 for the test_strptime failures; it looks like
something's forgetting (or stripping off) a leading zero somewhere.

----------
components: +Tests
nosy: +nadeem.vawda
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14131>
_______________________________________

From report at bugs.python.org  Sun Feb 26 15:34:35 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 26 Feb 2012 14:34:35 +0000
Subject: [issue14085] PyUnicode_WRITE: "comparison is always true" warnings
In-Reply-To: <1329900692.24.0.951186261982.issue14085@psf.upfronthosting.co.za>
Message-ID: <1330266875.93.0.434892714051.issue14085@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Same on OSX, building trunk (3.3.0a0)

$ uname -v
Darwin Kernel Version 10.8.0: Tue Jun  7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64

$ gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)

$ ./configure MACOSX_DEPLOYMENT_TARGET=10.8 --with-pydebug
(...)
$ make -s -j12
(...)
Objects/unicodeobject.c: In function ?PyUnicode_FromFormatV?:
Objects/unicodeobject.c:2729: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:2729: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:2729: warning: comparison is always true due to limited range of data type
Python/import.c: In function ?make_compiled_pathname?:
Python/import.c:981: warning: comparison is always true due to limited range of data type
Python/import.c:981: warning: comparison is always true due to limited range of data type
Python/import.c:981: warning: comparison is always true due to limited range of data type
Python/import.c:987: warning: comparison is always true due to limited range of data type
Python/import.c:987: warning: comparison is always true due to limited range of data type
Python/import.c:987: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c: In function ?PyUnicode_DecodeUTF16Stateful?:
Objects/unicodeobject.c:5525: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:5525: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:5526: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:5526: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:5528: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:5528: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:5529: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:5529: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c: In function ?PyUnicode_DecodeASCII?:
Objects/unicodeobject.c:6929: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:6929: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:6929: warning: comparison is always true due to limited range of data type
Python/formatter_unicode.c: In function ?fill_number?:
Python/formatter_unicode.c:561: warning: comparison is always true due to limited range of data type
Python/formatter_unicode.c:561: warning: comparison is always true due to limited range of data type
Python/formatter_unicode.c:561: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c: In function ?unicode_repr?:
Objects/unicodeobject.c:12325: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12325: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12325: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12326: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12326: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12326: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12344: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12344: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12344: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12345: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12345: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12345: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12351: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12351: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12351: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12352: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12352: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12352: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12353: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12353: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12353: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12354: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12354: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12354: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12355: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12355: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12355: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12356: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12356: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12356: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12357: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12357: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12357: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12358: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12358: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12358: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12364: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12364: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12364: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12365: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12365: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12365: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12366: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12366: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12366: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12367: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12367: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:12367: warning: comparison is always true due to limited range of data type

----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +flox, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14085>
_______________________________________

From report at bugs.python.org  Sun Feb 26 15:36:49 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 26 Feb 2012 14:36:49 +0000
Subject: [issue14107] Debian bigmem buildbot hanging in test_bigmem
In-Reply-To: <1330096646.48.0.414006184823.issue14107@psf.upfronthosting.co.za>
Message-ID: <1330267009.93.0.415289466316.issue14107@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I think my original plan was to put it in non-blocking mode, but I
> must have forgotten in the end.

Here's a patch.

> I can't think of any drawback off the top of my head, so that sounds
> reasonable.

I'll try to write up a patch (I have only 1.2GB RAM, so it won't be easy
to test :-).

----------
keywords: +patch
Added file: http://bugs.python.org/file24645/mem_watchdog_nonblock.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14107>
_______________________________________

From report at bugs.python.org  Sun Feb 26 15:37:14 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 26 Feb 2012 14:37:14 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1330267034.63.0.178696916472.issue14080@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

> So the test needs to be fixed to call importlib.invalidate_caches()
> after creating the module.

That works. With issue14080.diff I can run the failing combination
without problems:

$ ./python -m test test_sqlite test_imp
[1/2] test_sqlite
test_sqlite skipped -- No module named '_sqlite3'
[2/2] test_imp
1 test OK.
1 test skipped:
    test_sqlite
Those skips are all expected on linux.
[111339 refs]



Is invalidate_caches() a transitional measure until importlib
is fully integrated?

----------
keywords: +patch
Added file: http://bugs.python.org/file24646/issue14080.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Sun Feb 26 15:37:32 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 26 Feb 2012 14:37:32 +0000
Subject: [issue14085] PyUnicode_WRITE: "comparison is always true" warnings
In-Reply-To: <1329900692.24.0.951186261982.issue14085@psf.upfronthosting.co.za>
Message-ID: <1330267052.05.0.318784091715.issue14085@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
assignee: ronaldoussoren -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14085>
_______________________________________

From report at bugs.python.org  Sun Feb 26 15:38:28 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 26 Feb 2012 14:38:28 +0000
Subject: [issue14127] os.stat and os.utime: allow preserving exact metadata
In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za>
Message-ID: <1330267108.65.0.561594971392.issue14127@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Is it totally insane to think about using a float subclass with an additional attribute instead of a tuple?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14127>
_______________________________________

From report at bugs.python.org  Sun Feb 26 16:15:32 2012
From: report at bugs.python.org (=?utf-8?q?J=C3=A1n_Janech?=)
Date: Sun, 26 Feb 2012 15:15:32 +0000
Subject: [issue14132] Redirect is not working correctly in urllib2
Message-ID: <1330269331.97.0.613564747875.issue14132@psf.upfronthosting.co.za>


New submission from J?n Janech <janech at kios.sk>:

When only the query string is sent by the server as the redirect url, urllib2 redirects to incorrect address.

Error is occuring on the page http://kniznica.uniza.sk/opac. Server sends only the query string part of the uri in the Location header (ie. ?fs=04D07295D4434730A51C95A9F1727373&fn=main). Path is then incorrectly stripped from the original url, and urllib2 redirects to http://kniznica.uniza.sk/?fs=04D07295D4434730A51C95A9F1727373&fn=main.

The error was introduced in the fix of the issue #2464. I think, the attached patch is fixing the error (it is working for me).

----------
components: Library (Lib)
files: urllib2_redirect_fix.patch
keywords: patch
messages: 154356
nosy: janik
priority: normal
severity: normal
status: open
title: Redirect is not working correctly in urllib2
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file24647/urllib2_redirect_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14132>
_______________________________________

From report at bugs.python.org  Sun Feb 26 16:16:37 2012
From: report at bugs.python.org (=?utf-8?q?J=C3=A1n_Janech?=)
Date: Sun, 26 Feb 2012 15:16:37 +0000
Subject: [issue14132] Redirect is not working correctly in urllib2
In-Reply-To: <1330269331.97.0.613564747875.issue14132@psf.upfronthosting.co.za>
Message-ID: <1330269397.99.0.815126362315.issue14132@psf.upfronthosting.co.za>


J?n Janech <janech at kios.sk> added the comment:

I forgot to mention that the correct url in the example would be http://kniznica.uniza.sk/opac?fs=04D07295D4434730A51C95A9F1727373&fn=main.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14132>
_______________________________________

From report at bugs.python.org  Sun Feb 26 16:18:27 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 26 Feb 2012 15:18:27 +0000
Subject: [issue14132] Redirect is not working correctly in urllib2
In-Reply-To: <1330269331.97.0.613564747875.issue14132@psf.upfronthosting.co.za>
Message-ID: <1330269507.26.0.882022231781.issue14132@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, facundobatista, gregory.p.smith, orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14132>
_______________________________________

From report at bugs.python.org  Sun Feb 26 16:19:23 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 26 Feb 2012 15:19:23 +0000
Subject: [issue14133] improved PEP 409 implementation
Message-ID: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

It uses a __suppress_context__ attribute rather than the whole Ellipsis mess.

----------
components: Interpreter Core
files: pep409.patch
keywords: patch
messages: 154358
nosy: benjamin.peterson, ncoghlan
priority: normal
severity: normal
status: open
title: improved PEP 409 implementation
versions: Python 3.3
Added file: http://bugs.python.org/file24648/pep409.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14133>
_______________________________________

From report at bugs.python.org  Sun Feb 26 16:25:53 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 26 Feb 2012 15:25:53 +0000
Subject: [issue14133] improved PEP 409 implementation
In-Reply-To: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za>
Message-ID: <1330269953.62.0.866794092182.issue14133@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think it has to be a __special__ attribute. suppress_context would probably be fine.
Also, instead of looking up the attribute in the dict, why not have a dedicated C member?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14133>
_______________________________________

From report at bugs.python.org  Sun Feb 26 16:35:14 2012
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 26 Feb 2012 15:35:14 +0000
Subject: [issue13224] Change str(x) to return only the (qual)name for some
	types
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1330270514.3.0.216240099888.issue13224@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Not 100% sure what you're asking. Is your specific question whether it is okay that str(Counter.update) returns 'Counter.update'? Yes, it is.  Same for Top.Nested.method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Sun Feb 26 16:39:56 2012
From: report at bugs.python.org (sbt)
Date: Sun, 26 Feb 2012 15:39:56 +0000
Subject: [issue14116] Lock.__enter__() method returns True instead of self
In-Reply-To: <1330117381.1.0.499178307418.issue14116@psf.upfronthosting.co.za>
Message-ID: <1330270796.77.0.730498399532.issue14116@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> IIUC returning True is not incorrect, only useless.  In the stdlib I 
> usually see ?with lock:?.  Can you tell what is the use case for 
> accessing the condition object inside the context block?  Does it 
> apply only to Condition or also to *Lock and Semaphore?

I was going to do something like

  with Condition() as c:
    Thread(target=foo, args=(c,...)).start()
    c.wait_for(...)

But I will agree that I don't have a compelling use case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14116>
_______________________________________

From report at bugs.python.org  Sun Feb 26 16:46:09 2012
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 26 Feb 2012 15:46:09 +0000
Subject: [issue14127] os.stat and os.utime: allow preserving exact metadata
In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za>
Message-ID: <1330271169.88.0.557204421133.issue14127@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

@RDM: yes, that's insane for this purpose. The size of the solution doesn't match the size of the problem (the problem is non-existent for most people).

@Larry: That seems unnecessarily general. I take full responsibility for fixing the precision at ns.  And note that I *am* giving you a way out -- I'm establishing a clear pattern, and if someone really, desperately wants ps or fs, it's completely obvious how to change the API again.  But I bet you a case of beer that won't happen in our lifetimes (or in Benjamin's).  So the dynamic precision is just unnneeded complexity.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14127>
_______________________________________

From report at bugs.python.org  Sun Feb 26 16:56:45 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 26 Feb 2012 15:56:45 +0000
Subject: [issue14127] os.stat and os.utime: allow preserving exact metadata
In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za>
Message-ID: <1330271805.31.0.204982845794.issue14127@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

I suggest that publishing nanoseconds as a plain int would be a nasty API.  Consider what it would do to os.utime:

    if isinstance(mtime, int):
        # must be st_mtime_ns, it's in nanoseconds, use as-is
        value = mtime
    else:
        assert isinstance(mtime, float)
        # must be st_mtime, it's in seconds, multiply by a billion
        value = mtime * 1000000000

Have we ever published an API that treated a parameter as two wildly different numbers based solely on whether the parameter was an int or a float?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14127>
_______________________________________

From report at bugs.python.org  Sun Feb 26 16:57:08 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 26 Feb 2012 15:57:08 +0000
Subject: [issue14113] Failure in test_strptime on Windows
In-Reply-To: <1330114398.55.0.713486121761.issue14113@psf.upfronthosting.co.za>
Message-ID: <1330271828.64.0.672152945175.issue14113@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

It looks like test_locale from test_format.py changes the locale on Windows:

>>> import time                                                                                      >>> magic_date = (1999, 3, 17, 22, 44, 55, 2, 76, 0)                                                 >>> time.strftime("%c", magic_date)
'03/17/99 22:44:55'
>>> import locale
>>> locale.getdefaultlocale()
('en_US', 'cp1252')                                                                                  >>> time.strftime("%c", magic_date)                                                                  '03/17/99 22:44:55'
>>> oldloc = locale.setlocale(locale.LC_ALL, '')
>>> oldloc
'English_United States.1252'
>>> time.strftime("%c", magic_date)                                                                  '3/17/1999 10:44:55 PM'
>>> locale.setlocale(locale.LC_ALL, oldloc)
'English_United States.1252'
>>> time.strftime("%c", magic_date)                                                                  '3/17/1999 10:44:55 PM'

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14113>
_______________________________________

From report at bugs.python.org  Sun Feb 26 16:59:44 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 26 Feb 2012 15:59:44 +0000
Subject: [issue14127] os.stat and os.utime: allow preserving exact metadata
In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za>
Message-ID: <1330271984.44.0.317990977147.issue14127@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

(D'oh.  My pseudo-code should have said

        value = int(mtime * 1000000000)

for that second assignment.  Hopefully my point was still clear.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14127>
_______________________________________

From report at bugs.python.org  Sun Feb 26 17:05:35 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 26 Feb 2012 16:05:35 +0000
Subject: [issue14127] os.stat and os.utime: allow preserving exact metadata
In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za>
Message-ID: <1330272335.66.0.227165508296.issue14127@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

How about a separate float attribute for the fractional part (in seconds)? This gives a femtosecond precision (assuming a 50 bits mantissa). The utime() could accept a (integral part, fractional part) tuple to set a timestamp without losing bits.

(PHP does something similar, but badly, with its microtime() function:
http://www.php.net/manual/en/function.microtime.php)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14127>
_______________________________________

From report at bugs.python.org  Sun Feb 26 17:07:18 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 26 Feb 2012 16:07:18 +0000
Subject: [issue14127] os.stat and os.utime: allow preserving exact metadata
In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za>
Message-ID: <1330272438.98.0.771074861622.issue14127@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

@pitrou: What would that look like when passed in to os.utime?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14127>
_______________________________________

From report at bugs.python.org  Sun Feb 26 17:18:07 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 26 Feb 2012 16:18:07 +0000
Subject: [issue14127] os.stat and os.utime: allow preserving exact metadata
In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za>
Message-ID: <1330273087.86.0.111793958825.issue14127@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

>>> st = os.stat('LICENSE')
>>> st.st_mtime
1330108216.7984242
>>> st.st_mtime_frac
0.798424152
>>> tup = st.st_mtime, st.st_mtime_frac
>>> os.utime('LICENSE', (tup, tup))

Of course, the fact that utime takes a (atime, mtime) tuple makes this a bit cumbersome.
When passed a tuple, utime would ignore the fractional part of the first element.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14127>
_______________________________________

From report at bugs.python.org  Sun Feb 26 17:28:38 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Feb 2012 16:28:38 +0000
Subject: [issue14107] Debian bigmem buildbot hanging in test_bigmem
In-Reply-To: <1330096646.48.0.414006184823.issue14107@psf.upfronthosting.co.za>
Message-ID: <E1S1gxh-0007gr-2o@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 52dc4fcd0d6f by Charles-Fran?ois Natali in branch 'default':
Issue #14107: test: Fix a deadlock involving the memory watchdog thread.
http://hg.python.org/cpython/rev/52dc4fcd0d6f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14107>
_______________________________________

From report at bugs.python.org  Sun Feb 26 17:59:17 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 26 Feb 2012 16:59:17 +0000
Subject: [issue1116520] Prefix search is filesystem-centric
Message-ID: <1330275557.71.0.251674097155.issue1116520@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Importlib actually requires no files from disk; everything that is required for importlib are built-in modules or are constants in importlib itself (e.g. os.sep). So technically this should be doable since my bootstrap work freezes importlib itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1116520>
_______________________________________

From report at bugs.python.org  Sun Feb 26 18:03:20 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 26 Feb 2012 17:03:20 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1330275800.01.0.947461531814.issue14080@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

importlib.invalidate_caches() would become a permanent thing if the directory listdir cache approach stays and importlib gets bootstrapped. But it would be made more general to work for any and all loaders and not be specific to importlib (e.g. 3rd-party importers would also get cleared). It's an unfortunate side-effect of mtime of directories not being granular enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Sun Feb 26 18:13:32 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Feb 2012 17:13:32 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <E1S1hf8-0002ge-Sv@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1d7472b015f0 by Antoine Pitrou in branch 'default':
Issue #14080: fix sporadic test_imp failure.  Patch by Stefan Krah.
http://hg.python.org/cpython/rev/1d7472b015f0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Sun Feb 26 18:14:45 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 26 Feb 2012 17:14:45 +0000
Subject: [issue14133] improved PEP 409 implementation
In-Reply-To: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za>
Message-ID: <1330276485.42.0.1359963405.issue14133@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

__suppress_context__ parallels with __cause__ and __context__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14133>
_______________________________________

From report at bugs.python.org  Sun Feb 26 18:33:54 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 26 Feb 2012 17:33:54 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1330277634.99.0.411651999307.issue14080@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for diagnosing this :)

----------
assignee: brett.cannon -> 
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Sun Feb 26 18:52:19 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 26 Feb 2012 17:52:19 +0000
Subject: [issue14113] Failure in test_strptime on Windows
In-Reply-To: <1330114398.55.0.713486121761.issue14113@psf.upfronthosting.co.za>
Message-ID: <1330278739.21.0.905226509917.issue14113@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Attached a fix that is tested on Windows.

----------
keywords: +patch
Added file: http://bugs.python.org/file24649/issue14113.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14113>
_______________________________________

From report at bugs.python.org  Sun Feb 26 18:52:33 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 26 Feb 2012 17:52:33 +0000
Subject: [issue14128] _elementtree should expose types and factory functions
	consistently with ElementTree
In-Reply-To: <1330248620.3.0.71621144947.issue14128@psf.upfronthosting.co.za>
Message-ID: <1330278753.9.0.223962530843.issue14128@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/issue14128>
_______________________________________

From report at bugs.python.org  Sun Feb 26 18:59:00 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 26 Feb 2012 17:59:00 +0000
Subject: [issue14127] os.stat and os.utime: allow preserving exact metadata
In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za>
Message-ID: <1330279140.66.0.941652655001.issue14127@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/issue14127>
_______________________________________

From report at bugs.python.org  Sun Feb 26 18:59:29 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 26 Feb 2012 17:59:29 +0000
Subject: [issue14113] Failure in test_strptime on Windows
In-Reply-To: <1330114398.55.0.713486121761.issue14113@psf.upfronthosting.co.za>
Message-ID: <1330279169.98.0.768180444541.issue14113@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch works under Linux here.

----------
nosy: +haypo, loewis, pitrou
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14113>
_______________________________________

From report at bugs.python.org  Sun Feb 26 19:00:22 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 26 Feb 2012 18:00:22 +0000
Subject: [issue8706] accept keyword arguments on all base type methods and
	builtins
In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>
Message-ID: <1330279222.34.0.890522639055.issue8706@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/issue8706>
_______________________________________

From report at bugs.python.org  Sun Feb 26 19:02:50 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 26 Feb 2012 18:02:50 +0000
Subject: [issue14133] improved PEP 409 implementation
In-Reply-To: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za>
Message-ID: <1330279370.71.0.557096891169.issue14133@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/issue14133>
_______________________________________

From report at bugs.python.org  Sun Feb 26 19:43:44 2012
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 26 Feb 2012 18:43:44 +0000
Subject: [issue13520] Patch to make pickle aware of __qualname__
In-Reply-To: <1322843353.56.0.297081736881.issue13520@psf.upfronthosting.co.za>
Message-ID: <1330281824.54.0.209841394086.issue13520@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/issue13520>
_______________________________________

From report at bugs.python.org  Sun Feb 26 19:46:32 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 26 Feb 2012 18:46:32 +0000
Subject: [issue14127] os.stat and os.utime: allow preserving exact metadata
In-Reply-To: <1330271805.31.0.204982845794.issue14127@psf.upfronthosting.co.za>
Message-ID: <20120226194630.Horde.LuvDUKGZi1VPSn4G8TLyn_A@webmail.df.eu>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I suggest that publishing nanoseconds as a plain int would be a  
> nasty API.  Consider what it would do to os.utime:

No, it wouldn't. Please re-read Guido's proposal. If you want to
specify nanoseconds, you have to pass the ns= parameter. My only
quibble with the specific spelling is that it invokes Godwin's law
(but I can live that that as a theoretical concern, also).

> Have we ever published an API that treated a parameter as two wildly  
> different numbers based solely on whether the parameter was an int  
> or a float?

No, and Guido is on the record for objecting such APIs. Hence the
keyword parameter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14127>
_______________________________________

From report at bugs.python.org  Sun Feb 26 20:00:04 2012
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 26 Feb 2012 19:00:04 +0000
Subject: [issue14127] os.stat and os.utime: allow preserving exact metadata
In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za>
Message-ID: <1330282804.86.0.714952388801.issue14127@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Thanks Martin. I'd be happy with nsec instead of ns.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14127>
_______________________________________

From report at bugs.python.org  Sun Feb 26 20:29:31 2012
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sun, 26 Feb 2012 19:29:31 +0000
Subject: [issue8706] accept keyword arguments on all base type methods and
	builtins
In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>
Message-ID: <1330284571.72.0.605092908947.issue8706@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

With tests.

----------
Added file: http://bugs.python.org/file24650/8706_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8706>
_______________________________________

From report at bugs.python.org  Sun Feb 26 21:01:28 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 26 Feb 2012 20:01:28 +0000
Subject: [issue14133] improved PEP 409 implementation
In-Reply-To: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za>
Message-ID: <1330286488.72.0.970359886441.issue14133@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Here's a patch which doesn't use the dict.

----------
Added file: http://bugs.python.org/file24651/pep409.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14133>
_______________________________________

From report at bugs.python.org  Sun Feb 26 21:24:37 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Feb 2012 20:24:37 +0000
Subject: [issue14097] Improve the "introduction" page of the tutorial
In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>
Message-ID: <1330287877.9.0.374022526566.issue14097@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In English, calling someone or something 'degenerate' is a major insult. In means that x is not really human or what it seems or what it was. I remember being initially startled or puzzled at the mathematical usage, but it actually is similar, just without the strong insult. A line is a degenerate parabola; a line segment is a degenerate ellipse; crossed lines constitute a degenerate hyperbola; a line segment and a point on the segment constitute a degenerate triangle. There are all limit cases, but they are simplified 'degenerated' limit cases that lack the curvature or dimensionality of the members of the sets that they are limits of. Note that straight lines are only degenerate as a limit of parabolas; they are fine figures in their only right.

0/0 as the limit of 0/x for small x is degenerate in that it looses the essential property of being a well defined real number.

'Degenerate' should not be casually applied to limits, edge cases, corner cases, or oddball cases in general. One could claim that empty counts and collections, including sequences, are 'degenerate' limits in that they loose the 'essential' property of somethingness. But if one means that, then they should be denied existence, as was done for 0 and empty sets, or put in separate classes. (For 0 and {}, there really is a sense of insult that does not apply to lines. We still see it with 'imaginary' numbers.) By including 0 and empty collections in their respective classes, Python denies that they are degenerate. So I do not think any slice should be called 'degenerate'. Certainly, the contrast between all slices working and only some indexes working has nothing to do with 'degeneracy'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14097>
_______________________________________

From report at bugs.python.org  Sun Feb 26 21:32:37 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Feb 2012 20:32:37 +0000
Subject: [issue14097] Improve the "introduction" page of the tutorial
In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>
Message-ID: <1330288357.29.0.25460055156.issue14097@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think we should feel free to change 'variable' to 'name', especially in the Intro, if it can be done gracefully in context. In my experience with python-list, the former seems a source of confusion for Python newbies. I try to avoid it when writing about Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14097>
_______________________________________

From report at bugs.python.org  Sun Feb 26 21:38:50 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 26 Feb 2012 20:38:50 +0000
Subject: [issue14127] os.stat and os.utime: allow preserving exact metadata
In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za>
Message-ID: <1330288730.27.0.868703924328.issue14127@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

My mistake!  That ought to teach me to bound out of bed Sunday morning with my "brilliant realization".  (But it probably won't.)

I volunteer to implement this, with the new custom class for the os.stat object.  I'll have it done no later than the PyCon sprints next month.

For the record, I actually prefer "ns".  "s" is the SI standard abbreviation for second (as is "n" for nano-):
http://en.wikipedia.org/wiki/International_System_of_Units#Units_and_prefixes
If we're going to abbreviate, I think it's reasonable to go with their standard.  But I'm willing to be overridden.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14127>
_______________________________________

From report at bugs.python.org  Sun Feb 26 21:40:42 2012
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sun, 26 Feb 2012 20:40:42 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1330288842.41.0.62076101122.issue13521@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Fixed both issues.

----------
Added file: http://bugs.python.org/file24652/13521_27_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Sun Feb 26 21:51:43 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 26 Feb 2012 20:51:43 +0000
Subject: [issue14131] test_threading failure on WIndows 7 3.x buildbot
In-Reply-To: <1330259585.57.0.540126008704.issue14131@psf.upfronthosting.co.za>
Message-ID: <1330289503.46.0.884689407086.issue14131@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Re: test_packaging: my mistake, the problem was actually test_package__file__ in test_imp (and Antoine already fixed it - there were some caches that weren't getting cleared properly: #14080)

The last Win7 test run was green, so we may have to write this one up as a weird glitch. I'd say we leave it for a week or so, then close it if it doesn't happen again.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14131>
_______________________________________

From report at bugs.python.org  Sun Feb 26 21:53:18 2012
From: report at bugs.python.org (Leon Matthews)
Date: Sun, 26 Feb 2012 20:53:18 +0000
Subject: [issue14006] Improve the documentation of xml.etree.ElementTree
In-Reply-To: <1329190125.69.0.69162565954.issue14006@psf.upfronthosting.co.za>
Message-ID: <1330289598.8.0.763916053671.issue14006@psf.upfronthosting.co.za>


Leon Matthews <python at lost.co.nz> added the comment:

Thank you ?ric and Ezio.  I'll produce a patch to convert the javadoc to docstrings this week, then submit it here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14006>
_______________________________________

From report at bugs.python.org  Sun Feb 26 21:54:37 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 26 Feb 2012 20:54:37 +0000
Subject: [issue14133] improved PEP 409 implementation
In-Reply-To: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za>
Message-ID: <1330289677.11.0.602033504401.issue14133@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I don't consider using Ellipsis as a sentinel value a mess. If you don't like the PEP's solution, take it up with Guido.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14133>
_______________________________________

From report at bugs.python.org  Sun Feb 26 21:55:48 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 26 Feb 2012 20:55:48 +0000
Subject: [issue14133] improved PEP 409 implementation
In-Reply-To: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za>
Message-ID: <1330289748.16.0.996444408649.issue14133@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Maybe it's not awful, but why is this not a cleaner solution?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14133>
_______________________________________

From report at bugs.python.org  Sun Feb 26 22:05:46 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 26 Feb 2012 21:05:46 +0000
Subject: [issue14127] os.stat and os.utime: allow preserving exact metadata
In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za>
Message-ID: <1330290346.11.0.426118153419.issue14127@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Let's go with ns= them. It's also what POSIX uses (although I initially had problems parsing "futimens", reading it as foo-timen-z, when it really is eff-youtime-en-es)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14127>
_______________________________________

From report at bugs.python.org  Sun Feb 26 22:08:44 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 26 Feb 2012 21:08:44 +0000
Subject: [issue14109] test_lib2to3: output that looks like a failure on
	Windows 7
In-Reply-To: <1330108216.18.0.0457510512891.issue14109@psf.upfronthosting.co.za>
Message-ID: <1330290524.5.0.450531234306.issue14109@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> test_all_project_files() expected failure

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14109>
_______________________________________

From report at bugs.python.org  Sun Feb 26 22:08:54 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 26 Feb 2012 21:08:54 +0000
Subject: [issue13125] test_all_project_files() expected failure
In-Reply-To: <1318012693.65.0.29583104397.issue13125@psf.upfronthosting.co.za>
Message-ID: <1330290534.28.0.193200633528.issue13125@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +nadeem.vawda, skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13125>
_______________________________________

From report at bugs.python.org  Sun Feb 26 22:09:07 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 26 Feb 2012 21:09:07 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1330290547.61.0.841921770368.issue6884@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Well... testing distutils2 on Windows has been quite an adventure. When
I ran the test suite before applying the patch, I got a bunch of failures
on all of the Python versions I tested (except the ones that had issues
preventing me from running the tests at all). Only one of the failures
appears to be due to the current issue.

A summary of the problems, broken down by Python version:


[python3 branch]

- 3.3/3.2: Two failures:

   * One in test_command_build_ext..test_finalize_options where the
     library search path erroneously includes some additional directories
     under the Python installation directory. This failure is not fixed
     by the patch; it continues to fail after the patch is applied.

   * One in test_manifest that looks like this:

        FAIL: test_process_template (distutils2.tests.test_manifest.ManifestTestCase)
        ----------------------------------------------------------------------
        Traceback (most recent call last):
          File "C:\Users\Nadeem\Code\distutils2\distutils2\tests\test_manifest.py", line 215, in test_process_template
            self.assertEqual(manifest.files, ['d/b.py', 'd/d/e.py'])
        AssertionError: Lists differ: [] != ['d/b.py', 'd/d/e.py']

    This one is clearly caused by the whole directory separator regex
    snafu we're trying to fix. Applying the patch fixes it, and doesn't
    introduce any new failures.

- 3.1: Same as above, plus a failure in test_util:

        FAIL: test_generate_setup_py (distutils2.tests.test_util.UtilTestCase)
        ----------------------------------------------------------------------
        Traceback (most recent call last):
          File "C:\Users\Nadeem\Code\distutils2\distutils2\tests\test_util.py", line 557, in test_generate_setup_py
            self.assertEqual(out, b'SPAM\n')
        AssertionError: b'SPAM\r\n' != b'SPAM\n'

     Like the test_finalize_options failure, this isn't fixed by the patch.


[default branch]

- 2.7: Before the tests start running, runtests.py crashes with an
       ImportError complaining that it can't find the winreg module.
       AFAIK the registry-handling module in the stdlib is called _winreg
       in 2.x, and was only renamed to winreg in 3.x.

- 2.6: Same as 2.7.

- 2.5: Twenty (20) failures, including the three I get on 3.1, some
       miscellaneous stuff that looks registry-related, and around a
       dozen errors complaining about non-ASCII characters in
       bdist_msi.py's copyright notice. As above, your patch fixes
       the one failure in test_manifest, but none of the others.

- 2.4: Can't run the tests; needs Visual C++ 2003, which (AFAICT) isn't
       freely available.


TL;DR summary: The patch itself looks good, but D2 and Windows currently
don't get along at all.

I'd like to file a separate bug for the unrelated failures - do I do that
here, or does distutils2 have a separate bugtracker/mailing list?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Sun Feb 26 22:16:22 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 26 Feb 2012 21:16:22 +0000
Subject: [issue14133] improved PEP 409 implementation
In-Reply-To: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za>
Message-ID: <1330290982.35.0.995624707188.issue14133@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I find this cleaner than the contrived "Ellipsis as magic value" solution, myself :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14133>
_______________________________________

From report at bugs.python.org  Sun Feb 26 22:18:48 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 26 Feb 2012 21:18:48 +0000
Subject: [issue14133] improved PEP 409 implementation
In-Reply-To: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za>
Message-ID: <1330291128.47.0.506655003796.issue14133@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Because you're breaking the semantics of the "raise X from Y" syntax.

That syntax is *just* syntactic sugar for "_exc = X; _exc.__cause__ = Y; raise _exc".

Under PEP 409, that remains true.

Your patch breaks it.

If you want to change the meaning for "raise X from Y", write a new PEP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14133>
_______________________________________

From report at bugs.python.org  Sun Feb 26 22:24:26 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 26 Feb 2012 21:24:26 +0000
Subject: [issue14113] Failure in test_strptime on Windows
In-Reply-To: <1330114398.55.0.713486121761.issue14113@psf.upfronthosting.co.za>
Message-ID: <1330291466.78.0.715980178663.issue14113@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Does test.support track the locale for test mutations? If not we might want to add that check w/ all of the other interpreter state checks we have.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14113>
_______________________________________

From report at bugs.python.org  Sun Feb 26 22:26:31 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 26 Feb 2012 21:26:31 +0000
Subject: [issue14126] Speed up list comprehensions by preallocating the list
	where possible
In-Reply-To: <1330212567.11.0.0699848649478.issue14126@psf.upfronthosting.co.za>
Message-ID: <1330291591.83.0.692104406223.issue14126@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/issue14126>
_______________________________________

From report at bugs.python.org  Sun Feb 26 22:27:52 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 26 Feb 2012 21:27:52 +0000
Subject: [issue14133] improved PEP 409 implementation
In-Reply-To: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za>
Message-ID: <1330291672.35.0.622371096858.issue14133@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The other problem with the "separate attribute" approach is that it makes the condition for suppressing the context ugly:

  exc.__suppress_context__ or exc.__cause__ is not None

That's hardly cleaner than:

  exc.__cause__ is not Ellipsis

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14133>
_______________________________________

From report at bugs.python.org  Sun Feb 26 22:29:48 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 26 Feb 2012 21:29:48 +0000
Subject: [issue14133] improved PEP 409 implementation
In-Reply-To: <1330291672.35.0.622371096858.issue14133@psf.upfronthosting.co.za>
Message-ID: <1330291568.3345.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The other problem with the "separate attribute" approach is that it
> makes the condition for suppressing the context ugly:
> 
>   exc.__suppress_context__ or exc.__cause__ is not None
> 
> That's hardly cleaner than:
> 
>   exc.__cause__ is not Ellipsis

I find it cleaner actually, because it states the intent rather than
hiding it behing an unexpected magic value (Ellipsis not being
exception-related).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14133>
_______________________________________

From report at bugs.python.org  Sun Feb 26 22:31:53 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 26 Feb 2012 21:31:53 +0000
Subject: [issue14133] improved PEP 409 implementation
In-Reply-To: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za>
Message-ID: <1330291913.98.0.219461077529.issue14133@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Regardless, I'm rejecting this for not complying with the PEP specification (which is quite explicit about the implementation mechanism and the API exposed to Python). If you want to challenge an approved PEP, the correct way to go about it is to write a new PEP.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14133>
_______________________________________

From report at bugs.python.org  Sun Feb 26 22:49:18 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 26 Feb 2012 21:49:18 +0000
Subject: [issue13086] Update howto/cporting.rst so it talks about Python 3
	instead of 3.0
In-Reply-To: <1317466662.3.0.331555988129.issue13086@psf.upfronthosting.co.za>
Message-ID: <1330292958.14.0.00449035873266.issue13086@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Gah!  This one fell through the cracks.

Attached is an updated patch with Ezio's "Python-level" fix, and a little more paragraph tidying.  (Apart from that one   ^ dash, the only changes
between r1 and r2 are eols.)

Unless I hear otherwise, I'll check this in to 2.7 on Tuesday or so.   Then I'll manually edit the 3.2 docs to match, and once that goes in I'll forward-merge into trunk.

----------
Added file: http://bugs.python.org/file24653/larry.cporting.to.python.3.r2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13086>
_______________________________________

From report at bugs.python.org  Sun Feb 26 22:49:37 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 26 Feb 2012 21:49:37 +0000
Subject: [issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's
	doctype() method missing
In-Reply-To: <1329193190.72.0.667201124226.issue14007@psf.upfronthosting.co.za>
Message-ID: <1330292977.62.0.217634762569.issue14007@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Two other differences:
 * the C TreeBuilder has an undocumented and unused method "xml"
 * if you omit one of the TreeBuilder method (start(), end(), data(), close()) on you custom TreeBuilder implementation, the C XMLParser works fine, but the Python XMLParser raises an attribute error.

And I confirm that if you implement the "doctype()" method on a custom TreeBuilder object, the C XMLParser ignores it, while the Python version works fine.


I propose:
 - to drop the undocumented, empty "TreeBuilder().xml" method.
 - to relax the Python XMLParser, in order to accept incomplete TreeBuilder implementation (like the C version)
 - to implement the "doctype()" handler in the C XMLParser (this needs some work)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14007>
_______________________________________

From report at bugs.python.org  Sun Feb 26 22:50:33 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 26 Feb 2012 21:50:33 +0000
Subject: [issue12904] Change os.utime &c functions to use nanosecond precision
	where possible
In-Reply-To: <1315256882.76.0.179568612134.issue12904@psf.upfronthosting.co.za>
Message-ID: <1330293033.26.0.0694663626811.issue12904@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

This was committed last September; I should have marked it closed then.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12904>
_______________________________________

From report at bugs.python.org  Sun Feb 26 22:52:44 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 26 Feb 2012 21:52:44 +0000
Subject: [issue14097] Improve the "introduction" page of the tutorial
In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>
Message-ID: <1330293164.42.0.772392509861.issue14097@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Well, I guess some people will always be blind to the finer distinctions in the scientific meaning of words...  but that doesn't mean we should apply them where they don't.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14097>
_______________________________________

From report at bugs.python.org  Sun Feb 26 22:56:00 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 26 Feb 2012 21:56:00 +0000
Subject: [issue13086] Update howto/cporting.rst so it talks about Python 3
	instead of 3.0
In-Reply-To: <1317466662.3.0.331555988129.issue13086@psf.upfronthosting.co.za>
Message-ID: <1330293360.87.0.31255606612.issue13086@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Note that the 2.7 docs now use a recent Sphinx too, so :c:macro: should work on all the 3 branches (so you don't have to use :cmacro: on 2.7 and :c:macro: on 3.x).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13086>
_______________________________________

From report at bugs.python.org  Sun Feb 26 22:59:25 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 26 Feb 2012 21:59:25 +0000
Subject: [issue14133] improved PEP 409 implementation
In-Reply-To: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za>
Message-ID: <1330293565.24.0.570894213169.issue14133@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

FWIW, I agree with Nick: once we go as far as writing PEPs for smaller features, we should keep to the spec as accepted.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14133>
_______________________________________

From report at bugs.python.org  Sun Feb 26 23:01:36 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 26 Feb 2012 22:01:36 +0000
Subject: [issue11941] Support st_atim,
	st_mtim and st_ctim attributes in os.stat_result
In-Reply-To: <1303938022.85.0.623572797729.issue11941@psf.upfronthosting.co.za>
Message-ID: <1330293696.89.0.372097207877.issue11941@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Given Guido's rejection of PEP 410, this won't happen, so I'm closing this bug.  Our BFDL has specifically rejected any of the complicated representations; he ruled that all we need are new _ns fields representing the time in nanoseconds, and to accept a "ns=" argument for os.utime and its ilk.  Please see bug #14127 for discussion of that change.

----------
nosy: +larry
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11941>
_______________________________________

From report at bugs.python.org  Sun Feb 26 23:01:54 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 26 Feb 2012 22:01:54 +0000
Subject: [issue11457] os.stat(): add new fields to get timestamps as Decimal
	objects with nanosecond resolution
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1330293714.29.0.796727301732.issue11457@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Given Guido's rejection of PEP 410, this won't happen, so I'm closing this bug.  Our BFDL has specifically rejected any of the complicated representations; he ruled that all we need are new _ns fields representing the time in nanoseconds, and to accept a "ns=" argument for os.utime and its ilk.  Please see bug #14127 for discussion of that change.

----------
resolution:  -> wont fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________

From report at bugs.python.org  Sun Feb 26 23:07:57 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 26 Feb 2012 22:07:57 +0000
Subject: [issue14113] Failure in test_strptime on Windows
In-Reply-To: <1330114398.55.0.713486121761.issue14113@psf.upfronthosting.co.za>
Message-ID: <1330294077.94.0.622519987158.issue14113@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Attached a fix that is tested on Windows.

Patch looks good to me.


> Does test.support track the locale for test mutations?

No, it doesn't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14113>
_______________________________________

From report at bugs.python.org  Sun Feb 26 23:08:30 2012
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sun, 26 Feb 2012 22:08:30 +0000
Subject: [issue11807] Documentation of add_subparsers lacks information about
	parametres
In-Reply-To: <1302340872.99.0.0231583237732.issue11807@psf.upfronthosting.co.za>
Message-ID: <1330294110.0.0.565314990291.issue11807@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Bump! I would like to remind about this issue and patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11807>
_______________________________________

From report at bugs.python.org  Sun Feb 26 23:18:47 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 26 Feb 2012 22:18:47 +0000
Subject: [issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's
	doctype() method missing
In-Reply-To: <1330292977.62.0.217634762569.issue14007@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda8sCgzV+trTrfsU-Q+iFzGFGd89q4BxaoEo13emcGyZ1w@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

On Sun, Feb 26, 2012 at 23:49, Florent Xicluna <report at bugs.python.org>wrote:

Yes, these suggestions sound reasonable to me. Moving toward two more
consistent implementations of the API, while not disabling existing
features is the way to go. Things like relaxing the Python XMLParser just
add features rather than restricting them, so they should not result in
breakage due to backward-incompatibility.

Eli

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14007>
_______________________________________

From report at bugs.python.org  Sun Feb 26 23:19:01 2012
From: report at bugs.python.org (Andrej A Antonov)
Date: Sun, 26 Feb 2012 22:19:01 +0000
Subject: [issue14134] "xmlrpc.client.ServerProxy()" -- need for
	"timeout"-parameter
Message-ID: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za>


New submission from Andrej A Antonov <polymorphm at gmail.com>:

good day!

"xmlrpc.client.ServerProxy()" -- not has "timeout"-parameter

"xmlrpc.client.Transport()" and "xmlrpc.client.SafeTransport()" -- not has "timeout"-parameter too

but "http.client.HTTPConnection()" and http.client.HTTPSConnection() -- has "timeout"-parameter

----------
components: Library (Lib)
messages: 154409
nosy: polymorphm
priority: normal
severity: normal
status: open
title: "xmlrpc.client.ServerProxy()" --  need for "timeout"-parameter
type: enhancement
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14134>
_______________________________________

From report at bugs.python.org  Sun Feb 26 23:28:56 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 26 Feb 2012 22:28:56 +0000
Subject: [issue13086] Update howto/cporting.rst so it talks about Python 3
	instead of 3.0
In-Reply-To: <1317466662.3.0.331555988129.issue13086@psf.upfronthosting.co.za>
Message-ID: <1330295336.13.0.619407172231.issue13086@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Whoops--I hadn't updated my repo since last year, and someone had already changed to :c:macro:, :c:func:, and :c:type:.  When will I learn!

Attached is a new diff with those changes, against revision @4c6662090870 (on the 2.7 branch).  Also, while I was in there, I made some minor edits to the start of the paragraph about "long/int Unification".  I think it's a slight improvement.

----------
Added file: http://bugs.python.org/file24654/larry.cporting.to.python.3.r3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13086>
_______________________________________

From report at bugs.python.org  Sun Feb 26 23:32:50 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 26 Feb 2012 22:32:50 +0000
Subject: [issue13053] Add Capsule migration documentation to "cporting"
In-Reply-To: <1317224248.53.0.263122473581.issue13053@psf.upfronthosting.co.za>
Message-ID: <1330295570.11.0.308986482897.issue13053@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

I have some more changes for cporting.rst (see #13086).  Once those are in, I'll manually merge the edits over to 3.2, then forward-port to trunk.  Does anyone want to see those as patches before I commit them?  (Your silence will be interpreted as "go ahead and commit, no patches necessary".)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13053>
_______________________________________

From report at bugs.python.org  Sun Feb 26 23:39:44 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 26 Feb 2012 22:39:44 +0000
Subject: [issue14006] Improve the documentation of xml.etree.ElementTree
In-Reply-To: <1329190125.69.0.69162565954.issue14006@psf.upfronthosting.co.za>
Message-ID: <1330295984.63.0.409971307544.issue14006@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

FWIW, Fredrik, who is the creator of ElementTree, had a preference for JavaDoc conventions, as explained here: http://bugs.python.org/issue6488#msg102087

They are compatible with the tool PythonDoc, authored by Fredrik too:
http://www.effbot.org/zone/pythondoc.htm


However, I agree it makes sense to turn them into docstrings if the package is only maintained in the standard library.


BTW, the issue 6488 is still opened. I did not check if there's something left to do before to close it.
There's also a patch attached to issue 2864, which need some review.

----------
dependencies: +ElementTree documentation refers to "path" with no explanation, and inconsistently
nosy: +effbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14006>
_______________________________________

From report at bugs.python.org  Sun Feb 26 23:45:18 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 26 Feb 2012 22:45:18 +0000
Subject: [issue14113] Failure in test_strptime on Windows
In-Reply-To: <1330294077.94.0.622519987158.issue14113@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbF0kP4jmSokgGFO+1sjeRmcBPXfboVtPNPpgVC_mQ98g@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

>> Attached a fix that is tested on Windows.
>
> Patch looks good to me.

-            oldloc = locale.setlocale(locale.LC_ALL, '')
+            oldloc = locale.setlocale(locale.LC_ALL)

Python provides locale.getlocale().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14113>
_______________________________________

From report at bugs.python.org  Sun Feb 26 23:47:48 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 26 Feb 2012 22:47:48 +0000
Subject: [issue14135] check for locale changes in test.support
Message-ID: <1330296468.42.0.0463135348779.issue14135@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Issue #14113 pointed out that test.support doesn't check if tests mucked with the locale after running.

----------
components: Tests
keywords: easy
messages: 154414
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: check for locale changes in test.support
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14135>
_______________________________________

From report at bugs.python.org  Sun Feb 26 23:48:34 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 26 Feb 2012 22:48:34 +0000
Subject: [issue14113] Failure in test_strptime on Windows
In-Reply-To: <1330114398.55.0.713486121761.issue14113@psf.upfronthosting.co.za>
Message-ID: <1330296514.04.0.461289270594.issue14113@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Created issue14135 for having test.support check the locale to see if it has been changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14113>
_______________________________________

From report at bugs.python.org  Sun Feb 26 23:48:37 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 26 Feb 2012 22:48:37 +0000
Subject: [issue14113] Failure in test_strptime on Windows
In-Reply-To: <1330114398.55.0.713486121761.issue14113@psf.upfronthosting.co.za>
Message-ID: <1330296517.6.0.268340783965.issue14113@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Python provides locale.getlocale().

That was my initial thought too, but it seems that getlocale() doesn't
accept LC_ALL as its argument:

    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/usr/local/lib/python3.3/locale.py", line 523, in getlocale
        raise TypeError('category LC_ALL is not supported')
    TypeError: category LC_ALL is not supported

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14113>
_______________________________________

From report at bugs.python.org  Sun Feb 26 23:49:02 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 26 Feb 2012 22:49:02 +0000
Subject: [issue14085] PyUnicode_WRITE: "comparison is always true" warnings
In-Reply-To: <1330267052.07.0.147961223806.issue14085@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwawmggxnUnNE+DJxqMhVUL4gVKK6GSPQFNinPdkbbecMg@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Castng to Py_UCS4 doesn't make the warning quiet. Does someone know
how to make the warning quiet.

If not, assertions can be removed from PyUnicode_WRITE. We might write
a function for Python compiled in debug mode to add the assertions.

More consistency tests (e.g. check for non-ASCII character in an ASCII
string) could be added if the macro got the object, but it only takes
data and kind.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14085>
_______________________________________

From report at bugs.python.org  Sun Feb 26 23:49:09 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 26 Feb 2012 22:49:09 +0000
Subject: [issue14135] check for locale changes in test.support
In-Reply-To: <1330296468.42.0.0463135348779.issue14135@psf.upfronthosting.co.za>
Message-ID: <1330296549.82.0.0433734949947.issue14135@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14135>
_______________________________________

From report at bugs.python.org  Sun Feb 26 23:51:27 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 26 Feb 2012 22:51:27 +0000
Subject: [issue11457] os.stat(): add new fields to get timestamps as Decimal
	objects with nanosecond resolution
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1330296687.88.0.0938158900595.issue11457@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________

From report at bugs.python.org  Sun Feb 26 23:54:16 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Feb 2012 22:54:16 +0000
Subject: [issue13873] SIGBUS in test_big_buffer() of test_zlib on Debian
	bigmem buildbot
In-Reply-To: <1327583804.29.0.71599909936.issue13873@psf.upfronthosting.co.za>
Message-ID: <E1S1myq-0003xL-ME@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fc43b051ae1c by Nadeem Vawda in branch '3.2':
Issue #13873: Fix crash in test_zlib when running on a small (<4GB) tmpfs.
http://hg.python.org/cpython/rev/fc43b051ae1c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13873>
_______________________________________

From report at bugs.python.org  Sun Feb 26 23:55:10 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 26 Feb 2012 22:55:10 +0000
Subject: [issue14129] Corrections for the "extending" doc
In-Reply-To: <1330254538.51.0.802028199864.issue14129@psf.upfronthosting.co.za>
Message-ID: <1330296910.27.0.246958062442.issue14129@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

There are some:

"
   XXX Need to ...
"

Paragraphs scattered across the doc. These have no place in the official documentation. For placeholders, an issue can be created that lists all the things that need to be done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14129>
_______________________________________

From report at bugs.python.org  Mon Feb 27 00:01:48 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 26 Feb 2012 23:01:48 +0000
Subject: [issue14134] "xmlrpc.client.ServerProxy()" -- need for
	"timeout"-parameter
In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za>
Message-ID: <1330297308.66.0.229076508127.issue14134@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14134>
_______________________________________

From report at bugs.python.org  Mon Feb 27 00:02:10 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 26 Feb 2012 23:02:10 +0000
Subject: [issue14134] "xmlrpc.client.ServerProxy()" -- need for
	"timeout"-parameter
In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za>
Message-ID: <1330297330.22.0.852426712005.issue14134@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/issue14134>
_______________________________________

From report at bugs.python.org  Mon Feb 27 00:28:12 2012
From: report at bugs.python.org (sbt)
Date: Sun, 26 Feb 2012 23:28:12 +0000
Subject: [issue14125] Windows: failures in refleak mode
In-Reply-To: <1330210051.4.0.773065627544.issue14125@psf.upfronthosting.co.za>
Message-ID: <1330298892.61.0.884922275941.issue14125@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

The failures for test_multiprocessing and test_concurrent_futures seem to be caused by a leak in _multiprocessing.win32.WaitForMultipleObjects().

The attached patch fixes those leaks for me (on a 32 bit build).

----------
keywords: +patch
nosy: +sbt
Added file: http://bugs.python.org/file24655/mp_wfmo_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14125>
_______________________________________

From report at bugs.python.org  Mon Feb 27 00:48:58 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Feb 2012 23:48:58 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <E1S1npp-0000AL-D0@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5c52e7c6d868 by Antoine Pitrou in branch '2.7':
Issue #13521: dict.setdefault() now does only one lookup for the given key, making it "atomic" for many purposes.
http://hg.python.org/cpython/rev/5c52e7c6d868

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Mon Feb 27 01:05:45 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Feb 2012 00:05:45 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <E1S1o64-0001oC-Al@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 90572ccda12c by Antoine Pitrou in branch '3.2':
Issue #13521: dict.setdefault() now does only one lookup for the given key, making it "atomic" for many purposes.
http://hg.python.org/cpython/rev/90572ccda12c

New changeset 3dfa98cf2e26 by Antoine Pitrou in branch 'default':
Issue #13521: dict.setdefault() now does only one lookup for the given key, making it "atomic" for many purposes.
http://hg.python.org/cpython/rev/3dfa98cf2e26

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Mon Feb 27 01:06:33 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Feb 2012 00:06:33 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1330301193.25.0.606830125699.issue13521@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you Filip! I've now committed the patch.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Mon Feb 27 01:46:14 2012
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 27 Feb 2012 00:46:14 +0000
Subject: [issue14067] Avoid more stat() calls in importlib
In-Reply-To: <1329772687.53.0.782755770398.issue14067@psf.upfronthosting.co.za>
Message-ID: <1330303574.01.0.997870132266.issue14067@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at gmail.com> added the comment:

As long as the interpreter knows about about files that *it* wrote, no repeat checks during startup seems utterly reasonable; sneaking in a new or changed file is inherently a race condition.

I think it would also be reasonable for general use, so long as there was also a way to say "for this particular directory, always check".

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14067>
_______________________________________

From report at bugs.python.org  Mon Feb 27 03:23:20 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 27 Feb 2012 02:23:20 +0000
Subject: [issue14136] Simplify PEP 409 command line test and move it to
	test_cmd_line_script
Message-ID: <1330309400.02.0.0793594491787.issue14136@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

I stuffed up the review on one of the new tests in the PEP 409 patch - the one that checks if the exception context is suppressed correctly from the command line.

That test should be drastically simplified and moved from test_raise to test_cmd_line_script.

----------
assignee: ncoghlan
components: Tests
messages: 154425
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Simplify PEP 409 command line test and move it to test_cmd_line_script
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14136>
_______________________________________

From report at bugs.python.org  Mon Feb 27 03:59:59 2012
From: report at bugs.python.org (Narnie Harshoe)
Date: Mon, 27 Feb 2012 02:59:59 +0000
Subject: [issue14137] GTK3 Segmentation fault from Warning: g_object_notify:
	assertion `G_IS_OBJECT (object)' failed
Message-ID: <1330311599.64.0.412967212338.issue14137@psf.upfronthosting.co.za>


New submission from Narnie Harshoe <signupnarnie at gmail.com>:

Using the following code for a Gtk.CellRenderSpin results in the following error after changing the spin button several times.

The error is:

/usr/lib/python2.7/dist-packages/gi/types.py:43: Warning: g_object_notify: assertion `G_IS_OBJECT (object)' failed
  return info.invoke(*args, **kwargs)
Segmentation fault

#! /usr/bin/env python
# -*- coding: utf-8 -*-

from gi.repository import Gtk

class CellRendererSpinWindow(Gtk.Window):

    def __init__(self):
        Gtk.Window.__init__(self, title="CellRendererSpin Example")

        self.set_default_size(200, 200)

        self.liststore = Gtk.ListStore(str, int)
        self.liststore.append(["Oranges", 5])
        self.liststore.append(["Apples", 4])
        self.liststore.append(["Bananas", 2])

        treeview = Gtk.TreeView(model=self.liststore)

        renderer_text = Gtk.CellRendererText()
        column_text = Gtk.TreeViewColumn("Fruit", renderer_text, text=0)
        treeview.append_column(column_text)

        renderer_spin = Gtk.CellRendererSpin()
        renderer_spin.connect("edited", self.on_amount_edited)
        renderer_spin.set_property("editable", True)

        adjustment = Gtk.Adjustment(0, 0, 100, 1, 10, 0)
        renderer_spin.set_property("adjustment", adjustment)

        column_spin = Gtk.TreeViewColumn("Amount", renderer_spin, text=1)
        treeview.append_column(column_spin)

        self.add(treeview)

    def on_amount_edited(self, widget, path, value):
        self.liststore[path][1] = int(value)

win = CellRendererSpinWindow()
win.connect("delete-event", Gtk.main_quit)
win.show_all()
Gtk.main()

This code comes from http://python-gtk-3-tutorial.readthedocs.org/en/latest/cellrenderers.html

It is confirmed by another user via Ubuntu launchpad at https://bugs.launchpad.net/ubuntu/+source/pygobject/+bug/908889

My system is a Debian system tracking debian testing.

Exact python --version is Python 2.7.2+

----------
components: None
messages: 154426
nosy: Narnie.Harshoe
priority: normal
severity: normal
status: open
title: GTK3 Segmentation fault from Warning: g_object_notify: assertion `G_IS_OBJECT (object)' failed
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14137>
_______________________________________

From report at bugs.python.org  Mon Feb 27 04:13:28 2012
From: report at bugs.python.org (Narnie Harshoe)
Date: Mon, 27 Feb 2012 03:13:28 +0000
Subject: [issue14138] Ctrl-C does not terminate GTK3 Gtk.main() loop when
	program run from command line
Message-ID: <1330312408.32.0.611668312241.issue14138@psf.upfronthosting.co.za>


New submission from Narnie Harshoe <signupnarnie at gmail.com>:

In a normal python program, Ctrl-C will set up a KeyboardInterrupt and terminate the program. This works with a normal python script, including GTK2 gtk.main(), but GTK3 Gtk.main() (even when used in a more robust GTK program that coded below) will not terminate with Ctrl-C requiring a Ctrl-Z and killing the job to terminate. See the commmand line output below:

$ python -c "while True:
>  pass
> "
^CTraceback (most recent call last):
  File "<string>", line 1, in <module>
KeyboardInterrupt


$ python -c "import gtk
> gtk.main()
> "
^CTraceback (most recent call last):
  File "<string>", line 2, in <module>
KeyboardInterrupt


$ python -c "from gi.repository import Gtk
> Gtk.main()
> "
^C
^C
^Z
[1]+  Stopped                 python -c "from gi.repository import Gtk
Gtk.main()
"
$ kill %1

[1]+  Stopped                 python -c "from gi.repository import Gtk
Gtk.main()
"

The behaviour under Gtk.main() should be changed to respond to the KeyboardInterrupt.

----------
components: None
messages: 154427
nosy: Narnie.Harshoe
priority: normal
severity: normal
status: open
title: Ctrl-C does not terminate GTK3 Gtk.main() loop when program run from command line
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14138>
_______________________________________

From report at bugs.python.org  Mon Feb 27 04:58:22 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 27 Feb 2012 03:58:22 +0000
Subject: [issue14127] os.stat and os.utime: allow preserving exact metadata
In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za>
Message-ID: <1330315102.81.0.132115484944.issue14127@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/issue14127>
_______________________________________

From report at bugs.python.org  Mon Feb 27 05:34:41 2012
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 27 Feb 2012 04:34:41 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1330317281.93.0.226569568306.issue13703@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

After pulling the latest code, random.py no longer works since it tries to import urandom from os on both 3.3 and 2.7.

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Mon Feb 27 05:51:24 2012
From: report at bugs.python.org (Mark Hammond)
Date: Mon, 27 Feb 2012 04:51:24 +0000
Subject: [issue8170] Wrong Paths for distutils build --plat-name=win-amd64
In-Reply-To: <1268913333.33.0.305416760988.issue8170@psf.upfronthosting.co.za>
Message-ID: <1330318284.37.0.525384807754.issue8170@psf.upfronthosting.co.za>


Mark Hammond <skippy.hammond at gmail.com> added the comment:

I don't quite understand how the order will be wrong.  Which earlier entry is causing the problem?  OTOH though, I also don't quite understand how the build would work at all if a 32bit Python is used to invoke distutils with --plat-name=win-amd64 as the 32bit Python install wont have that PCBuild/AMD64 directory at all - so some more context is needed before I can understand this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8170>
_______________________________________

From report at bugs.python.org  Mon Feb 27 06:01:40 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 27 Feb 2012 05:01:40 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1330317281.93.0.226569568306.issue13703@psf.upfronthosting.co.za>
Message-ID: <CAPZV6o9ysUDkZMytmcJwSWSE6=tg6VnhZWJLZhLOn55EnXTU1g@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

Can you paste the error you're getting?

2012/2/26 Roger Serwy <report at bugs.python.org>:
>
> Roger Serwy <roger.serwy at gmail.com> added the comment:
>
> After pulling the latest code, random.py no longer works since it tries to import urandom from os on both 3.3 and 2.7.
>
> ----------
> nosy: +serwy
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13703>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Mon Feb 27 06:13:09 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 27 Feb 2012 05:13:09 +0000
Subject: [issue14137] GTK3 Segmentation fault from Warning: g_object_notify:
	assertion `G_IS_OBJECT (object)' failed
In-Reply-To: <1330311599.64.0.412967212338.issue14137@psf.upfronthosting.co.za>
Message-ID: <1330319589.83.0.853832340975.issue14137@psf.upfronthosting.co.za>


Ramchandra Apte <maniandram01 at gmail.com> added the comment:

Why do you think this is a bug in Python?
I don't think this is a bug in Python.
This might be bug in PyGTK or GTK which are third-party libraries.

----------
nosy: +ramchandra.apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14137>
_______________________________________

From report at bugs.python.org  Mon Feb 27 06:22:27 2012
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 27 Feb 2012 05:22:27 +0000
Subject: [issue13703] Hash collision security issue
In-Reply-To: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>
Message-ID: <1330320147.71.0.849958794935.issue13703@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

It was a false alarm. I didn't recompile python before running it with the latest /Lib files. My apologies.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Mon Feb 27 06:30:03 2012
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 27 Feb 2012 05:30:03 +0000
Subject: [issue14111] IDLE Debugger should handle interrupts
In-Reply-To: <1330112839.68.0.0096879566667.issue14111@psf.upfronthosting.co.za>
Message-ID: <1330320603.84.0.928518519942.issue14111@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I can confirm the issue Larry's raises. Attached is a patch against 2.7 to enable Ctrl+C interrupts for the debugger. The patch opens up the possibility of making "Go" a toggle button, but that would require some more plumbing (not included in patch).

A "run" indicator should be simple to implement. The status bar can contain a label that can be updated with calls to "beginexecuting" and "endexecuting" in PyShell.py.

----------
keywords: +patch
nosy: +serwy, terry.reedy
Added file: http://bugs.python.org/file24656/Issue14111.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14111>
_______________________________________

From report at bugs.python.org  Mon Feb 27 07:15:05 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 27 Feb 2012 06:15:05 +0000
Subject: [issue14129] Corrections for the "extending" doc
In-Reply-To: <1330254538.51.0.802028199864.issue14129@psf.upfronthosting.co.za>
Message-ID: <1330323305.82.0.376128216781.issue14129@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Adding the documentation experts. 

I plan to apply a fix for these soon. If you guys have any objections, let me know.

----------
nosy: +eric.araujo, ezio.melotti, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14129>
_______________________________________

From report at bugs.python.org  Mon Feb 27 07:59:55 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Mon, 27 Feb 2012 06:59:55 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1330325995.68.0.704890366457.issue13405@psf.upfronthosting.co.za>


Marc Abramowitz <msabramo at gmail.com> added the comment:

Hi Jes?s,

Yes, I'm on an x86 machine. A MacBook Pro with OS X 10.6.8.

I'll try to hop on Google Talk during the week. I'm on the west coast of the U.S. (GMT-8) so it might be tricky to find a mutually good time.

Here's the result of the tests - like you said the stack test failed but everything else passed:

```
[last: 0] marca at SCML-MarcA:~/src/python-hg/cpython-2011$ sudo ~/custom/bin/python Lib/test/test_dtrace.py 
test_function_entry_return (__main__.DTraceTestsNormal) ... ok
test_garbage_collection (__main__.DTraceTestsNormal) ... ok
test_instance_creation_destruction (__main__.DTraceTestsNormal) ... ok
test_line (__main__.DTraceTestsNormal) ... ok
test_stack (__main__.DTraceTestsNormal) ... FAIL
test_verify_opcodes (__main__.DTraceTestsNormal) ... ok

======================================================================
FAIL: test_stack (__main__.DTraceTestsNormal)
...
```

Perhaps the test should be modified as follows:

```
[last: 0] marca at SCML-MarcA:~/src/python-hg/cpython-2011$ hg diff Lib/test/test_dtrace.py
diff -r b50130b35288 Lib/test/test_dtrace.py
--- a/Lib/test/test_dtrace.py	Wed Feb 22 02:15:47 2012 +0100
+++ b/Lib/test/test_dtrace.py	Sun Feb 26 22:56:03 2012 -0800
@@ -78,6 +78,9 @@
         self.assertEqual(actual_result, expected_result)
 
     def test_stack(self) :
+        if sys.platform == 'darwin':
+            raise unittest.SkipTest, "No jstack support on Mac OS X"
+
         dscript = """
 python$target:::function-entry
 /(copyinstr(arg0)=="%(path)s") &&
```

Then the result is:

```
[last: 0] marca at SCML-MarcA:~/src/python-hg/cpython-2011$ sudo ~/custom/bin/python Lib/test/test_dtrace.py 
test_function_entry_return (__main__.DTraceTestsNormal) ... ok
test_garbage_collection (__main__.DTraceTestsNormal) ... ok
test_instance_creation_destruction (__main__.DTraceTestsNormal) ... ok
test_line (__main__.DTraceTestsNormal) ... ok
test_stack (__main__.DTraceTestsNormal) ... skipped 'No jstack support on Mac OS X'
test_verify_opcodes (__main__.DTraceTestsNormal) ... ok

----------------------------------------------------------------------
Ran 6 tests in 0.561s

OK (skipped=1)
test_function_entry_return (__main__.DTraceTestsOptimize) ... ok
test_garbage_collection (__main__.DTraceTestsOptimize) ... ok
test_instance_creation_destruction (__main__.DTraceTestsOptimize) ... ok
test_line (__main__.DTraceTestsOptimize) ... ok
test_stack (__main__.DTraceTestsOptimize) ... skipped 'No jstack support on Mac OS X'
test_verify_opcodes (__main__.DTraceTestsOptimize) ... ok

----------------------------------------------------------------------
Ran 6 tests in 0.577s

OK (skipped=1)
```

By the way, I have some virtual machines set up for OpenIndiana b151A and FreeBSD 9.0, so you need some testing on those platforms, let me know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Feb 27 08:25:59 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Mon, 27 Feb 2012 07:25:59 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1330327559.18.0.386014231999.issue13405@psf.upfronthosting.co.za>


Marc Abramowitz <msabramo at gmail.com> added the comment:

All tests pass on OpenIndiana b151A (SunOS openindiana 5.11 oi_151a2 i86pc i386 i86pc Solaris).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Feb 27 08:52:50 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 27 Feb 2012 07:52:50 +0000
Subject: [issue14138] Ctrl-C does not terminate GTK3 Gtk.main() loop when
	program run from command line
In-Reply-To: <1330312408.32.0.611668312241.issue14138@psf.upfronthosting.co.za>
Message-ID: <1330329170.22.0.893169483338.issue14138@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> The behaviour under Gtk.main() should be changed to respond to the 
> KeyboardInterrupt.

Well, you should report that to (Py)GTK folks then :-)
Either they set up a SIGINT handler, or they catch the KeyboardInterrupt exception, but that's not a problem with Python.
Closing.

----------
nosy: +neologix
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14138>
_______________________________________

From report at bugs.python.org  Mon Feb 27 08:58:39 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 27 Feb 2012 07:58:39 +0000
Subject: [issue14137] GTK3 Segmentation fault from Warning: g_object_notify:
	assertion `G_IS_OBJECT (object)' failed
In-Reply-To: <1330311599.64.0.412967212338.issue14137@psf.upfronthosting.co.za>
Message-ID: <1330329519.68.0.984173089049.issue14137@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

@Narnie
This is the Python bug tracker, not the PyGTK one.
You should report your problems on the PyGTK/GTK bug tracker.

Thanks.

----------
nosy: +neologix
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14137>
_______________________________________

From report at bugs.python.org  Mon Feb 27 09:02:24 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 27 Feb 2012 08:02:24 +0000
Subject: [issue14107] Debian bigmem buildbot hanging in test_bigmem
In-Reply-To: <1330096646.48.0.414006184823.issue14107@psf.upfronthosting.co.za>
Message-ID: <1330329744.76.0.0777281289582.issue14107@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

test_bigmem now passes on the buildbot:
http://python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/149/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14107>
_______________________________________

From report at bugs.python.org  Mon Feb 27 09:50:16 2012
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Mon, 27 Feb 2012 08:50:16 +0000
Subject: [issue1531415] parsetok.c emits warnings by writing to stderr
Message-ID: <1330332616.48.0.235599351811.issue1531415@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

I am interested in solving this bug. 
If I understood correctly, that should be just a matter of spitting over sys.stdout whenever the user imports warnings.py, sys.stderr otherwise. 
Rewriting the code in C for python3.x would still be appreciated?

----------
nosy: +eric.araujo, ezio.melotti, maker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1531415>
_______________________________________

From report at bugs.python.org  Mon Feb 27 09:56:11 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 08:56:11 +0000
Subject: [issue14129] Corrections for the "extending" doc
In-Reply-To: <1330254538.51.0.802028199864.issue14129@psf.upfronthosting.co.za>
Message-ID: <1330332971.56.0.119150335259.issue14129@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> "in this case, nothing more than every Python object contains"
> There's a grammar error lurking somewhere in there...

It could be: ?nothing more that what every Python object contains?.

Could you post a patch for review?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14129>
_______________________________________

From report at bugs.python.org  Mon Feb 27 09:58:46 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 08:58:46 +0000
Subject: [issue13086] Update howto/cporting.rst so it talks about Python 3
	instead of 3.0
In-Reply-To: <1317466662.3.0.331555988129.issue13086@psf.upfronthosting.co.za>
Message-ID: <1330333126.08.0.249346688741.issue13086@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+can simply switch to :c:type:`Capsule`.  If you need to support Python 3.0,
+or versions of Python earlier than 2.7,
+you'll have to support both CObjects and Capsules.

We pretend that Python 3.0 never existed, or was a beta.  Python 3.1 is the first supported 3.x release.  Thus I think you can delete that mention.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13086>
_______________________________________

From report at bugs.python.org  Mon Feb 27 10:01:39 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 27 Feb 2012 09:01:39 +0000
Subject: [issue14113] Failure in test_strptime on Windows
In-Reply-To: <1330114398.55.0.713486121761.issue14113@psf.upfronthosting.co.za>
Message-ID: <1330333299.91.0.0215506196472.issue14113@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

> ... it seems that getlocale() doesn't accept LC_ALL as its argument:

The current situation is not ideal. getlocale() is documented to fail
("category may be one of the LC_* values except LC_ALL"), but it only
fails if there's a semicolon in the locale name:

if category == LC_ALL and ';' in localename:
    raise TypeError('category LC_ALL is not supported')


I'd prefer that getlocale(LC_ALL) fails consistently on all systems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14113>
_______________________________________

From report at bugs.python.org  Mon Feb 27 10:03:40 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 09:03:40 +0000
Subject: [issue13224] Change str(x) to return only the (qual)name for some
	types
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1330333420.13.0.206834198801.issue13224@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Is your specific question whether it is okay that str(Counter.update) returns 'Counter.update'?
Yes, sorry if I was unclear.

> Yes, it is.  Same for Top.Nested.method.
Good!  I?ll commit soon.  I?ll make a note in Misc/NEWS, but I don?t think this should go to whatsnew or other doc, as it?s an implementation detail anyway (as discussed on the python-ideas thread).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Mon Feb 27 10:06:05 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 09:06:05 +0000
Subject: [issue14123] Indicate that there are no current plans to deprecate
	printf-style formatting
In-Reply-To: <1330202928.96.0.727285588049.issue14123@psf.upfronthosting.co.za>
Message-ID: <1330333565.46.0.676642728229.issue14123@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Apparently this was too urgent too wait for my patch :)

Not closing yet, as there are still phrasing issues discussed on python-dev.

----------
assignee: eric.araujo -> 
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14123>
_______________________________________

From report at bugs.python.org  Mon Feb 27 10:20:46 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Feb 2012 09:20:46 +0000
Subject: [issue14113] Failure in test_strptime on Windows
In-Reply-To: <1330114398.55.0.713486121761.issue14113@psf.upfronthosting.co.za>
Message-ID: <E1S1wlB-0007Ul-1T@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1ea466240792 by Stefan Krah in branch 'default':
Issue #14113: Fix a test_strptime failure caused by changes to LC_ALL.
http://hg.python.org/cpython/rev/1ea466240792

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14113>
_______________________________________

From report at bugs.python.org  Mon Feb 27 10:25:17 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 09:25:17 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1330334717.61.0.87225171479.issue6884@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

[Nadeem]
> Not sure about a CI service, but if you want Windows for your own machine
> I believe you can get a free MSDN subscription:
Yep, I have one of these and downloaded an ISO, but I haven?t yet managed to set it up with qemu.

[Adam]
> ZTK (Zope toolkit) ended up with renting a windows (server) VM. http://winbot.zope.org/
> There we run a buildbot that does the windows releases of some packages
OK.  Too bad for me then.


Nadeem, thanks for your report.  We used to have one or two people working on distutils2 on Windows, but they got busy with other things or I scared them off, and now I just have to hope that my commits work, which clearly doesn?t work.  I?ll send a call for testers on some mailing lists.

Newlines are a particular sore point.  In many cases we don?t care about them and happily use splitlines to ignore platform differences; in some cases we really want LF on all platforms but there are no tests.

Please file reports for the bugs you?ve found, on this tracker.  Set the ?Distutils2? component and I?ll be auto-nosy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Mon Feb 27 10:31:35 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 27 Feb 2012 09:31:35 +0000
Subject: [issue14094] nt.realpath() should use GetFinalPathNameByHandle() when
	available
In-Reply-To: <1329954470.08.0.180096078595.issue14094@psf.upfronthosting.co.za>
Message-ID: <1330335095.1.0.586768377866.issue14094@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14094>
_______________________________________

From report at bugs.python.org  Mon Feb 27 10:32:50 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 27 Feb 2012 09:32:50 +0000
Subject: [issue14088] sys.executable generating canonical path
In-Reply-To: <1330058170.47.0.297534639706.issue14088@psf.upfronthosting.co.za>
Message-ID: <20120227093246.GA9041@chang>


Petri Lehtinen <petri at digip.org> added the comment:

?ric Araujo wrote:
> I wonder if the doc for sys.executable should mention that ..
> segments may be present.

Once this is fixed, it should say that .. segments may be present if
there's realpath() is not available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14088>
_______________________________________

From report at bugs.python.org  Mon Feb 27 10:40:55 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 27 Feb 2012 09:40:55 +0000
Subject: [issue14123] Indicate that there are no current plans to deprecate
	printf-style formatting
In-Reply-To: <1330202928.96.0.727285588049.issue14123@psf.upfronthosting.co.za>
Message-ID: <1330335655.29.0.432915211741.issue14123@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage: needs patch -> committed/rejected
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14123>
_______________________________________

From report at bugs.python.org  Mon Feb 27 11:16:17 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 10:16:17 +0000
Subject: [issue11841] packaging.version: Bug when comparing versions with rc
	marker
In-Reply-To: <1302686380.66.0.407051830429.issue11841@psf.upfronthosting.co.za>
Message-ID: <1330337777.63.0.683772003736.issue11841@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t remember how I did it last time, but yesterday I was able to reproduce the bug.  I have added unit tests, as the lines I added to the doctest were actually no run (I?m working on it in #13953), and applied the fix.  I will push shortly.

----------
resolution: out of date -> 
stage: committed/rejected -> commit review
status: closed -> open
title: Bug in the version comparison -> packaging.version: Bug when comparing versions with rc marker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11841>
_______________________________________

From report at bugs.python.org  Mon Feb 27 11:23:30 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 27 Feb 2012 10:23:30 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1330338210.26.0.336124509965.issue14080@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I think there's another problem on Windows even after the fix:

http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/4463


======================================================================
FAIL: test_package___file__ (test.test_imp.PEP3147Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_imp.py", line 331, in test_package___file__
    self.assertEqual(m.__file__, expected___file__, (m.__file__, m.__path__))
AssertionError: 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows7\\build\\build\\test_pytho [truncated]... != '.\\pep3147\\__init__.py'
- D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\build\test_python_2652\pep3147\__init__.py
+ .\pep3147\__init__.py
 : ('D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows7\\build\\build\\test_python_2652\\pep3147\\__init__.py', ['D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows7\\build\\build\\test_python_2652\\pep3147'])

----------------------------------------------------------------------

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Mon Feb 27 11:47:52 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Feb 2012 10:47:52 +0000
Subject: [issue11841] packaging.version: Bug when comparing versions with rc
	marker
In-Reply-To: <1302686380.66.0.407051830429.issue11841@psf.upfronthosting.co.za>
Message-ID: <E1S1y7S-00075D-Ky@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 32cb52bee738 by ?ric Araujo in branch 'default':
Fix comparison bug with 'rc' versions in packaging.version (#11841).
http://hg.python.org/cpython/rev/32cb52bee738

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11841>
_______________________________________

From report at bugs.python.org  Mon Feb 27 12:09:58 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 27 Feb 2012 11:09:58 +0000
Subject: [issue13873] SIGBUS in test_big_buffer() of test_zlib on Debian
	bigmem buildbot
In-Reply-To: <1327583804.29.0.71599909936.issue13873@psf.upfronthosting.co.za>
Message-ID: <1330340998.04.0.122431899657.issue13873@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13873>
_______________________________________

From report at bugs.python.org  Mon Feb 27 12:14:04 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 27 Feb 2012 11:14:04 +0000
Subject: [issue14139] test_ftplib: segfault
Message-ID: <1330341244.46.0.956938686476.issue14139@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Seen on a Windows buildbot:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/4223/steps/test/logs/stdio

Fatal Python error: Segmentation fault

Current thread 0x000007e4:
  File "D:\Buildslave\3.x.moore-windows\build\lib\ssl.py", line 476 in unwrap
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_ftplib.py", line 333 in _do_ssl_shutdown
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_ftplib.py", line 394 in close
  File "D:\Buildslave\3.x.moore-windows\build\lib\asyncore.py", line 577 in close_all
  File "../lib/test/regrtest.py", line 1043 in restore_asyncore_socket_map
  File "../lib/test/regrtest.py", line 1188 in __exit__
  File "../lib/test/regrtest.py", line 1225 in runtest_inner
  File "../lib/test/regrtest.py", line 907 in runtest
  File "../lib/test/regrtest.py", line 710 in main
  File "../lib/test/regrtest.py", line 1812 in <module>


Perhaps see also:

http://mail.python.org/pipermail/python-list/2011-May/1272350.html

----------
components: Tests
messages: 154452
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ftplib: segfault
type: crash
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14139>
_______________________________________

From report at bugs.python.org  Mon Feb 27 12:22:10 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 11:22:10 +0000
Subject: [issue14140] packaging tests: add helpers to create and inspect a
	tree of files
Message-ID: <1330341730.18.0.549794058583.issue14140@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Many packaging tests use functions like os.mkdir and open to create files in order to test commands or actions, or slightly higher-level helpers like packaging.tests.support.TempdirManager.write_file.

I think this could be much more automated.  There should be an helper function which could accept a string with a custom format describing directories, files and their contents, then create the files in a temp directory and later cleans it all.  Likewise, it should be easier to check what new files are created (i.e. in the build or dist directory) and what their contents are.

My ultimate goal is to move from low-level tests which use command objects directly to higher-level tests which actually run the pysetup script and check the results, so that tests get closer to what people do.  This will also remove cruft in the tests, and let us change details more easily (because we?ll be testing behavior, not internal attributes or exact output).

----------
assignee: eric.araujo
components: Distutils2
messages: 154453
nosy: alexis, eric.araujo, francismb, python-dev, shane.moore, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: packaging tests: add helpers to create and inspect a tree of files
type: enhancement
versions: 3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14140>
_______________________________________

From report at bugs.python.org  Mon Feb 27 12:26:46 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 27 Feb 2012 11:26:46 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1330342006.53.0.560116480809.issue6884@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Yep, I have one of these and downloaded an ISO, but I haven?t yet managed to set it up with qemu.

You might want to give VirtualBox a try - I've found it very easy to set up.


> Please file reports for the bugs you?ve found, on this tracker.

Will do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Mon Feb 27 12:29:46 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Feb 2012 11:29:46 +0000
Subject: [issue13193] packaging.tests.test_manifest and
	distutils.tests.test_filelist failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <E1S1ym0-0002Ti-MX@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4d6a9f287543 by ?ric Araujo in branch 'default':
Fix bugs with MANIFEST.in parsing on Windows (#6884).
http://hg.python.org/distutils2/rev/4d6a9f287543

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Mon Feb 27 12:29:46 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Feb 2012 11:29:46 +0000
Subject: [issue13974] packaging: test for set_platform()
In-Reply-To: <1328775875.69.0.230962367845.issue13974@psf.upfronthosting.co.za>
Message-ID: <E1S1ym0-0002Ti-MM@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fae9d7aa7fc9 by ?ric Araujo in branch 'default':
Add test for util.set_platform (#13974).
http://hg.python.org/distutils2/rev/fae9d7aa7fc9

New changeset 7d1a7251d771 by ?ric Araujo in branch 'python3':
Merge fixes for #13974, #6884 and #11841 from default
http://hg.python.org/distutils2/rev/7d1a7251d771

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13974>
_______________________________________

From report at bugs.python.org  Mon Feb 27 12:29:47 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Feb 2012 11:29:47 +0000
Subject: [issue14004] Distutils filelist selects too many files on Windows
In-Reply-To: <1329166628.27.0.616152401371.issue14004@psf.upfronthosting.co.za>
Message-ID: <E1S1ym0-0002Ti-Mg@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4d6a9f287543 by ?ric Araujo in branch 'default':
Fix bugs with MANIFEST.in parsing on Windows (#6884).
http://hg.python.org/distutils2/rev/4d6a9f287543

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14004>
_______________________________________

From report at bugs.python.org  Mon Feb 27 12:29:47 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Feb 2012 11:29:47 +0000
Subject: [issue9691] sdist includes files that are not in MANIFEST.in
In-Reply-To: <1282822249.86.0.974734126224.issue9691@psf.upfronthosting.co.za>
Message-ID: <E1S1ym0-0002Ti-N9@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4d6a9f287543 by ?ric Araujo in branch 'default':
Fix bugs with MANIFEST.in parsing on Windows (#6884).
http://hg.python.org/distutils2/rev/4d6a9f287543

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9691>
_______________________________________

From report at bugs.python.org  Mon Feb 27 12:29:48 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Feb 2012 11:29:48 +0000
Subject: [issue11841] packaging.version: Bug when comparing versions with rc
	marker
In-Reply-To: <1302686380.66.0.407051830429.issue11841@psf.upfronthosting.co.za>
Message-ID: <E1S1ym0-0002Ti-N1@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c82c97b2eae1 by ?ric Araujo in branch 'default':
Fix comparison bug with 'rc' versions (#11841)
http://hg.python.org/distutils2/rev/c82c97b2eae1

New changeset 7d1a7251d771 by ?ric Araujo in branch 'python3':
Merge fixes for #13974, #6884 and #11841 from default
http://hg.python.org/distutils2/rev/7d1a7251d771

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11841>
_______________________________________

From report at bugs.python.org  Mon Feb 27 12:29:49 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Feb 2012 11:29:49 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <E1S1ym0-0002Ti-Mq@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4d6a9f287543 by ?ric Araujo in branch 'default':
Fix bugs with MANIFEST.in parsing on Windows (#6884).
http://hg.python.org/distutils2/rev/4d6a9f287543

New changeset 7d1a7251d771 by ?ric Araujo in branch 'python3':
Merge fixes for #13974, #6884 and #11841 from default
http://hg.python.org/distutils2/rev/7d1a7251d771

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Mon Feb 27 12:29:52 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 27 Feb 2012 11:29:52 +0000
Subject: [issue14140] packaging tests: add helpers to create and inspect a
	tree of files
In-Reply-To: <1330341730.18.0.549794058583.issue14140@psf.upfronthosting.co.za>
Message-ID: <1330342192.61.0.994430775964.issue14140@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14140>
_______________________________________

From report at bugs.python.org  Mon Feb 27 12:31:27 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 11:31:27 +0000
Subject: [issue11841] packaging.version: Bug when comparing versions with rc
	marker
In-Reply-To: <1302686380.66.0.407051830429.issue11841@psf.upfronthosting.co.za>
Message-ID: <1330342287.32.0.529533078681.issue11841@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks again for the patch.  Next time I say that I couldn?t reproduce a bug, please insist :)

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11841>
_______________________________________

From report at bugs.python.org  Mon Feb 27 12:32:15 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 11:32:15 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1330342335.94.0.54330647862.issue6884@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve been recommended VirtualBox, but I don?t have Qt libs on my machine (I don?t have much disk space and I don?t like Qt :)

Happily closing as fixed.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Mon Feb 27 12:50:10 2012
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Mon, 27 Feb 2012 11:50:10 +0000
Subject: [issue11841] packaging.version: Bug when comparing versions with rc
	marker
In-Reply-To: <1302686380.66.0.407051830429.issue11841@psf.upfronthosting.co.za>
Message-ID: <1330343410.8.0.267532964199.issue11841@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I prefer to be humble and trust core devs, when I post some patch to a codebase I don't know very well. I am glad you managed to reproduce it and I could help :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11841>
_______________________________________

From report at bugs.python.org  Mon Feb 27 12:50:47 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 11:50:47 +0000
Subject: [issue11841] packaging.version: Bug when comparing versions with rc
	marker
In-Reply-To: <1302686380.66.0.407051830429.issue11841@psf.upfronthosting.co.za>
Message-ID: <1330343447.29.0.104075405483.issue11841@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Having push rights does not make me smarter :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11841>
_______________________________________

From report at bugs.python.org  Mon Feb 27 12:58:06 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 11:58:06 +0000
Subject: [issue13756] Python3.2.2 make fail on cygwin
In-Reply-To: <1326199459.04.0.575648132034.issue13756@psf.upfronthosting.co.za>
Message-ID: <1330343886.52.0.450100598336.issue13756@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Martin, any input?

Uncompressed patch attached.  Plain text files are easier to review and devoid of security issues (unlike executables on Windows, PDFs if you?re using Adobe Reader, etc.).

----------
Added file: http://bugs.python.org/file24657/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13756>
_______________________________________

From report at bugs.python.org  Mon Feb 27 13:13:38 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 12:13:38 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1330344818.99.0.146964539532.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I merged default yesterday and produced this patch.  I?ll use the review site to make comments.

----------
Added file: http://bugs.python.org/file24658/9a7dba6e6f1a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Mon Feb 27 13:21:31 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 12:21:31 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1330345291.34.0.791064863511.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Or I won?t, as even a dumb no-git-style diff does not create a review link, maybe because of the binary file change.  *Sigh*  Trying again.

----------
Added file: http://bugs.python.org/file24659/9a7dba6e6f1a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Mon Feb 27 13:21:44 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 12:21:44 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1330345304.08.0.409048592861.issue12394@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file24658/9a7dba6e6f1a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Mon Feb 27 13:21:59 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 12:21:59 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1330345319.05.0.36793245512.issue12394@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file23008/7099110c8f14.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Mon Feb 27 13:23:33 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 12:23:33 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1330345413.74.0.860570072375.issue8668@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Merged yesterday and created this patch.  Will refresh my memories by reading all messages again and review.

----------
dependencies:  -Add **kwargs to reinitialize_command
Added file: http://bugs.python.org/file24660/fe817128d2fc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Mon Feb 27 13:24:22 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 27 Feb 2012 12:24:22 +0000
Subject: [issue10713] re module doesn't describe string boundaries for \b
In-Reply-To: <1292461535.35.0.85810781117.issue10713@psf.upfronthosting.co.za>
Message-ID: <1330345462.08.0.179742667043.issue10713@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is a new patch based on Martin work.
I don't think it's necessary to explain what happens while using r'\b' or r'\B' on an empty string in the doc -- that's not a common case and it might end up confusing users.  I think however that a couple of examples might help them figuring out what they are useful for.
Mentioning that they work with the beginning/end of the string too is a reasonable request, so I tweaked the doc to point that out.

----------
stage: needs patch -> patch review
type:  -> enhancement
versions:  -Python 3.1
Added file: http://bugs.python.org/file24661/issue10713.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10713>
_______________________________________

From report at bugs.python.org  Mon Feb 27 13:28:42 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 12:28:42 +0000
Subject: [issue5302] Allow package_data specs/globs to match directories
In-Reply-To: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za>
Message-ID: <1330345722.17.0.635600202759.issue5302@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

For consistency with the resources section, a recursive glob should be mydata/**, not mydata/* or bare mydata.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5302>
_______________________________________

From report at bugs.python.org  Mon Feb 27 13:50:01 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 12:50:01 +0000
Subject: [issue13167] Add get_metadata to packaging
In-Reply-To: <1318521693.13.0.517549681601.issue13167@psf.upfronthosting.co.za>
Message-ID: <1330347001.54.0.914425209717.issue13167@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the feedback.

> So, that would mean instead of
>   get_distribution(name).metadata['Version']
> you'd use
>   get_metadata(name)['Version']
> ?
> I'm not sure that's really buys you much.

Yeah.  At the moment we also have get_distribution(name).version, which I hope is not deemed ugly.

> I don't entirely remember my objections to the API, but I wonder if you couldn't provide
> attribute access via properties on .metadata?  Or are there keys that can't be mapped to
> identifiers (modulo typical dash-to-underscore mappings)?

In distutils1, the metadata fields were accessed as attributes.  I think using a mapping interface makes more sense and is nicer to use.

Rejecting for now.

----------
assignee: tarek -> eric.araujo
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13167>
_______________________________________

From report at bugs.python.org  Mon Feb 27 13:56:18 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 27 Feb 2012 12:56:18 +0000
Subject: [issue14125] Windows: failures in refleak mode
In-Reply-To: <1330210051.4.0.773065627544.issue14125@psf.upfronthosting.co.za>
Message-ID: <1330347378.83.0.150375975662.issue14125@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Nice! This also fixes the leak in test_concurrent_futures. The
time-related test failures probably also have a single source.


I ran the whole test suite on x64 with no (new) failures.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14125>
_______________________________________

From report at bugs.python.org  Mon Feb 27 13:57:26 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Feb 2012 12:57:26 +0000
Subject: [issue14125] Windows: failures in refleak mode
In-Reply-To: <1330210051.4.0.773065627544.issue14125@psf.upfronthosting.co.za>
Message-ID: <E1S208q-0002iZ-Mm@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ba51573fcf90 by Stefan Krah in branch 'default':
Issue #14125: Fix multiprocessing refleak on Windows. Patch by sbt.
http://hg.python.org/cpython/rev/ba51573fcf90

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14125>
_______________________________________

From report at bugs.python.org  Mon Feb 27 13:58:58 2012
From: report at bugs.python.org (sbt)
Date: Mon, 27 Feb 2012 12:58:58 +0000
Subject: [issue14125] Windows: failures in refleak mode
In-Reply-To: <1330210051.4.0.773065627544.issue14125@psf.upfronthosting.co.za>
Message-ID: <1330347538.04.0.510122353753.issue14125@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

The attached patch fixes the time related refleaks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14125>
_______________________________________

From report at bugs.python.org  Mon Feb 27 13:59:46 2012
From: report at bugs.python.org (sbt)
Date: Mon, 27 Feb 2012 12:59:46 +0000
Subject: [issue14125] Windows: failures in refleak mode
In-Reply-To: <1330210051.4.0.773065627544.issue14125@psf.upfronthosting.co.za>
Message-ID: <1330347586.41.0.841501325834.issue14125@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

Ah.  Forgot the patch.

----------
Added file: http://bugs.python.org/file24662/time_strftime_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14125>
_______________________________________

From report at bugs.python.org  Mon Feb 27 14:04:57 2012
From: report at bugs.python.org (Nicholas Cole)
Date: Mon, 27 Feb 2012 13:04:57 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1330347897.58.0.957182708565.issue12567@psf.upfronthosting.co.za>


Nicholas Cole <nicholas.cole at gmail.com> added the comment:

It looks to me as if the documentation in the release candidates for 2.7.3 and 3.2.3 haven't been updated to include the new curses fixes.  Is that correct?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Mon Feb 27 14:13:25 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 13:13:25 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1330348405.47.0.718083006706.issue12567@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yes, it was only fixed for 3.3.

----------
nosy: +eric.araujo
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Mon Feb 27 14:28:44 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 13:28:44 +0000
Subject: [issue10713] re module doesn't describe string boundaries for \b
In-Reply-To: <1292461535.35.0.85810781117.issue10713@psf.upfronthosting.co.za>
Message-ID: <1330349324.52.0.39118367177.issue10713@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Like it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10713>
_______________________________________

From report at bugs.python.org  Mon Feb 27 15:02:53 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 27 Feb 2012 14:02:53 +0000
Subject: [issue14129] Corrections for the "extending" doc
In-Reply-To: <1330254538.51.0.802028199864.issue14129@psf.upfronthosting.co.za>
Message-ID: <1330351373.33.0.200371297255.issue14129@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Patch attached

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file24663/issue_14129.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14129>
_______________________________________

From report at bugs.python.org  Mon Feb 27 15:07:20 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 27 Feb 2012 14:07:20 +0000
Subject: [issue8739] Update to smtpd.py to RFC 5321
In-Reply-To: <1274103249.44.0.284620021799.issue8739@psf.upfronthosting.co.za>
Message-ID: <1330351640.17.0.6822871679.issue8739@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8739>
_______________________________________

From report at bugs.python.org  Mon Feb 27 15:08:58 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 27 Feb 2012 14:08:58 +0000
Subject: [issue14026] test_cmd_line_script should include more sys.argv checks
In-Reply-To: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za>
Message-ID: <1330351738.94.0.496863617104.issue14026@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14026>
_______________________________________

From report at bugs.python.org  Mon Feb 27 16:18:29 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 27 Feb 2012 15:18:29 +0000
Subject: [issue8706] accept keyword arguments on all base type methods and
	builtins
In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>
Message-ID: <1330355909.31.0.590335809953.issue8706@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> patch review
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8706>
_______________________________________

From report at bugs.python.org  Mon Feb 27 16:33:34 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Feb 2012 15:33:34 +0000
Subject: [issue14125] Windows: failures in refleak mode
In-Reply-To: <1330210051.4.0.773065627544.issue14125@psf.upfronthosting.co.za>
Message-ID: <E1S22Zu-0002bh-A0@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d4adbf908983 by Stefan Krah in branch 'default':
Issue #14125: Fix refleak in timemodule.c on Windows. Thanks sbt for pointing
http://hg.python.org/cpython/rev/d4adbf908983

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14125>
_______________________________________

From report at bugs.python.org  Mon Feb 27 16:36:18 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 27 Feb 2012 15:36:18 +0000
Subject: [issue14125] Windows: failures in refleak mode
In-Reply-To: <1330210051.4.0.773065627544.issue14125@psf.upfronthosting.co.za>
Message-ID: <1330356978.09.0.371933755292.issue14125@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

sbt, thanks again! I chose a different approach because on non-Windows
the unused 'error' label produced compiler warnings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14125>
_______________________________________

From report at bugs.python.org  Mon Feb 27 16:58:12 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Feb 2012 15:58:12 +0000
Subject: [issue1531415] parsetok.c emits warnings by writing to stderr
Message-ID: <1330358292.17.0.168676982561.issue1531415@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Not quite, Michele. So this bug is about taking the stuff that is printed to stdout/stderr explicitly in parsetok.c and instead using the warnings functions, e.g. PyErr_Warn(), since _warnings is a built-in module (now) and thus is available to the tokenizer to use.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1531415>
_______________________________________

From report at bugs.python.org  Mon Feb 27 17:07:37 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 27 Feb 2012 16:07:37 +0000
Subject: [issue14133] improved PEP 409 implementation
In-Reply-To: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za>
Message-ID: <1330358857.13.0.588644109888.issue14133@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Now with doc changes!

----------
Added file: http://bugs.python.org/file24664/pep415.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14133>
_______________________________________

From report at bugs.python.org  Mon Feb 27 17:13:53 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Feb 2012 16:13:53 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1330359233.9.0.971358071101.issue14080@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

This is issue #14052 all over again, just with a different test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Mon Feb 27 17:18:29 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Feb 2012 16:18:29 +0000
Subject: [issue14067] Avoid more stat() calls in importlib
In-Reply-To: <1329772687.53.0.782755770398.issue14067@psf.upfronthosting.co.za>
Message-ID: <1330359509.03.0.891021116742.issue14067@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Well, we already have a delay in detecting new files in importlib as the directory mtime check already adds a delay of the granularity of the mtime value for a directory. So if you manage to mutate a directory, import, write a file, and then import again all within the mtime of a directory, you will miss the new file (which has already triggered sporadic failures in various tests because they were not blowing out importlib's cache). IOW there is already a freshness problem that if we don't have importlib will never get bootstrapped because people will complain about performance too much.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14067>
_______________________________________

From report at bugs.python.org  Mon Feb 27 17:32:32 2012
From: report at bugs.python.org (Steve McConnel)
Date: Mon, 27 Feb 2012 16:32:32 +0000
Subject: [issue14141] 2.7.2 64-bit Windows library has __impt_Py* for several
	symbols instead of __imp__Py*
Message-ID: <1330360352.45.0.311661027338.issue14141@psf.upfronthosting.co.za>


New submission from Steve McConnel <stephen_mcconnel at sil.org>:

The Python27.lib file shipped with the 64-bit Windows installer (.msi) has several symbols with improper values.  The problem appears to be a single underscore instead of a double underscore between __imp and Py in the symbol.  Attempting to build our application which links to Python in Visual Studio 2008, the following symbols are undefined due to this problem:
 __imp__PyCallable_Check
 __imp__PyClass_Type
 __imp__PyDict_GetItemString
 __imp__PyErr_Clear
 __imp__PyErr_Fetch
 __imp__PyErr_Occurred
 __imp__PyImport_ImportModule
 __imp__PyInstance_Type
 __imp__PyModule_GetDict
 __imp__PyObject_CallObject
 __imp__PyRun_SimpleStringFlags
 __imp__PyString_AsString
 __imp__PyString_AsStringAndSize
 __imp__PyString_FromStringAndSize
 __imp__PyString_Type
 __imp__PyTraceBack_Type
 __imp__PyTuple_New
 __imp__PyTuple_SetItem
 __imp__PyType_IsSubtype
 __imp__PyUnicodeUCS2_AsUnicode
 __imp__PyUnicodeUCS2_FromUnicode
 __imp__PyUnicodeUCS2_GetSize
 __imp__Py_DecRef
 __imp__Py_Finalize
 __imp__Py_Initialize

These symbols appear to be properly defined in the 32-bit version.

----------
messages: 154487
nosy: Steve.McConnel
priority: normal
severity: normal
status: open
title: 2.7.2 64-bit Windows library has __impt_Py* for several symbols instead of __imp__Py*

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14141>
_______________________________________

From report at bugs.python.org  Mon Feb 27 17:35:11 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 27 Feb 2012 16:35:11 +0000
Subject: [issue14141] 2.7.2 64-bit Windows library has __impt_Py* for several
	symbols instead of __imp__Py*
In-Reply-To: <1330360352.45.0.311661027338.issue14141@psf.upfronthosting.co.za>
Message-ID: <1330360511.51.0.81300980007.issue14141@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
components: +Windows
nosy: +brian.curtin, loewis, nadeem.vawda, tim.golden
stage:  -> needs patch
type:  -> compile error
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14141>
_______________________________________

From report at bugs.python.org  Mon Feb 27 17:40:01 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Feb 2012 16:40:01 +0000
Subject: [issue14125] Windows: failures in refleak mode
In-Reply-To: <1330210051.4.0.773065627544.issue14125@psf.upfronthosting.co.za>
Message-ID: <E1S23cG-0001Vq-Co@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b4321f93e3f2 by Stefan Krah in branch '3.2':
Issue #14125: backport refleak fix (d4adbf908983).
http://hg.python.org/cpython/rev/b4321f93e3f2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14125>
_______________________________________

From report at bugs.python.org  Mon Feb 27 17:49:24 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 27 Feb 2012 16:49:24 +0000
Subject: [issue14125] Windows: failures in refleak mode
In-Reply-To: <1330210051.4.0.773065627544.issue14125@psf.upfronthosting.co.za>
Message-ID: <1330361364.37.0.14097924004.issue14125@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Test suite is OK also on 3.2. Closing.

----------
components: +Tests
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14125>
_______________________________________

From report at bugs.python.org  Mon Feb 27 17:54:21 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 27 Feb 2012 16:54:21 +0000
Subject: [issue13756] Python3.2.2 make fail on cygwin
In-Reply-To: <1326199459.04.0.575648132034.issue13756@psf.upfronthosting.co.za>
Message-ID: <1330361661.92.0.310825287855.issue13756@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The removal of testing for ncurses.h is incorrect: this should break the Linux build, where ncurses.h is indeed commonly located in /usr/include.

Not sure how to proceed here: if somebody would try to reproduce the problem, they would likely come up with a patch which is fairly different from the one you are proposing. 

So, Luis: are you interested in working out a complete and correct patch? If so, please start with generating one that is against the hg 3.2 branch (or perhaps even against the default branch). It's ok if you are not interested, in that case we'll need to wait for some other volunteer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13756>
_______________________________________

From report at bugs.python.org  Mon Feb 27 18:10:07 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 27 Feb 2012 17:10:07 +0000
Subject: [issue8706] accept keyword arguments on all base type methods and
	builtins
In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>
Message-ID: <1330362607.41.0.632232224667.issue8706@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

At a quick glance, I think you've got the right idea.  Fixing this involves a lot of PyArg_ParseTuple -> PyArg_ParseTupleAndKeywords upgrades all over the place.

Obviously there are are a wide range of things that can use updating for this so in order to keep things sane, it makes sense to do them in stages with individual patches for particular libraries.

I like that your 8706_2.patch chose to attack stringlib to start with as that covers a lot of ground with one piece of code and that you updated the tests to confirm that ordered args and keyword args both work.

This issue as filed doesn't have a well defined "end goal" to know when it is complete.  Another good thing would be to come up with a final goal.  Perhaps an audit of the stdlib and types to list which things do not properly accept keyword arguments?  That way there is a list of things to check off.  And if desired we could file sub-issues for various components rather than letting this one get huge.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8706>
_______________________________________

From report at bugs.python.org  Mon Feb 27 18:17:28 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 27 Feb 2012 17:17:28 +0000
Subject: [issue14129] Corrections for the "extending" doc
In-Reply-To: <1330254538.51.0.802028199864.issue14129@psf.upfronthosting.co.za>
Message-ID: <1330363048.48.0.831578036977.issue14129@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Thanks for the review. I'm going to do the commit now. Feel free to just fix it if any obvious mistakes remain.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14129>
_______________________________________

From report at bugs.python.org  Mon Feb 27 18:17:28 2012
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Mon, 27 Feb 2012 17:17:28 +0000
Subject: [issue8706] accept keyword arguments on all base type methods and
	builtins
In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>
Message-ID: <1330363048.8.0.96558886381.issue8706@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Do you think I should put everything into a single patch or rather slowly add new patches with different methods or method groups?

I would rather split it into several patches, I think it is easier to manage them, especially that this one is quite huge already.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8706>
_______________________________________

From report at bugs.python.org  Mon Feb 27 18:19:12 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Feb 2012 17:19:12 +0000
Subject: [issue14129] Corrections for the "extending" doc
In-Reply-To: <1330254538.51.0.802028199864.issue14129@psf.upfronthosting.co.za>
Message-ID: <E1S24Dx-0006Bg-UJ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6c737eb12c3e by Eli Bendersky in branch 'default':
Some corrections for the Doc/extending documentation. Closes #14129
http://hg.python.org/cpython/rev/6c737eb12c3e

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14129>
_______________________________________

From report at bugs.python.org  Mon Feb 27 18:33:14 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 27 Feb 2012 17:33:14 +0000
Subject: [issue14142] getlocale(LC_ALL) behavior
Message-ID: <1330363994.24.0.841585589979.issue14142@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

This came up in #14113. getlocale(LC_ALL) is documented to fail, at
least that's how I read this:

   "category may be one of the LC_* values except LC_ALL."


But in fact getlocale(LC_ALL) works if there is no semicolon in the
locale name:

>>> getlocale(LC_ALL)
('en_US', 'ISO8859-1')


I would prefer if getlocale(LC_ALL) fails consistently. If that's
not possible, then this is a documentation issue.

----------
messages: 154495
nosy: skrah
priority: normal
severity: normal
status: open
title: getlocale(LC_ALL) behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14142>
_______________________________________

From report at bugs.python.org  Mon Feb 27 18:48:09 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 27 Feb 2012 17:48:09 +0000
Subject: [issue14113] Failure in test_strptime on Windows
In-Reply-To: <1330114398.55.0.713486121761.issue14113@psf.upfronthosting.co.za>
Message-ID: <1330364889.73.0.70375483485.issue14113@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I've created #14142 for the getlocale(LC_ALL) situation. The main issue
is fixed, Nadeem's changes result in better error messages, so I think we
can close this.

Perhaps the assertEqual changes should be backported to 3.2 and 2.7
to keep the files in sync (leaving the issue open for that).

----------
resolution:  -> fixed
stage: commit review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14113>
_______________________________________

From report at bugs.python.org  Mon Feb 27 18:51:02 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 27 Feb 2012 17:51:02 +0000
Subject: [issue14113] Failure in test_strptime on Windows
In-Reply-To: <1330114398.55.0.713486121761.issue14113@psf.upfronthosting.co.za>
Message-ID: <1330365062.98.0.562970441669.issue14113@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Perhaps the assertEqual changes should be backported to 3.2 and 2.7
> to keep the files in sync (leaving the issue open for that).

Agreed. I'll also make similar changes to the other test cases; my
initial changes only touched the tests that were failing.

----------
assignee:  -> nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14113>
_______________________________________

From report at bugs.python.org  Mon Feb 27 19:01:25 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 27 Feb 2012 18:01:25 +0000
Subject: [issue14107] Debian bigmem buildbot hanging in test_bigmem
In-Reply-To: <1330096646.48.0.414006184823.issue14107@psf.upfronthosting.co.za>
Message-ID: <1330365685.26.0.381122114276.issue14107@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14107>
_______________________________________

From report at bugs.python.org  Mon Feb 27 19:17:44 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 27 Feb 2012 18:17:44 +0000
Subject: [issue14139] test_ftplib: segfault
In-Reply-To: <1330341244.46.0.956938686476.issue14139@psf.upfronthosting.co.za>
Message-ID: <1330366664.97.0.538179542811.issue14139@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14139>
_______________________________________

From report at bugs.python.org  Mon Feb 27 19:23:37 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 27 Feb 2012 18:23:37 +0000
Subject: [issue14131] test_threading failure on WIndows 7 3.x buildbot
In-Reply-To: <1330259585.57.0.540126008704.issue14131@psf.upfronthosting.co.za>
Message-ID: <1330367017.33.0.869861436378.issue14131@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

A very similar failure in test_thread:

http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/4469/steps/test/logs/stdio

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14131>
_______________________________________

From report at bugs.python.org  Mon Feb 27 19:52:42 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 27 Feb 2012 18:52:42 +0000
Subject: [issue12151] test_logging fails sometimes
In-Reply-To: <1306106163.56.0.790245092521.issue12151@psf.upfronthosting.co.za>
Message-ID: <1330368762.06.0.813701923216.issue12151@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

A similar failure to msg136576 has cropped up on the Windows 7 bot:

http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/4469/steps/test/logs/stdio

----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12151>
_______________________________________

From report at bugs.python.org  Mon Feb 27 19:55:06 2012
From: report at bugs.python.org (Eric Snow)
Date: Mon, 27 Feb 2012 18:55:06 +0000
Subject: [issue1116520] Prefix search is filesystem-centric
Message-ID: <1330368906.11.0.489607213924.issue1116520@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1116520>
_______________________________________

From report at bugs.python.org  Mon Feb 27 19:55:57 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Feb 2012 18:55:57 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1330368957.16.0.329273776657.issue14080@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> This is issue #14052 all over again, just with a different test.

I don't think so, because I've whacked the part of importlib that transformed '' into os.getcwd().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Mon Feb 27 20:00:48 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Feb 2012 19:00:48 +0000
Subject: [issue13125] test_all_project_files() expected failure
In-Reply-To: <1318012693.65.0.29583104397.issue13125@psf.upfronthosting.co.za>
Message-ID: <E1S25oU-0000Kf-Rg@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2fd68efac05a by Antoine Pitrou in branch '3.2':
Issue #13125: Silence spurious test_lib2to3 output when in non-verbose mode.
http://hg.python.org/cpython/rev/2fd68efac05a

New changeset e721b2b74b59 by Antoine Pitrou in branch 'default':
Issue #13125: Silence spurious test_lib2to3 output when in non-verbose mode.
http://hg.python.org/cpython/rev/e721b2b74b59

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13125>
_______________________________________

From report at bugs.python.org  Mon Feb 27 20:01:39 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Feb 2012 19:01:39 +0000
Subject: [issue13125] test_all_project_files() expected failure
In-Reply-To: <1318012693.65.0.29583104397.issue13125@psf.upfronthosting.co.za>
Message-ID: <1330369299.62.0.498682161193.issue13125@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you for the patch, Mikhail. I got Benjamin to give it the ok and so it's now committed in 3.2 and 3.3!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13125>
_______________________________________

From report at bugs.python.org  Mon Feb 27 20:07:40 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 27 Feb 2012 19:07:40 +0000
Subject: [issue14143] test_ntpath failure on Windows
Message-ID: <1330369660.88.0.127957807148.issue14143@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6075/steps/test/logs/stdio

    FAIL: test_time (test.test_ntpath.NtCommonTest)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_genericpath.py", line 127, in test_time
        self.pathmodule.getmtime(support.TESTFN)
    AssertionError: 1330364192.9002845 not less than or equal to 1330363190.76044

It seems the file's modification time is earlier than its creation time by ~1002s.

----------
components: Tests, Windows
keywords: buildbot
messages: 154503
nosy: nadeem.vawda
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ntpath failure on Windows
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14143>
_______________________________________

From report at bugs.python.org  Mon Feb 27 20:18:36 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 27 Feb 2012 19:18:36 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1330370316.46.0.362853367387.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Marc, OpenIndiana is one of the platforms I am testing myself :-).

If you can try FreeBSD 9.0, that would be amazing.

I have committed the skip of "jstack()" test in "darwin", since we know that the code is not actually ported to MacOS X.

The main complexity of supporting MacOS X was that "dtrace -G" used to fails under MacOS. Current MacOS releases simply ignore the flag. I don't know since when this is not an issue anymore. Can you test under older MacOS releases?. Is it OK to support this feature ONLY in recent OS releases?. AFAIK, "-G" was a problem with MacOS X 10.5. See http://markmail.org/message/5xrxt2w5m42nojkz

Have you tried both 32 and 64 bits builds?.

I have a handful of pending commits for vainilla Solaris 10 support, and I hope to be able to test SPARC builds in a few days.

PS: If you update your clone and have any issue, use as base a08c688aa99b, not "tip". I am going to rewrite some stuff and I rather prefer you have a "known" good codebase.

Thanks for your very helpful effort.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Feb 27 20:28:08 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 27 Feb 2012 19:28:08 +0000
Subject: [issue8706] accept keyword arguments on all base type methods and
	builtins
In-Reply-To: <1330363048.8.0.96558886381.issue8706@psf.upfronthosting.co.za>
Message-ID: <CAGE7PNLXDF8xnoAA=PELdDzua3m8wBi2JxN_b4tE+x3W8b8wBw@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

Several patches for sure!  and give the patch files useful names
indicating which things they touch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8706>
_______________________________________

From report at bugs.python.org  Mon Feb 27 21:11:06 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 27 Feb 2012 20:11:06 +0000
Subject: [issue8706] accept keyword arguments on all base type methods and
	builtins
In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>
Message-ID: <1330373466.0.0.158876530049.issue8706@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

On one hand I agree that it would be nice to get rid of these implementation details that prevent some C functions/methods to accept keyword args, but on the other hand I'm not sure that changing them all is the right thing to do.
For some functions/methods being able to pass keyword args make the code more readable/flexible, but for some other there's no real gain.
It also seems to me that since the arguments where only positional, not much thought went into choosing an appropriate name for these arguments.
For example str.join() is documented as str.join(iterable), and the C function calls the argument 'data'.
If we use those names, we won't have a chance to fix them later, so we should be careful before doing a mass-update.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8706>
_______________________________________

From report at bugs.python.org  Mon Feb 27 21:22:05 2012
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 27 Feb 2012 20:22:05 +0000
Subject: [issue8706] accept keyword arguments on all base type methods and
	builtins
In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>
Message-ID: <1330374125.97.0.972539498293.issue8706@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

> For some functions/methods being able to pass keyword args make the code more readable/flexible, but for some other there's no real gain.

I know what you're saying with the last part, but I think everyone becomes a winner in the consistency game if we expose kwargs regardless of level of improvement compared to other places.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8706>
_______________________________________

From report at bugs.python.org  Mon Feb 27 21:25:55 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 27 Feb 2012 20:25:55 +0000
Subject: [issue12151] test_logging fails sometimes
In-Reply-To: <1330368762.06.0.813701923216.issue12151@psf.upfronthosting.co.za>
Message-ID: <1330374353.89020.YahooMailNeo@web171315.mail.ir2.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> A similar failure to msg136576 has cropped up on the Windows 7 bot:

> 
> http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/4469/steps/test/logs/stdio

Right. Not making excuses, but this one is rather hard to find, as it's pretty hard to reproduce. That's why I haven't made any progress :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12151>
_______________________________________

From report at bugs.python.org  Mon Feb 27 21:31:39 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 27 Feb 2012 20:31:39 +0000
Subject: [issue8706] accept keyword arguments on all base type methods and
	builtins
In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>
Message-ID: <1330374699.97.0.867588540613.issue8706@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

FWIW PyPy doesn't seem to support keyword args for e.g. str.join() (so that's extra work for them too), and I don't see what would be the advantage of being able to do '-'.join(iterable=a_list).  Even if I also don't see a valid reason why that shouldn't work and realize that it might be surprising for someone, I'm not sure it's worth changing it just for the sake of being consistent everywhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8706>
_______________________________________

From report at bugs.python.org  Mon Feb 27 21:36:26 2012
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Mon, 27 Feb 2012 20:36:26 +0000
Subject: [issue8706] accept keyword arguments on all base type methods and
	builtins
In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>
Message-ID: <1330374986.6.0.535655660423.issue8706@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I would stay away from methods that accept just a single argument. For those that accept more, I think it's reasonable to allow keyword args.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8706>
_______________________________________

From report at bugs.python.org  Mon Feb 27 21:59:13 2012
From: report at bugs.python.org (Jon Brandvein)
Date: Mon, 27 Feb 2012 20:59:13 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
	mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1330376353.41.0.322831277559.issue4806@psf.upfronthosting.co.za>


Changes by Jon Brandvein <jon.brandvein at gmail.com>:


----------
nosy: +brandj

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4806>
_______________________________________

From report at bugs.python.org  Mon Feb 27 22:09:41 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 27 Feb 2012 21:09:41 +0000
Subject: [issue12151] test_logging fails sometimes
In-Reply-To: <1306106163.56.0.790245092521.issue12151@psf.upfronthosting.co.za>
Message-ID: <1330376981.79.0.596182490677.issue12151@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Not making excuses, but this one is rather hard to find, as it's pretty hard to reproduce. That's why I haven't made any progress :-(

Yeah, not having a reproducible test case is quite a pain.

(I suppose this should be reopened if the failure is still happening...)

----------
resolution: fixed -> 
stage:  -> test needed
status: closed -> open
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12151>
_______________________________________

From report at bugs.python.org  Mon Feb 27 22:50:03 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 27 Feb 2012 21:50:03 +0000
Subject: [issue14131] test_threading failure on WIndows 7 3.x buildbot
In-Reply-To: <1330259585.57.0.540126008704.issue14131@psf.upfronthosting.co.za>
Message-ID: <1330379403.87.0.0831142213856.issue14131@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Does Windows still have its once per day/week/whatever time synchronization, or does it use a proper NTP client?
Because this offset is way too large for a broken RTC lock, so it might simply be some process adjusting the clock behind our back (although it's too much for a typical NTP client, at least on Unix).
It could be interesting to replace time.time() by the new time.monotonic().

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14131>
_______________________________________

From report at bugs.python.org  Mon Feb 27 23:01:22 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Mon, 27 Feb 2012 22:01:22 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1330380082.3.0.924585399339.issue13405@psf.upfronthosting.co.za>


Marc Abramowitz <msabramo at gmail.com> added the comment:

I get a build error on FreeBSD 9.0:

make: don't know how to make ./Include/phelper_offsets.h. Stop

Any ideas?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Feb 27 23:27:41 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Mon, 27 Feb 2012 22:27:41 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1330381661.08.0.427325025453.issue13405@psf.upfronthosting.co.za>


Marc Abramowitz <msabramo at gmail.com> added the comment:

Re my comment in #154513, the following seems to fix that problem on FreeBSD 9.0:


[marca at freebsd9-0 ~/src/cpython-2011]$ hg diff Makefile.pre.in
diff -r 70dc1e48bd7f Makefile.pre.in
--- a/Makefile.pre.in	Mon Feb 27 22:43:17 2012 +0100
+++ b/Makefile.pre.in	Mon Feb 27 14:20:18 2012 -0800
@@ -632,7 +632,7 @@
 	else	touch $@ ; \
 	fi;
 
-Include/phelper_offsets.h: $(srcdir)/Include/phelper_offsets.c $(srcdir)/Python/ceval.o
+$(srcdir)/Include/phelper_offsets.h: $(srcdir)/Include/phelper_offsets.c $(srcdir)/Python/ceval.o
 	$(CC) $(PY_CFLAGS) -o $(srcdir)/Include/phelper_offsets \
 		$(srcdir)/Include/phelper_offsets.c
 	$(srcdir)/Include/phelper_offsets.sh $(DTRACE_NM) \

I'm now struggling with some other errors:

gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include  -DPy_BUILD_CORE  -c ./Modules/xxsubtype.c -o Modules/xxsubtype.o
if test "dtrace" != "" ; then  dtrace -o Python/dtrace.o -64  -C -G -s ./Include/pydtrace.d  Python/ceval.o Modules/gcmodule.o  Objects/classobject.o Objects/typeobject.o;  else    touch Python/dtrace.o ;  fi;
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include  -DPy_BUILD_CORE -o ./Include/phelper_offsets  ./Include/phelper_offsets.c
./Include/phelper_offsets.sh OTHER  ./Python/ceval.o ./Include/phelper_offsets >  ./Include/phelper_offsets.h
if test "dtrace" != "" ; then  dtrace -o Python/phelper.o -DPHELPER -64  -I. -IInclude -I./Include -C -G -s ./Include/phelper.d ;  else	touch Python/phelper.o ;  fi;
dtrace: failed to compile script ./Include/phelper.d: line 3: useless declaration
*** Error code 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Feb 27 23:40:45 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 27 Feb 2012 22:40:45 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1330382445.0.0.642807269355.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Marc, check your email. I am online in Jabber/XMPP. My JID is jcea at jabber.org. Can you send me a chat message there?. Google demands that you start the communication, possibly to avoid IM spam.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Feb 27 23:44:09 2012
From: report at bugs.python.org (Jay Deiman)
Date: Mon, 27 Feb 2012 22:44:09 +0000
Subject: [issue14144] urllib2 HTTPRedirectHandler not handling POST data in
	redirect
Message-ID: <1330382649.62.0.524230876085.issue14144@psf.upfronthosting.co.za>


New submission from Jay Deiman <admin at splitstreams.com>:

I've noticed that urllib2's HTTPRedirectHandler does not redirect a POST request with the POST data.  

If you send a POST request to a server with data, the data is dropped when the new Request is made to the new url.  As stated in a comment in the library itself, redirecting a POST request is not strictly RFC compliant, but it's generally supported anyway.  The problem here being that our POST data is not also being redirected.  I ran into this issue when writing a web api wrapper in Python.

I'm submitting a small patch that fixes this issue:


--- /usr/lib/python2.7/urllib2.py	2011-10-04 16:07:28.000000000 -0500
+++ urllib2.py	2012-02-27 16:03:36.000000000 -0600
@@ -551,7 +551,11 @@
             newheaders = dict((k,v) for k,v in req.headers.items()
                               if k.lower() not in ("content-length", "content-type")
                              )
+            data = None
+            if req.has_data():
+                data = req.get_data()
             return Request(newurl,
+                           data=data,
                            headers=newheaders,
                            origin_req_host=req.get_origin_req_host(),
                            unverifiable=True)

----------
components: Extension Modules
files: urllib2.py.patch
keywords: patch
messages: 154516
nosy: crustymonkey
priority: normal
severity: normal
status: open
title: urllib2 HTTPRedirectHandler not handling POST data in redirect
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file24665/urllib2.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14144>
_______________________________________

From report at bugs.python.org  Mon Feb 27 23:47:33 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 27 Feb 2012 22:47:33 +0000
Subject: [issue14144] urllib2 HTTPRedirectHandler not handling POST data in
	redirect
In-Reply-To: <1330382649.62.0.524230876085.issue14144@psf.upfronthosting.co.za>
Message-ID: <1330382853.04.0.563780686215.issue14144@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

If I recollect correctly, redirecting a POST request with POST data is not a recommended thing to do and could be a security hazard. That's why RFC prohibits it too. It is intentional that urllib2 is not redirecting carrying along the POST data. Could you show any browsers showing this behavior of redirecting along with POST?

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14144>
_______________________________________

From report at bugs.python.org  Tue Feb 28 00:01:54 2012
From: report at bugs.python.org (Nam Nguyen)
Date: Mon, 27 Feb 2012 23:01:54 +0000
Subject: [issue14119] Ability to adjust queue size in Executors
In-Reply-To: <1330129142.34.0.452763799677.issue14119@psf.upfronthosting.co.za>
Message-ID: <1330383714.08.0.47280460821.issue14119@psf.upfronthosting.co.za>


Changes by Nam Nguyen <bitsink at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file24666/executor-queue-size.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14119>
_______________________________________

From report at bugs.python.org  Tue Feb 28 00:07:50 2012
From: report at bugs.python.org (Jay Deiman)
Date: Mon, 27 Feb 2012 23:07:50 +0000
Subject: [issue14144] urllib2 HTTPRedirectHandler not handling POST data in
	redirect
In-Reply-To: <1330382649.62.0.524230876085.issue14144@psf.upfronthosting.co.za>
Message-ID: <1330384070.16.0.242796502038.issue14144@psf.upfronthosting.co.za>


Jay Deiman <admin at splitstreams.com> added the comment:

Senthil,

That is a good point about the potential for security issues.  What if it was an explicit option in HTTPRedirectHandler since there is a possibility of value in being able to do it.  I know my case is probably unusual, but I imagine that others might have run into this too.  Something roughly along this line is what I'm thinking:

----------------
class HTTPRedirectHandler(BaseHandler):
    redirect_post_data = False
    ...
    ...
    def redirect_request(self, req, fp, code, msg, headers, newurl):
        ...
        ...
        data = None
        if req.has_data() and self.redirect_post_data:
            data = req.get_data()
        return Request(newurl,
                       data=data,
                       headers=newheaders,
                       origin_req_host=req.get_origin_req_host(),
                       unverifiable=True)
----------------
That would leave the current default behavior as-is, but leave the option to explicitly override it by the user, perhaps with a BIG DISCLAIMER comment about security.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14144>
_______________________________________

From report at bugs.python.org  Tue Feb 28 00:50:21 2012
From: report at bugs.python.org (Narnie Harshoe)
Date: Mon, 27 Feb 2012 23:50:21 +0000
Subject: [issue14138] Ctrl-C does not terminate GTK3 Gtk.main() loop when
	program run from command line
In-Reply-To: <1330312408.32.0.611668312241.issue14138@psf.upfronthosting.co.za>
Message-ID: <1330386621.93.0.458004516601.issue14138@psf.upfronthosting.co.za>


Narnie Harshoe <signupnarnie at gmail.com> added the comment:

Understood. I didn't realize it was 3rd party.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14138>
_______________________________________

From report at bugs.python.org  Tue Feb 28 00:51:27 2012
From: report at bugs.python.org (Narnie Harshoe)
Date: Mon, 27 Feb 2012 23:51:27 +0000
Subject: [issue14137] GTK3 Segmentation fault from Warning: g_object_notify:
	assertion `G_IS_OBJECT (object)' failed
In-Reply-To: <1330311599.64.0.412967212338.issue14137@psf.upfronthosting.co.za>
Message-ID: <1330386687.7.0.318479309079.issue14137@psf.upfronthosting.co.za>


Narnie Harshoe <signupnarnie at gmail.com> added the comment:

Understood. Didn't realize pythonized GTK was 3rd party.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14137>
_______________________________________

From report at bugs.python.org  Tue Feb 28 01:03:46 2012
From: report at bugs.python.org (Narnie Harshoe)
Date: Tue, 28 Feb 2012 00:03:46 +0000
Subject: [issue14137] GTK3 Segmentation fault from Warning: g_object_notify:
	assertion `G_IS_OBJECT (object)' failed
In-Reply-To: <1330311599.64.0.412967212338.issue14137@psf.upfronthosting.co.za>
Message-ID: <1330387426.77.0.410111323265.issue14137@psf.upfronthosting.co.za>


Narnie Harshoe <signupnarnie at gmail.com> added the comment:

PyGtk and the python bindings for GTK3 seem to be separate entities. I could find nothing about GTK3 on pygtk.org. Any ideas where the bug reporting goes for the python bindings for GTK3?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14137>
_______________________________________

From report at bugs.python.org  Tue Feb 28 01:17:14 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 28 Feb 2012 00:17:14 +0000
Subject: [issue14133] improved PEP 409 implementation
In-Reply-To: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za>
Message-ID: <1330388234.55.0.867789346995.issue14133@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution: rejected -> 
status: closed -> open
Added file: http://bugs.python.org/file24667/pep415.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14133>
_______________________________________

From report at bugs.python.org  Tue Feb 28 02:37:06 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 28 Feb 2012 01:37:06 +0000
Subject: [issue8706] accept keyword arguments on all base type methods and
	builtins
In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>
Message-ID: <1330393026.64.0.31671066047.issue8706@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8706>
_______________________________________

From report at bugs.python.org  Tue Feb 28 03:03:44 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Feb 2012 02:03:44 +0000
Subject: [issue8706] accept keyword arguments on all base type methods and
	builtins
In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>
Message-ID: <1330394624.73.0.56706809807.issue8706@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

For many builtins, this would be a total waste, slowing down the calls, and supplying keyword names that would be meaningless or just weird.  For example, chr(i=65) is just a waste.

Keyword args should only be added where they would add clarity to something that would otherwise be ambiguous.

FWIW, that is the reason that sorted() required a keyword argument.  It prevents confusion between key-functions and cmp-functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8706>
_______________________________________

From report at bugs.python.org  Tue Feb 28 03:16:33 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 28 Feb 2012 02:16:33 +0000
Subject: [issue14133] improved PEP 409 implementation
In-Reply-To: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za>
Message-ID: <1330395393.6.0.205696392494.issue14133@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I don't think it's a good idea for setting one attribute to implicitly set another.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14133>
_______________________________________

From report at bugs.python.org  Tue Feb 28 03:24:15 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 28 Feb 2012 02:24:15 +0000
Subject: [issue8706] accept keyword arguments on all base type methods and
	builtins
In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>
Message-ID: <1330395855.19.0.776202443586.issue8706@psf.upfronthosting.co.za>


Ramchandra Apte <maniandram01 at gmail.com> added the comment:

See also issue14081 which got fixed.

----------
nosy: +ramchandra.apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8706>
_______________________________________

From report at bugs.python.org  Tue Feb 28 03:26:56 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 28 Feb 2012 02:26:56 +0000
Subject: [issue14139] test_ftplib: segfault
In-Reply-To: <1330341244.46.0.956938686476.issue14139@psf.upfronthosting.co.za>
Message-ID: <1330396016.54.0.374382531477.issue14139@psf.upfronthosting.co.za>


Ramchandra Apte <maniandram01 at gmail.com> added the comment:

On my Linux machine it does not crash.

----------
nosy: +ramchandra.apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14139>
_______________________________________

From report at bugs.python.org  Tue Feb 28 03:28:42 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 28 Feb 2012 02:28:42 +0000
Subject: [issue14133] improved PEP 409 implementation
In-Reply-To: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za>
Message-ID: <1330396122.0.0.206083394528.issue14133@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The alternatives are a backwards compatibility break (i.e. raise exc from other_exc would suppress the context, but exc.__cause__ = other_exc would not) or else that we don't succeed in eliminating the dual use of __cause__ in the display routines.

Given that those two problems are the reason I went for the PEP 409 approach in the first place, I'm really only interested in alternative approaches that eliminate them (such as setting the flag automatically whenever __cause__ is set). If you don't like it, then we already have PEP 409's Ellipsis based implementation which meets my criteria.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14133>
_______________________________________

From report at bugs.python.org  Tue Feb 28 03:30:40 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 28 Feb 2012 02:30:40 +0000
Subject: [issue14133] improved PEP 409 implementation
In-Reply-To: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za>
Message-ID: <1330396240.95.0.582386359793.issue14133@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Also, ensuring class invariants by setting derived attributes correctly is one of the primary use cases for properties, so objecting to my proposed approach is objecting to a fairly fundamental programming technique.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14133>
_______________________________________

From report at bugs.python.org  Tue Feb 28 03:32:14 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 28 Feb 2012 02:32:14 +0000
Subject: [issue8706] accept keyword arguments on all base type methods and
	builtins
In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>
Message-ID: <1330396334.07.0.124898344837.issue8706@psf.upfronthosting.co.za>


Ramchandra Apte <maniandram01 at gmail.com> added the comment:

Can we have keyword arguments to range([start],stop,[step])?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8706>
_______________________________________

From report at bugs.python.org  Tue Feb 28 04:13:03 2012
From: report at bugs.python.org (Griffin Smith)
Date: Tue, 28 Feb 2012 03:13:03 +0000
Subject: [issue14145] string.rfind() returns AttributeError: 'list' object has
	no attribute 'rfind'
Message-ID: <1330398783.39.0.669167719061.issue14145@psf.upfronthosting.co.za>


New submission from Griffin Smith <wildgriffin45 at gmail.com>:

This occurs even when calling methods in modules (such as os.path.splitext), so I know it's not happening due to an error on my part

Win7 SP1

----------
components: Windows
messages: 154529
nosy: glittershark
priority: normal
severity: normal
status: open
title: string.rfind() returns AttributeError: 'list' object has no attribute 'rfind'
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14145>
_______________________________________

From report at bugs.python.org  Tue Feb 28 04:41:17 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 28 Feb 2012 03:41:17 +0000
Subject: [issue14145] string.rfind() returns AttributeError: 'list' object has
	no attribute 'rfind'
In-Reply-To: <1330398783.39.0.669167719061.issue14145@psf.upfronthosting.co.za>
Message-ID: <1330400477.59.0.749329097695.issue14145@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You'll have to give more details about what you are doing, but I suspect you are in fact calling it incorrectly.  In addition, there are pretty much no circumstances in which you want to use string.rfind in 2.7.  Just use ''.rfind.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14145>
_______________________________________

From report at bugs.python.org  Tue Feb 28 04:50:59 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 28 Feb 2012 03:50:59 +0000
Subject: [issue14145] string.rfind() returns AttributeError: 'list' object has
	no attribute 'rfind'
In-Reply-To: <1330398783.39.0.669167719061.issue14145@psf.upfronthosting.co.za>
Message-ID: <1330401059.78.0.317610233469.issue14145@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, perhaps you *meant* you are calling rfind on a string, rather than calling rfind on the 'string' module as I imagined.

So, we definitely need more details about how you are producing this failure and what the traceback looks like.  'abc'.rfind('a') works fine for me, and works fine on Windows in our unit tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14145>
_______________________________________

From report at bugs.python.org  Tue Feb 28 04:57:40 2012
From: report at bugs.python.org (Griffin Smith)
Date: Tue, 28 Feb 2012 03:57:40 +0000
Subject: [issue14145] string.rfind() returns AttributeError: 'list' object has
	no attribute 'rfind'
In-Reply-To: <1330398783.39.0.669167719061.issue14145@psf.upfronthosting.co.za>
Message-ID: <1330401460.36.0.0254554130679.issue14145@psf.upfronthosting.co.za>


Griffin Smith <wildgriffin45 at gmail.com> added the comment:

Sorry about the lack of clarity there.

I'm calling os.path.splitext("C:\blah.ext") and trackback is returning an AttributeError: 'list' object has no attribute 'rfind' from within the definition for splitext in the NTPath module.

That's only the specific usage that brought about the error - I'm getting it for all calls to rfind everywhere.

I will admit it's a very strange error - I did some searching around and nobody else is experiencing the bug, so clearly it's a problem with my particular installation of Python. I haven't used any third-party Python extensions, however, and everything seems like it's as vanilla as possible to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14145>
_______________________________________

From report at bugs.python.org  Tue Feb 28 05:01:48 2012
From: report at bugs.python.org (Rich Rauenzahn)
Date: Tue, 28 Feb 2012 04:01:48 +0000
Subject: [issue14146] IDLE: source line in editor doesn't highlight when
	debugging
Message-ID: <1330401708.67.0.511106941359.issue14146@psf.upfronthosting.co.za>


New submission from Rich Rauenzahn <rrauenza at gmail.com>:

Using 64bit python for windows downloaded from python.org on 64bit windows 7.

Python Version 3.2.2
Tk version 8.5
IDLE version 3.2.2

When stepping through code the corresponding line in the editor does not highlight with the code steps.  The windows does update the contents, so it appears to be tracking, but just fails to highlight the line.

Double clicking on the line in the debugger will go ahead and highlight it.  My settings are all default, and I've double checked the color schemes in the "highlighting" dialog.

----------
components: IDLE
messages: 154533
nosy: Rich.Rauenzahn
priority: normal
severity: normal
status: open
title: IDLE: source line in editor doesn't highlight when debugging
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14146>
_______________________________________

From report at bugs.python.org  Tue Feb 28 06:16:06 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Feb 2012 05:16:06 +0000
Subject: [issue8706] accept keyword arguments on all base type methods and
	builtins
In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>
Message-ID: <1330406166.3.0.404070094989.issue8706@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

range() has been around 20+ years and there has been zero need for keyword arguments for it.

FWIW, the maxsplit keyword argument was a case where a keyword argument added clarity, and there may be a handful of other cases that are also warranted.  Greg Smith's idea for "start" for str.find() may be one of those.   

People are welcome to propose individual suggestions in separate tracker items; however, if someone wants a wholesale set of changes to core builtins, then they should discuss it on python-ideas.  It would also be worthwhile for someone to benchmark the performance cost of switching from "METH_O" to "METH_VARARGS | METH_KEYWORDS".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8706>
_______________________________________

From report at bugs.python.org  Tue Feb 28 08:13:13 2012
From: report at bugs.python.org (Remi Pointel)
Date: Tue, 28 Feb 2012 07:13:13 +0000
Subject: [issue12905] multiple errors in test_socket on OpenBSD
In-Reply-To: <1315258413.34.0.212082169153.issue12905@psf.upfronthosting.co.za>
Message-ID: <1330413193.06.0.251997575336.issue12905@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

I think we could close this bug because it's du to the pthread library on OpenBSD and not Python.
We are switching to rthreads and I can't reproduce this bug.

Thanks for your help and sorry for the delay.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12905>
_______________________________________

From report at bugs.python.org  Tue Feb 28 08:13:33 2012
From: report at bugs.python.org (Remi Pointel)
Date: Tue, 28 Feb 2012 07:13:33 +0000
Subject: [issue12903] test_io.test_interrupte[r]d* blocks on OpenBSD
In-Reply-To: <1315252314.97.0.81854089556.issue12903@psf.upfronthosting.co.za>
Message-ID: <1330413213.69.0.176142286198.issue12903@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

I think we could close this bug because it's du to the pthread library on OpenBSD and not Python.
We are switching to rthreads and I can't reproduce this bug.

Thanks for your help and sorry for the delay.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12903>
_______________________________________

From report at bugs.python.org  Tue Feb 28 08:36:53 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 28 Feb 2012 07:36:53 +0000
Subject: [issue12905] multiple errors in test_socket on OpenBSD
In-Reply-To: <1315258413.34.0.212082169153.issue12905@psf.upfronthosting.co.za>
Message-ID: <1330414613.95.0.347975236328.issue12905@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I think we could close this bug because it's du to the pthread library 
> on OpenBSD and not Python.

Indeed.

----------
resolution:  -> invalid
stage:  -> committed/rejected
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12905>
_______________________________________

From report at bugs.python.org  Tue Feb 28 08:37:18 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 28 Feb 2012 07:37:18 +0000
Subject: [issue12903] test_io.test_interrupte[r]d* blocks on OpenBSD
In-Reply-To: <1315252314.97.0.81854089556.issue12903@psf.upfronthosting.co.za>
Message-ID: <1330414638.39.0.503076563982.issue12903@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
resolution:  -> invalid
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12903>
_______________________________________

From report at bugs.python.org  Tue Feb 28 09:20:31 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 28 Feb 2012 08:20:31 +0000
Subject: [issue12905] multiple errors in test_socket on OpenBSD
In-Reply-To: <1315258413.34.0.212082169153.issue12905@psf.upfronthosting.co.za>
Message-ID: <1330417231.18.0.293612057855.issue12905@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12905>
_______________________________________

From report at bugs.python.org  Tue Feb 28 09:47:30 2012
From: report at bugs.python.org (lilei)
Date: Tue, 28 Feb 2012 08:47:30 +0000
Subject: [issue14147] print r"\" cause SyntaxError
Message-ID: <1330418850.42.0.159103996414.issue14147@psf.upfronthosting.co.za>


New submission from lilei <vbem at 163.com>:

$ python
Python 2.7.1 (r271:86832, Apr 16 2011, 23:27:12) 
[GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print r'\'
  File "<stdin>", line 1
    print r'\'
             ^
SyntaxError: EOL while scanning string literal
>>> 

I just want to print a raw string r'\', however, SyntaxError.
What is the reason?

----------
components: None
messages: 154538
nosy: vbem
priority: normal
severity: normal
status: open
title: print r"\" cause SyntaxError
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14147>
_______________________________________

From report at bugs.python.org  Tue Feb 28 09:48:38 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 28 Feb 2012 08:48:38 +0000
Subject: [issue14147] print r"\" cause SyntaxError
In-Reply-To: <1330418850.42.0.159103996414.issue14147@psf.upfronthosting.co.za>
Message-ID: <1330418918.04.0.133640642744.issue14147@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See http://docs.python.org/faq/design.html#why-can-t-raw-strings-r-strings-end-with-a-backslash

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14147>
_______________________________________

From report at bugs.python.org  Tue Feb 28 09:54:02 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 28 Feb 2012 08:54:02 +0000
Subject: [issue13876] Sporadic failure in test_socket
In-Reply-To: <1327588563.2.0.447366914719.issue13876@psf.upfronthosting.co.za>
Message-ID: <1330419242.66.0.0498125952147.issue13876@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

The same failure has appeared on the Debian bigmem buildbot:

http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/152/steps/test/logs/stdio

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13876>
_______________________________________

From report at bugs.python.org  Tue Feb 28 10:21:04 2012
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 28 Feb 2012 09:21:04 +0000
Subject: [issue14145] string.rfind() returns AttributeError: 'list' object has
	no attribute 'rfind'
In-Reply-To: <1330398783.39.0.669167719061.issue14145@psf.upfronthosting.co.za>
Message-ID: <1330420864.67.0.296135571982.issue14145@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I can't reproduce this. Can you please post the entire traceback? It would be preferable if you could also show the exact code that's causing the problem, typed from a python command prompt (see my example below).

I can reproduce the error if I pass a list to ps.path.splitext(), which is what I suspect you're doing:

>>> os.path.splitext(['c:\\blah.ext'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/posixpath.py", line 95, in splitext
    return genericpath._splitext(p, sep, altsep, extsep)
  File "/usr/lib/python2.6/genericpath.py", line 91, in _splitext
    sepIndex = p.rfind(sep)
AttributeError: 'list' object has no attribute 'rfind'

And you probably want: os.path.splitext("C:\\blah.ext"), so as to escape the backslash.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14145>
_______________________________________

From report at bugs.python.org  Tue Feb 28 11:37:38 2012
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 28 Feb 2012 10:37:38 +0000
Subject: [issue14136] Simplify PEP 409 command line test and move it to
	test_cmd_line_script
In-Reply-To: <1330309400.02.0.0793594491787.issue14136@psf.upfronthosting.co.za>
Message-ID: <1330425458.4.0.530632084062.issue14136@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Changed TestTraceback.test_traceback_verbiage to use test.support and test.script_helper (much simpler now, thanks Antoine!).

It is still in test_raise, however.  

I do not understand why we would put it in test_cmd_line_script -- it seems to me that test_cmd_line_script is to verify that python is working correctly when executing scripts, but for this test we are assuming that python does work correctly when executing scripts and we testing the verbiage from raising exceptions.

----------
keywords: +patch
nosy: +stoneleaf
Added file: http://bugs.python.org/file24668/raise_from_none_test_cleanup.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14136>
_______________________________________

From report at bugs.python.org  Tue Feb 28 11:39:52 2012
From: report at bugs.python.org (Robin Becker)
Date: Tue, 28 Feb 2012 10:39:52 +0000
Subject: [issue8170] Wrong Paths for distutils build --plat-name=win-amd64
In-Reply-To: <1268913333.33.0.305416760988.issue8170@psf.upfronthosting.co.za>
Message-ID: <1330425592.73.0.44037550936.issue8170@psf.upfronthosting.co.za>


Robin Becker <rgbecker at users.sourceforge.net> added the comment:

Some context. ReportLab windows exe installers for pythons 2.x x=4-7 are built on a single 32bit machine with 32bit pythons using a code that looks like this

set FT_LIB=c:\devel\libs_x86\freetype.lib
\python2x\python setup.py bdist_wininst --bitmap=%BMP% --title="ReportLab"

we build the 64 bit versions for 2.6 & 2.7 only. In those cases an extra step does

set FT_LIB=c:\devel\libs_amd64\freetype.lib
\python2.x\python setup.py bdist_wininst --bitmap=%BMP% --plat-name=win-amd64 --title="ReportLab"

To make this work I have copied from 64bit win32 installs of python2.6/7 various lib/dll/pyds. These live in 

C:\Python2x\PCBuild\AMD64

eg
C:\ux\ExeBuilder>ls \Python26\PCBuild\AMD64
_bsddb.lib            _socket.lib           pyexpat.lib
_bsddb.pyd            _socket.pyd           pyexpat.pyd
_ctypes.lib           _sqlite3.lib          python26.dll
_ctypes.pyd           _sqlite3.pyd          python26.lib
_ctypes_test.lib      _ssl.lib              select.lib
_ctypes_test.pyd      _ssl.pyd              select.pyd
_elementtree.lib      _testcapi.lib         sqlite3.dll
_elementtree.pyd      _testcapi.pyd         tcl85.dll
_hashlib.lib          _tkinter.lib          tclpip85.dll
_hashlib.pyd          _tkinter.pyd          tk85.dll
_msi.lib              bz2.lib               unicodedata.lib
_msi.pyd              bz2.pyd               unicodedata.pyd
_multiprocessing.lib  py.ico                winsound.lib
_multiprocessing.pyd  pyc.ico               winsound.pyd

I followed most of section 5.4 in http://docs.python.org/distutils/builtdist.html to get this almost working, but got problems related to the library paths which my patch appears to fix (I seem to get working exes out of this approach).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8170>
_______________________________________

From report at bugs.python.org  Tue Feb 28 11:44:03 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 28 Feb 2012 10:44:03 +0000
Subject: [issue14136] Simplify PEP 409 command line test and move it to
	test_cmd_line_script
In-Reply-To: <1330309400.02.0.0793594491787.issue14136@psf.upfronthosting.co.za>
Message-ID: <1330425843.0.0.613436442022.issue14136@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It's about separating out the testing of the command line executable (i.e. test_cmd_line and test_cmd_line_script) from that of the interpreter's internal behaviour.

test_raise is about making sure the "raise" statement works correctly - the new test isn't testing that, it's testing the display code in the command line interface.

A non-CPython interpreter must conform exactly to test_raise, but conforming to test_cmd_line(_script) is less essential.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14136>
_______________________________________

From report at bugs.python.org  Tue Feb 28 12:00:53 2012
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 28 Feb 2012 11:00:53 +0000
Subject: [issue14136] Simplify PEP 409 command line test and move it to
	test_cmd_line_script
In-Reply-To: <1330309400.02.0.0793594491787.issue14136@psf.upfronthosting.co.za>
Message-ID: <1330426853.18.0.420818744947.issue14136@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Is there a better place, then, than test_cmd_line_script?

The entire purpose of PEP 409 is to allow the suppression of non-relevant information in the exception traceback.  As such I would expect every Python interpreter to adhere to it.

(Yes, I understand that custom display hooks can still do different things, but they are custom and not the default.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14136>
_______________________________________

From report at bugs.python.org  Tue Feb 28 12:05:29 2012
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 28 Feb 2012 11:05:29 +0000
Subject: [issue14136] Simplify PEP 409 command line test and move it to
	test_cmd_line_script
In-Reply-To: <1330309400.02.0.0793594491787.issue14136@psf.upfronthosting.co.za>
Message-ID: <1330427129.8.0.953046226625.issue14136@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

I guess the crux of the issue for me is that I'm trying to test interpreter output, and the fact that I am using a command-line script to do so is an implementation detail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14136>
_______________________________________

From report at bugs.python.org  Tue Feb 28 12:30:21 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 28 Feb 2012 11:30:21 +0000
Subject: [issue14136] Simplify PEP 409 command line test and move it to
	test_cmd_line_script
In-Reply-To: <1330309400.02.0.0793594491787.issue14136@psf.upfronthosting.co.za>
Message-ID: <1330428621.93.0.707130481762.issue14136@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

test_cmd_line and test_cmd_line_script are both about testing the behaviour of the interpreter when run from the command line. Since this test *is* a behavioural test for the interpreter when invoked as an application, it should be in one of them.

The former is for testing the behaviour that doesn't involve invoking a script that does something, whereas the latter is for testing the way the interpreter handles various methods of script invocation, *including* what it prints to stderr and stdout in various scenarios.

Therefore, test_cmd_line_script *is* the right place for it. The fact that it happens to be testing the way an exception is displayed doesn't change the fact that it's a test of the way the interpreter handles a particular situation that may arise when running a script.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14136>
_______________________________________

From report at bugs.python.org  Tue Feb 28 12:36:35 2012
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 28 Feb 2012 11:36:35 +0000
Subject: [issue8170] Wrong Paths for distutils build --plat-name=win-amd64
In-Reply-To: <1268913333.33.0.305416760988.issue8170@psf.upfronthosting.co.za>
Message-ID: <1330428995.57.0.849365643387.issue8170@psf.upfronthosting.co.za>


Mark Hammond <skippy.hammond at gmail.com> added the comment:

Can't you just install a 64bit Python in a different directory and use that executable to build the 64bit installer?  It seems less error prone and should work without manually copying stuff or changing any code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8170>
_______________________________________

From report at bugs.python.org  Tue Feb 28 12:43:00 2012
From: report at bugs.python.org (Paul Moore)
Date: Tue, 28 Feb 2012 11:43:00 +0000
Subject: [issue14148] Option to kill "stuck" workers in a multiprocessing pool
Message-ID: <1330429380.32.0.0524478586738.issue14148@psf.upfronthosting.co.za>


New submission from Paul Moore <p.f.moore at gmail.com>:

I have an application which fires off a number of database connections via a multiprocessing pool. Unfortunately, the database software occasionally gets "stuck" and a connection request hangs indefinitely. This locks up the whole process doing the connection, and cannot be interrupted except by killing the process.

It would be useful to have a facility to restart "stuck" workers in this case.

As an interface, I would suggest an additional argument to the AsyncResult.get method, kill_on_timeout. If this argument is true, and the get times out, the worker servicing the result will be killed and restarted.

Alternatively, provide a method on an AsyncResult to access the worker process that is servicing the request. I could then wait on the result and kill the worker manually if it does not respond in time.

Without a facility like this, there is a potential for the pool to get starved of workers if multiple connections hang.

----------
components: Library (Lib)
messages: 154549
nosy: pmoore
priority: normal
severity: normal
status: open
title: Option to kill "stuck" workers in a multiprocessing pool
type: enhancement
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14148>
_______________________________________

From report at bugs.python.org  Tue Feb 28 13:23:55 2012
From: report at bugs.python.org (Joseph Birr-Pixton)
Date: Tue, 28 Feb 2012 12:23:55 +0000
Subject: [issue14149] Argparse usage model requires argument names to be
	python identifiers
Message-ID: <1330431835.85.0.549489798388.issue14149@psf.upfronthosting.co.za>


New submission from Joseph Birr-Pixton <jpixton at gmail.com>:

Say I have an argument with the name 'foo-bar'.  Argparse accepts and parses arguments, but Namespace does not allow me to access the value.

Yes, I can use getattr or Namespace.__dict__.  But that's ugly.
Yes, I can change the name of the argument, but that's not what I want in my help output.

I think it should either:
- Collapse names to valid python identifiers (optparse did this).
- Namespace should act like an object and dict.

----------
components: Library (Lib)
files: argparsetest.py
messages: 154550
nosy: Joseph.Birr-Pixton
priority: normal
severity: normal
status: open
title: Argparse usage model requires argument names to be python identifiers
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file24669/argparsetest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14149>
_______________________________________

From report at bugs.python.org  Tue Feb 28 14:06:00 2012
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 28 Feb 2012 13:06:00 +0000
Subject: [issue13903] New shared-keys dictionary implementation
In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za>
Message-ID: <1330434360.38.0.635681939444.issue13903@psf.upfronthosting.co.za>


Changes by Mark Shannon <mark at hotpy.org>:


Added file: http://bugs.python.org/file24670/49b7e7e4a27c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13903>
_______________________________________

From report at bugs.python.org  Tue Feb 28 14:06:09 2012
From: report at bugs.python.org (=?utf-8?q?Jan_St=C3=BCrtz?=)
Date: Tue, 28 Feb 2012 13:06:09 +0000
Subject: [issue14150] AIX,
	crash loading shared module into another process than python like
	operator.so results in 0509-130
Message-ID: <1330434369.23.0.116359457055.issue14150@psf.upfronthosting.co.za>


New submission from Jan St?rtz <stuertz at googlemail.com>:

AIX 5.2.0.0 with gcc 4.3.0:
Compiling a shared python:
with:
./configure --enable-shared --with-gcc --disable-ipv6 --with-system-ffi
make; make install

results in a working build.
But when I build mod_wsgi into apache with this python and run it I get the follwoing exception when importing e.g. cgi.

Traceback (most recent call last):
  File "/devel/js/src/trunk/cdb/wsgi/static.py", line 256, in application
    status, response_headers, output = resources(environ, path_info[1:])
  File "/devel/js/src/trunk/cdb/wsgi/static.py", line 238, in resources
    "/".join(path_info[1:]), (os.environ["CADDOK_BASE"], os.environ["CADDOK_HOME"]))
  File "/devel/js/src/trunk/cdb/wsgi/static.py", line 105, in _find_file
    import cgi
  File "/devel/js/src/trunk/aix5/debug/img/lib/python2.7/cgi.py", line 37, in 
    from operator import attrgetter
ImportError: 	0509-130 Die Symbolaufl?sung f?r /devel/js/src/trunk/aix5/debug/img/lib/python2.7/lib-dynload/operator.so ist fehlgeschlagen. Ursache:
	0509-136   Symbol _PyArg_NoKeywords (Nummer 1) wurde nicht von
		   abh?ngigem Modul httpd exportiert.
	0509-136   Symbol PyArg_ParseTuple (Nummer 2) wurde nicht von
		   abh?ngigem Modul httpd exportiert.
	0509-136   Symbol PyArg_UnpackTuple (Nummer 3) wurde nicht von
		   abh?ngigem Modul httpd exportiert.
	0509-136   Symbol PyBool_FromLong (Nummer 4) wurde nicht von
		   abh?ngigem Modul httpd exportiert.
	0509-136   Symbol PyCallable_Check (Nummer 5) wurde nicht von
		   abh?ngigem Modul httpd exportiert.
	0509-136   Symbol PyErr_SetString (Nummer 6) wurde nicht von
		   abh?ngigem Modul httpd exportiert.
	0509-021 Es sind noch weitere Fehler aufgetreten, die aber nicht gemeldet wurden.
	0509-192 ?berpr?fen Sie die Symbole des Abschnitts .loader mit dem
		 Befehl 'dump -Tv'.

I stripped that problem down to a somewhat incorrect python.exp file for the linker.
Tis python.exp file is used as import file to the aix linker when linking the modules in lib-dynload.

So operator.so expects its Symbols like "_PyArg_NoKeywords" to appear in the main executable.

Looking with "dump -HTv" on operator.so results in:
dump -HTv lib/python2.7/lib-dynload/operator.so 

lib/python2.7/lib-dynload/operator.so:

                        ***Abschnitt f?r Ladeprogramm***
                      Header-Daten zum Ladeprogramm
VERSION#         #SYMtableENT     #RELOCent        LENidSTR
0x00000001       0x00000060       0x000002c4       0x00000208       

#IMPfilID        OFFidSTR         LENstrTBL        OFFstrTBL
0x00000004       0x00002a50       0x00000700       0x00002c58       


                        ***Dateizeichenfolgen importieren***
INDEX  PFAD                          BASIS               MEMBER              
0      /devel/js/trunk_E017100_python27/aix5/debug/img/lib:/usr/local/lib:/usr/local/contact/sdk/1.1/lib/gcc/powerpc-ibm-aix5.2.0.0/4.3.0/pthread:/usr/local/contact/sdk/1.1/lib/gcc/powerpc-ibm-aix5.2.0.0/4.3.0/../../../pthread:/usr/local/contact/sdk/1.1/lib/gcc/powerpc-ibm-aix5.2.0.0/4.3.0:/usr/local/contact/sdk/1.1/lib/gcc/powerpc-ibm-aix5.2.0.0/4.3.0/../../../../powerpc-ibm-aix5.2.0.0/lib:/usr/local/contact/sdk/1.1/lib/gcc/powerpc-ibm-aix5.2.0.0/4.3.0/../../..:/usr/lib:/lib                                         
1                                    libpthreads.a       shr_xpg5.o          
2                                    libc.a              shr.o               
3                                    .                                       

                        ***Informationen zur Symboltabelle des Ladeprogramms***
[Index]      Wert       Scn     IMEX Sclass   Typ            IMPid Name

[0]     0x20002338    .data              RW SECdef        [noIMid] __rtinit
[1]     0x00000000    undef      IMP     DS EXTref               . _PyArg_NoKeywords
[2]     0x00000000    undef      IMP     DS EXTref               . PyArg_ParseTuple
[3]     0x00000000    undef      IMP     DS EXTref               . PyArg_UnpackTuple
[4]     0x00000000    undef      IMP     DS EXTref               . PyBool_FromLong
[5]     0x00000000    undef      IMP     DS EXTref               . PyCallable_Check
[6]     0x00000000    undef      IMP     DS EXTref               . PyErr_SetString
[7]     0x00000000    undef      IMP     DS EXTref               . PyErr_WarnEx
[8]     0x00000000    undef      IMP     PR EXTref               . PyExc_DeprecationWarning
[9]     0x00000000    undef      IMP     PR EXTref               . PyExc_TypeError
[10]    0x00000000    undef      IMP     DS EXTref               . Py_InitModule4
[11]    0x00000000    undef      IMP     DS EXTref               . PyInt_FromSsize_t
[12]    0x00000000    undef      IMP     DS EXTref               . PyMapping_Check
[13]    0x00000000    undef      IMP     DS EXTref               . PyModule_AddObject
[14]    0x00000000    undef      IMP     PR EXTref               . _Py_NoneStruct
[15]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Absolute
[16]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Add
[17]    0x00000000    undef      IMP     DS EXTref               . PyNumber_And
[18]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Check
[19]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Divide
[20]    0x00000000    undef      IMP     DS EXTref               . PyNumber_FloorDivide
[21]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Index
[22]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceAdd
[23]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceAnd
[24]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceDivide
[25]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceFloorDivide
[26]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceLshift
[27]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceMultiply
[28]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceOr
[29]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlacePower
[30]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceRemainder
[31]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceRshift
[32]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceSubtract
[33]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceTrueDivide
[34]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceXor
[35]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Invert
[36]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Lshift
[37]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Multiply
[38]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Negative
[39]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Or
[40]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Positive
[41]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Power
[42]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Remainder
[43]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Rshift
[44]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Subtract
[45]    0x00000000    undef      IMP     DS EXTref               . PyNumber_TrueDivide
[46]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Xor
[47]    0x00000000    undef      IMP     DS EXTref               . PyObject_Call
[48]    0x00000000    undef      IMP     DS EXTref               . PyObject_DelItem
[49]    0x00000000    undef      IMP     DS EXTref               . PyObject_GC_Del
[50]    0x00000000    undef      IMP     DS EXTref               . _PyObject_GC_New
[51]    0x00000000    undef      IMP     DS EXTref               . PyObject_GC_Track
[52]    0x00000000    undef      IMP     DS EXTref               . PyObject_GC_UnTrack
[53]    0x00000000    undef      IMP     PR EXTref               . PyObject_GenericGetAttr
[54]    0x00000000    undef      IMP     DS EXTref               . PyObject_GetAttr
[55]    0x00000000    undef      IMP     DS EXTref               . PyObject_GetItem
[56]    0x00000000    undef      IMP     DS EXTref               . PyObject_IsTrue
[57]    0x00000000    undef      IMP     DS EXTref               . PyObject_Not
[58]    0x00000000    undef      IMP     DS EXTref               . PyObject_RichCompare
[59]    0x00000000    undef      IMP     DS EXTref               . PyObject_SetItem
[60]    0x00000000    undef      IMP     PR EXTref               . Py_Py3kWarningFlag
[61]    0x00000000    undef      IMP     DS EXTref               . PySequence_Check
[62]    0x00000000    undef      IMP     DS EXTref               . PySequence_Concat
[63]    0x00000000    undef      IMP     DS EXTref               . PySequence_Contains
[64]    0x00000000    undef      IMP     DS EXTref               . PySequence_Count
[65]    0x00000000    undef      IMP     DS EXTref               . PySequence_DelSlice
[66]    0x00000000    undef      IMP     DS EXTref               . PySequence_GetSlice
[67]    0x00000000    undef      IMP     DS EXTref               . PySequence_Index
[68]    0x00000000    undef      IMP     DS EXTref               . PySequence_InPlaceConcat
[69]    0x00000000    undef      IMP     DS EXTref               . PySequence_InPlaceRepeat
[70]    0x00000000    undef      IMP     DS EXTref               . PySequence_Repeat
[71]    0x00000000    undef      IMP     DS EXTref               . PySequence_SetSlice
[72]    0x00000000    undef      IMP     DS EXTref               . PyString_FromString
[73]    0x00000000    undef      IMP     DS EXTref               . PyString_FromStringAndSize
[74]    0x00000000    undef      IMP     PR EXTref               . _Py_TrueStruct
[75]    0x00000000    undef      IMP     DS EXTref               . PyTuple_GetSlice
[76]    0x00000000    undef      IMP     DS EXTref               . PyTuple_New
[77]    0x00000000    undef      IMP     DS EXTref               . PyType_Ready
[78]    0x00000000    undef      IMP     DS EXTref               . _PyUnicodeUCS2_AsDefaultEncodedString
[79]    0x00000000    undef      IMP     PR EXTref               . _Py_ZeroStruct
[80]    0x0000e008    undef      IMP     XO EXTref   libc.a(shr.o) ___memset
[81]    0x0000f000    undef      IMP     XO EXTref   libc.a(shr.o) ___memmove
[82]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) malloc
[83]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) realloc
[84]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) free
[85]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) calloc
[86]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) strlen
[87]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) strchr
[88]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) abort
[89]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_getspecific
[90]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_setspecific
[91]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_key_create
[92]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_once
[93]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_mutex_unlock
[94]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_mutex_lock
[95]    0x200023a8    .data EXPentPT     DS   Ldef        [noIMid] initoperator

But when I change the python Makefile right after configure, so that 
the first line of the python.exp (The !# line) looks this way:

old:
#!.
new:
#!libpython2.7.so

and rebuild every thing it works fine to me, because symbol resolution is fixed to use libpython.so.

So dump -HVtt looks that way:
-bash-2.05b$ dump -HTv lib/python2.7/lib-dynload/operator.so 

lib/python2.7/lib-dynload/operator.so:

                        ***Abschnitt f?r Ladeprogramm***
                      Header-Daten zum Ladeprogramm
VERSION#         #SYMtableENT     #RELOCent        LENidSTR
0x00000001       0x00000060       0x000002c4       0x00000216       

#IMPfilID        OFFidSTR         LENstrTBL        OFFstrTBL
0x00000004       0x00002a50       0x00000700       0x00002c66       


                        ***Dateizeichenfolgen importieren***
INDEX  PFAD                          BASIS               MEMBER              
0      /devel/js/trunk_E017100_python27/aix5/debug/img/lib:/usr/local/lib:/usr/local/contact/sdk/1.1/lib/gcc/powerpc-ibm-aix5.2.0.0/4.3.0/pthread:/usr/local/contact/sdk/1.1/lib/gcc/powerpc-ibm-aix5.2.0.0/4.3.0/../../../pthread:/usr/local/contact/sdk/1.1/lib/gcc/powerpc-ibm-aix5.2.0.0/4.3.0:/usr/local/contact/sdk/1.1/lib/gcc/powerpc-ibm-aix5.2.0.0/4.3.0/../../../../powerpc-ibm-aix5.2.0.0/lib:/usr/local/contact/sdk/1.1/lib/gcc/powerpc-ibm-aix5.2.0.0/4.3.0/../../..:/usr/lib:/lib                                         
1                                    libpthreads.a       shr_xpg5.o          
2                                    libc.a              shr.o               
3                                    libpython2.7.so                         

                        ***Informationen zur Symboltabelle des Ladeprogramms***
[Index]      Wert       Scn     IMEX Sclass   Typ            IMPid Name

[0]     0x20002338    .data              RW SECdef        [noIMid] __rtinit
[1]     0x00000000    undef      IMP     DS EXTref libpython2.7.so _PyArg_NoKeywords
[2]     0x00000000    undef      IMP     DS EXTref libpython2.7.so PyArg_ParseTuple
[3]     0x00000000    undef      IMP     DS EXTref libpython2.7.so PyArg_UnpackTuple
[4]     0x00000000    undef      IMP     DS EXTref libpython2.7.so PyBool_FromLong
[5]     0x00000000    undef      IMP     DS EXTref libpython2.7.so PyCallable_Check
[6]     0x00000000    undef      IMP     DS EXTref libpython2.7.so PyErr_SetString
[7]     0x00000000    undef      IMP     DS EXTref libpython2.7.so PyErr_WarnEx
[8]     0x00000000    undef      IMP     PR EXTref libpython2.7.so PyExc_DeprecationWarning
[9]     0x00000000    undef      IMP     PR EXTref libpython2.7.so PyExc_TypeError
[10]    0x00000000    undef      IMP     DS EXTref libpython2.7.so Py_InitModule4
[11]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyInt_FromSsize_t
[12]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyMapping_Check
[13]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyModule_AddObject
[14]    0x00000000    undef      IMP     PR EXTref libpython2.7.so _Py_NoneStruct
[15]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Absolute
[16]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Add
[17]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_And
[18]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Check
[19]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Divide
[20]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_FloorDivide
[21]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Index
[22]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceAdd
[23]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceAnd
[24]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceDivide
[25]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceFloorDivide
[26]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceLshift
[27]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceMultiply
[28]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceOr
[29]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlacePower
[30]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceRemainder
[31]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceRshift
[32]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceSubtract
[33]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceTrueDivide
[34]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceXor
[35]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Invert
[36]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Lshift
[37]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Multiply
[38]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Negative
[39]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Or
[40]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Positive
[41]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Power
[42]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Remainder
[43]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Rshift
[44]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Subtract
[45]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_TrueDivide
[46]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Xor
[47]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_Call
[48]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_DelItem
[49]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_GC_Del
[50]    0x00000000    undef      IMP     DS EXTref libpython2.7.so _PyObject_GC_New
[51]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_GC_Track
[52]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_GC_UnTrack
[53]    0x00000000    undef      IMP     PR EXTref libpython2.7.so PyObject_GenericGetAttr
[54]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_GetAttr
[55]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_GetItem
[56]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_IsTrue
[57]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_Not
[58]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_RichCompare
[59]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_SetItem
[60]    0x00000000    undef      IMP     PR EXTref libpython2.7.so Py_Py3kWarningFlag
[61]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_Check
[62]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_Concat
[63]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_Contains
[64]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_Count
[65]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_DelSlice
[66]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_GetSlice
[67]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_Index
[68]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_InPlaceConcat
[69]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_InPlaceRepeat
[70]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_Repeat
[71]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_SetSlice
[72]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyString_FromString
[73]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyString_FromStringAndSize
[74]    0x00000000    undef      IMP     PR EXTref libpython2.7.so _Py_TrueStruct
[75]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyTuple_GetSlice
[76]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyTuple_New
[77]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyType_Ready
[78]    0x00000000    undef      IMP     DS EXTref libpython2.7.so _PyUnicodeUCS2_AsDefaultEncodedString
[79]    0x00000000    undef      IMP     PR EXTref libpython2.7.so _Py_ZeroStruct
[80]    0x0000e008    undef      IMP     XO EXTref   libc.a(shr.o) ___memset
[81]    0x0000f000    undef      IMP     XO EXTref   libc.a(shr.o) ___memmove
[82]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) malloc
[83]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) realloc
[84]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) free
[85]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) calloc
[86]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) strlen
[87]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) strchr
[88]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) abort
[89]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_getspecific
[90]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_setspecific
[91]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_key_create
[92]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_once
[93]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_mutex_unlock
[94]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_mutex_lock
[95]    0x200023a8    .data EXPentPT     DS   Ldef        [noIMid] initoperator

But now im usnure how to implement this into the configure script and to provide a valid general patch for this.

----------
components: Build, Library (Lib)
messages: 154551
nosy: Jan.St?rtz
priority: normal
severity: normal
status: open
title: AIX, crash loading shared module into another process than python like operator.so results in 0509-130
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14150>
_______________________________________

From report at bugs.python.org  Tue Feb 28 14:18:42 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Feb 2012 13:18:42 +0000
Subject: [issue14150] AIX,
	crash loading shared module into another process than python like
	operator.so results in 0509-130
In-Reply-To: <1330434369.23.0.116359457055.issue14150@psf.upfronthosting.co.za>
Message-ID: <1330435122.56.0.525184876213.issue14150@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14150>
_______________________________________

From report at bugs.python.org  Tue Feb 28 14:51:38 2012
From: report at bugs.python.org (Popa Claudiu)
Date: Tue, 28 Feb 2012 13:51:38 +0000
Subject: [issue14151] multiprocessing.connection.Listener fails with invalid
	address
Message-ID: <1330437098.57.0.315162934772.issue14151@psf.upfronthosting.co.za>


New submission from Popa Claudiu <pcmanticore at gmail.com>:

In multiprocessing.connection, when using a Windows named pipe on a Unix platform, the following error will occur. This should not happen, the format of the address should be validated somehow before. The following error will occur because PipeListener is not defined under any platform different than win32. 

Python 3.2.2 (default, Oct 14 2011, 21:46:49)
[GCC 4.2.2 20070831 prerelease [FreeBSD]] on freebsd8
Type "help", "copyright", "credits" or "license" for more information.
>>> from multiprocessing.connection import Listener
>>> Listener(r'\\.\test')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.2/multiprocessing/connection.py", line 130, in __init__
    self._listener = PipeListener(address, backlog)
NameError: global name 'PipeListener' is not defined
>>>


I've attached a small patch for this issue.

----------
components: Library (Lib)
files: connection.patch
keywords: patch
messages: 154552
nosy: Popa.Claudiu
priority: normal
severity: normal
status: open
title: multiprocessing.connection.Listener fails with invalid address
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file24671/connection.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14151>
_______________________________________

From report at bugs.python.org  Tue Feb 28 15:49:14 2012
From: report at bugs.python.org (Matt Joiner)
Date: Tue, 28 Feb 2012 14:49:14 +0000
Subject: [issue10115] Support accept4() for atomic setting of flags at socket
	creation
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1330440554.7.0.803324062621.issue10115@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

Can we get this exposed as an os.accept4, and an optional flags parameter to socket.socket.accept?

----------
nosy: +anacrolix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Tue Feb 28 16:20:13 2012
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 28 Feb 2012 15:20:13 +0000
Subject: [issue14136] Simplify PEP 409 command line test and move it to
	test_cmd_line_script
In-Reply-To: <1330309400.02.0.0793594491787.issue14136@psf.upfronthosting.co.za>
Message-ID: <1330442413.6.0.0185779127356.issue14136@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Moved to test_cmd_line_script.

----------
Added file: http://bugs.python.org/file24672/raise_from_none_test_cleanup.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14136>
_______________________________________

From report at bugs.python.org  Tue Feb 28 16:30:01 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 28 Feb 2012 15:30:01 +0000
Subject: [issue14080] Sporadic test_imp failure
In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>
Message-ID: <1330443001.79.0.77087260022.issue14080@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Then how do you explain the failure being nothing more than prepending . compared to an absolute file path?

Anyway, the test passes under importlib with ``./python.exe -m importlib.test.regrtest test_imp``, so it requires some special setup to trigger the failure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14080>
_______________________________________

From report at bugs.python.org  Tue Feb 28 18:00:07 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 28 Feb 2012 17:00:07 +0000
Subject: [issue14152] arraymodule: structmember.h dependency
Message-ID: <1330448407.18.0.666571284408.issue14152@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

The arraymodule depends on "structmember.h". Patch attached.

----------
components: Build
files: arraymodule_deps.diff
keywords: patch
messages: 154556
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: arraymodule: structmember.h dependency
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file24673/arraymodule_deps.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14152>
_______________________________________

From report at bugs.python.org  Tue Feb 28 18:03:50 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 28 Feb 2012 17:03:50 +0000
Subject: [issue14153] Expose os.device_encoding() at the C level
Message-ID: <1330448630.79.0.296713458855.issue14153@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The _io module imports the os module purely for the use of os.device_encoding(). That function, though, is defined by posix and thus is already available to C code. To avoid this import dependency it would be better to simply expose the function somehow so that _io can just directly call the function.

Antoine has suggested Python/fileutils.c as a possible place, although I'm personally happy simply exposing the function from posix and making it a METH_O function so that as little code needs to change for _io to use it.

----------
components: Library (Lib)
messages: 154557
nosy: brett.cannon, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Expose os.device_encoding() at the C level
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14153>
_______________________________________

From report at bugs.python.org  Tue Feb 28 18:13:17 2012
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 28 Feb 2012 17:13:17 +0000
Subject: [issue14136] Simplify PEP 409 command line test and move it to
	test_cmd_line_script
In-Reply-To: <1330428621.93.0.707130481762.issue14136@psf.upfronthosting.co.za>
Message-ID: <4F4D0CE2.4010907@stoneleaf.us>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Nick,

Thank you for your thorough answers.  I'm not trying to be difficult, 
just trying to learn and understand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14136>
_______________________________________

From report at bugs.python.org  Tue Feb 28 19:14:59 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 28 Feb 2012 18:14:59 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1330452899.11.0.0463164896691.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

MacOS 10.6 was released in August 2009. The code should compile there flawless with a couple of trivial changes, as proved by Marc.

Supporting compilation in MacOS 10.5 is doable but more difficult. Since this is an optional feature, not impacting python programs, I am tempted of not investing any time on it.

Note, however, that the compiled 10.6 version will provide full dtrace support in previous MacOS releases. The difficulty is in compilation, not at runtime.

Opinions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Feb 28 19:30:41 2012
From: report at bugs.python.org (Wilfredo Sanchez)
Date: Tue, 28 Feb 2012 18:30:41 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1330453841.64.0.374290037756.issue13405@psf.upfronthosting.co.za>


Wilfredo Sanchez <wsanchez at wsanchez.net> added the comment:

Given that the current Mac OS is 10.7, and 10.8 was just announced, it seems reasonable to limit support to 10.6, if going back any further is more than a little bit of additional work.

IIRC, 10.6 is also the last release to support PowerPC, so going back that far does cover a lot of existing hardware.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Feb 28 19:42:07 2012
From: report at bugs.python.org (Philip Jenvey)
Date: Tue, 28 Feb 2012 18:42:07 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1330454527.67.0.403584230919.issue13405@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

Actually 10.5 was the last PowerPC release

----------
nosy: +pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Feb 28 20:03:08 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 28 Feb 2012 19:03:08 +0000
Subject: [issue12151] test_logging fails sometimes
In-Reply-To: <1306106163.56.0.790245092521.issue12151@psf.upfronthosting.co.za>
Message-ID: <E1S2SKI-0005lq-Ny@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ce0b9b1328d4 by Vinay Sajip in branch 'default':
Added additional diagnostics to help with #12151.
http://hg.python.org/cpython/rev/ce0b9b1328d4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12151>
_______________________________________

From report at bugs.python.org  Tue Feb 28 20:05:33 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Tue, 28 Feb 2012 19:05:33 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1330455933.21.0.917078654007.issue13405@psf.upfronthosting.co.za>


Marc Abramowitz <msabramo at gmail.com> added the comment:

Limiting to 10.6 and above seems entirely reasonable to me. I am one of the few folks that I know who is still on 10.6. Most of my friends are on 10.7.

Since OS X is primarily a desktop OS, I think people tend to upgrade more quickly compared to more of a server OS like Solaris. For instance, I stayed on 10.5 for a while but was eventually forced to upgrade to 10.6, because I wanted to do iOS development and the Xcode and developer SDK needed to do that required 10.6. That right there kind of tells you that even Apple is not really supporting 10.5 for development.

Also, if you target 10.6, I can test it for you. If you target 10.5, I don't have a 10.5 machine to test with.

So if it's at all hard to support 10.5, I'd say skip it and someone else can do it if they really need it. But I doubt that will happen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Feb 28 20:19:36 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Tue, 28 Feb 2012 19:19:36 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1330456776.85.0.916492148189.issue13405@psf.upfronthosting.co.za>


Marc Abramowitz <msabramo at gmail.com> added the comment:

I wanted to post an update on FreeBSD 9.0, which Jes?s and I worked on a bit yesterday.

Maybe Jordan will chime in here with an answer to my FreeBSD problems. :-)

With a little bit of Makefile hackery (make it skip building the phelper stuff which was failing with a "useless declaration" error and which is for jstack which might not be supported on FreeBSD), I got Python to build with Jes?s's patches.

But I couldn't actually dtrace anything with it.

And then I stepped back and tried to dtrace other programs to see if userland DTrace was working and I ran into all kinds of problems, including killing the traced program and a (reproduceable) kernel panic. Here's a question that I posted about it on the FreeBSD-questions mailing list:

http://lists.freebsd.org/pipermail/freebsd-questions/2012-February/238862.html

If I can get the FreeBSD DTrace support working without too much effort, then I'll do it, but if it's problematic, then I might skip it and focus on helping Jes?s test his stuff on OS X and OpenIndiana.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Feb 28 20:28:04 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 28 Feb 2012 19:28:04 +0000
Subject: [issue14152] setup.py: Python header file dependencies
In-Reply-To: <1330448407.18.0.666571284408.issue14152@psf.upfronthosting.co.za>
Message-ID: <1330457284.38.0.957220584958.issue14152@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

There is a comment in setup.py that suggests that *all* Python headers
should be added to the dependencies (?):


  # Python header files
  headers = [sysconfig.get_config_h_filename()]
  headers += glob(os.path.join(sysconfig.get_path('platinclude'), "*.h"))


Was that the intention? Because this is what I get when I add a
print statement:

['/home/stefan/pydev/cpython/pyconfig.h', '/home/stefan/pydev/cpython/pyconfig.h']

----------
stage: patch review -> 
title: arraymodule: structmember.h dependency -> setup.py: Python header file dependencies

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14152>
_______________________________________

From report at bugs.python.org  Tue Feb 28 20:28:21 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 28 Feb 2012 19:28:21 +0000
Subject: [issue14146] IDLE: source line in editor doesn't highlight when
	debugging
In-Reply-To: <1330401708.67.0.511106941359.issue14146@psf.upfronthosting.co.za>
Message-ID: <1330457301.98.0.501793871905.issue14146@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Is the "Source" check box in the Debug Control window checked?

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14146>
_______________________________________

From report at bugs.python.org  Tue Feb 28 20:33:44 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Tue, 28 Feb 2012 19:33:44 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1330457624.45.0.563825244583.issue13405@psf.upfronthosting.co.za>


Marc Abramowitz <msabramo at gmail.com> added the comment:

[marca at freebsd9-0 ~]$ /home/marca/custom/bin/python
Python 2.7.2+ (dtrace-issue13405_2.7:e612f29478e3+, Feb 27 2012, 20:37:22) 
[GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd9
Type "help", "copyright", "credits" or "license" for more information.
>>> 
[marca at freebsd9-0 ~]$ sudo dtrace -n 'pid$target:python::entry' -c /home/marca/custom/bin/python
Python 2.7.2+ (dtrace-issue13405_2.7:e612f29478e3+, Feb 27 2012, 20:37:22) 
[GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd9
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.getpid()
2541
>>> 
dtrace: failed to control pid 2541: process exited with status 0


[marca at freebsd9-0 ~]$ ps auxww | grep python
marca       2546   0.0  2.3  27452   5668   1  S+    3:29AM   0:00.02 /home/marca/custom/bin/python
[marca at freebsd9-0 ~]$ sudo dtrace -n 'pid2546:python::entry'
[marca at freebsd9-0 ~]$ ps auxww | grep python
marca       2552   0.0  0.5  16460   1244   0  S+    3:29AM   0:00.00 grep python

In the above case, the python proces (pid 2546) died with:

>>> Killed: 9

Why would DTrace kill -9 the program it's tracing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Feb 28 20:45:36 2012
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 28 Feb 2012 19:45:36 +0000
Subject: [issue14145] string.rfind() returns AttributeError: 'list' object has
	no attribute 'rfind'
In-Reply-To: <1330398783.39.0.669167719061.issue14145@psf.upfronthosting.co.za>
Message-ID: <1330458336.83.0.917316768332.issue14145@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm going to close this. Feel free to re-open it if you can give a small example showing the problem.

----------
resolution:  -> invalid
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14145>
_______________________________________

From report at bugs.python.org  Tue Feb 28 20:48:34 2012
From: report at bugs.python.org (Griffin Smith)
Date: Tue, 28 Feb 2012 19:48:34 +0000
Subject: [issue14145] string.rfind() returns AttributeError: 'list' object has
	no attribute 'rfind'
In-Reply-To: <1330398783.39.0.669167719061.issue14145@psf.upfronthosting.co.za>
Message-ID: <1330458514.35.0.567294731085.issue14145@psf.upfronthosting.co.za>


Griffin Smith <wildgriffin45 at gmail.com> added the comment:

Actually, I did some diagnosis and it would appear it was actually an inappropriate call - I was assuming os.path.walk returned a tuple containing a list of files instead of a tuple containing a list of lists of files.

Sorry about that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14145>
_______________________________________

From report at bugs.python.org  Tue Feb 28 20:53:21 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Feb 2012 19:53:21 +0000
Subject: [issue14153] Expose os.device_encoding() at the C level
In-Reply-To: <1330448630.79.0.296713458855.issue14153@psf.upfronthosting.co.za>
Message-ID: <1330458801.69.0.333635928603.issue14153@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/issue14153>
_______________________________________

From report at bugs.python.org  Tue Feb 28 21:02:51 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 28 Feb 2012 20:02:51 +0000
Subject: [issue14145] string.rfind() returns AttributeError: 'list' object has
	no attribute 'rfind'
In-Reply-To: <1330398783.39.0.669167719061.issue14145@psf.upfronthosting.co.za>
Message-ID: <1330459371.15.0.267821837326.issue14145@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14145>
_______________________________________

From report at bugs.python.org  Tue Feb 28 21:13:10 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 28 Feb 2012 20:13:10 +0000
Subject: [issue14154] reimplement the bigmem test memory watchdog as a
	subprocess
Message-ID: <1330459989.98.0.769260493369.issue14154@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali <neologix at free.fr>:

As suggested in http://bugs.python.org/msg154330, here's a rewrite of the test memory watchdog using subprocess instead of thread + faulthandler.

----------
components: Tests
files: mem_watchdog_subprocess.diff
keywords: needs review, patch
messages: 154570
nosy: neologix, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: reimplement the bigmem test memory watchdog as a subprocess
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file24674/mem_watchdog_subprocess.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14154>
_______________________________________

From report at bugs.python.org  Tue Feb 28 21:22:45 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 28 Feb 2012 20:22:45 +0000
Subject: [issue14154] reimplement the bigmem test memory watchdog as a
	subprocess
In-Reply-To: <1330459989.98.0.769260493369.issue14154@psf.upfronthosting.co.za>
Message-ID: <1330460565.99.0.584722739119.issue14154@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14154>
_______________________________________

From report at bugs.python.org  Tue Feb 28 21:31:07 2012
From: report at bugs.python.org (Rich Rauenzahn)
Date: Tue, 28 Feb 2012 20:31:07 +0000
Subject: [issue14146] IDLE: source line in editor doesn't highlight when
	debugging
In-Reply-To: <1330401708.67.0.511106941359.issue14146@psf.upfronthosting.co.za>
Message-ID: <1330461067.67.0.377497933668.issue14146@psf.upfronthosting.co.za>


Rich Rauenzahn <rrauenza at gmail.com> added the comment:

Yes, the source box was checkmarked.

Not the first one to encounter this as well:

http://python.6.n6.nabble.com/IDLE-not-highlighting-current-line-while-debugging-on-Win-td2113345.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14146>
_______________________________________

From report at bugs.python.org  Tue Feb 28 22:03:08 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Feb 2012 21:03:08 +0000
Subject: [issue14154] reimplement the bigmem test memory watchdog as a
	subprocess
In-Reply-To: <1330459989.98.0.769260493369.issue14154@psf.upfronthosting.co.za>
Message-ID: <1330462988.36.0.501741419937.issue14154@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's so much simpler that I feel a bit ridiculous with my earlier solution :)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14154>
_______________________________________

From report at bugs.python.org  Tue Feb 28 22:42:13 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Feb 2012 21:42:13 +0000
Subject: [issue14148] Option to kill "stuck" workers in a multiprocessing pool
In-Reply-To: <1330429380.32.0.0524478586738.issue14148@psf.upfronthosting.co.za>
Message-ID: <1330465333.6.0.44696664452.issue14148@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The problem is that queues and other synchronization objects can end up in an inconsistent state when a worker crashes, hangs or gets killed.
That's why, in concurrent.futures, a crashed worker makes the ProcessPoolExecutor become "broken". A similar thing should be done for multiprocessing.Pool but it's a more complex object.

----------
nosy: +neologix, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14148>
_______________________________________

From report at bugs.python.org  Tue Feb 28 23:23:09 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Feb 2012 22:23:09 +0000
Subject: [issue14153] Expose os.device_encoding() at the C level
In-Reply-To: <1330448630.79.0.296713458855.issue14153@psf.upfronthosting.co.za>
Message-ID: <1330467789.37.0.225577573514.issue14153@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

If it can help to bootstrap importlib, you can add:

PyObject* _Py_device_encoding(int fd);

And reuse it in posixmodule.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14153>
_______________________________________

From report at bugs.python.org  Tue Feb 28 23:24:47 2012
From: report at bugs.python.org (Paul Moore)
Date: Tue, 28 Feb 2012 22:24:47 +0000
Subject: [issue14148] Option to kill "stuck" workers in a multiprocessing pool
In-Reply-To: <1330465333.6.0.44696664452.issue14148@psf.upfronthosting.co.za>
Message-ID: <CACac1F-_RYK9trT6o2oPc3PSfr2NFvNpJ_xi2QmcYMwgQggBOw@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

As an alternative, maybe leave the "stuck" worker, but allow the pool
to recognise when a worker has not processed new messages for a long
period and spawn an extra worker to replace it. That would avoid the
starvation issue, and the stuck workers would die when the pool is
terminated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14148>
_______________________________________

From report at bugs.python.org  Tue Feb 28 23:26:10 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 28 Feb 2012 22:26:10 +0000
Subject: [issue14113] Failure in test_strptime on Windows
In-Reply-To: <1330114398.55.0.713486121761.issue14113@psf.upfronthosting.co.za>
Message-ID: <E1S2VUn-0001Qe-CJ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3ea8d0afe541 by Nadeem Vawda in branch '2.7':
Give better failure messages in test_strptime (cf. issue #14113).
http://hg.python.org/cpython/rev/3ea8d0afe541

New changeset 8d2ffe1f25d3 by Nadeem Vawda in branch '3.2':
Give better failure messages in test_strptime (cf. issue #14113).
http://hg.python.org/cpython/rev/8d2ffe1f25d3

New changeset 46ab2d46337c by Nadeem Vawda in branch 'default':
Merge: Give better failure messages in test_strptime (cf. issue #14113).
http://hg.python.org/cpython/rev/46ab2d46337c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14113>
_______________________________________

From report at bugs.python.org  Tue Feb 28 23:34:27 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 28 Feb 2012 22:34:27 +0000
Subject: [issue14113] Failure in test_strptime on Windows
In-Reply-To: <1330114398.55.0.713486121761.issue14113@psf.upfronthosting.co.za>
Message-ID: <1330468467.14.0.725490236534.issue14113@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14113>
_______________________________________

From report at bugs.python.org  Tue Feb 28 23:48:48 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Feb 2012 22:48:48 +0000
Subject: [issue14154] reimplement the bigmem test memory watchdog as a
	subprocess
In-Reply-To: <1330459989.98.0.769260493369.issue14154@psf.upfronthosting.co.za>
Message-ID: <1330469328.03.0.112488412954.issue14154@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

A subprocess looks simpler (and safer?) than a C thread with a pipe.

+ f = open(self.procfile, 'r')

'rb' mode is enough here, no need of Unicode ;-)

+ self.mem_watchdog = subprocess.Popen(..., stdin=f)

Can't you open the /proc/pid/stat file in the child process? It might be an issue with SELinux or Grsecurity, but I don't expect that our buildbot use such security patch.

+ statm = sys.stdin.read()

file_watchdog() did read only 1024 bytes. I don't know if it would be better or not to use an arbitrary limit (to avoid filling the memory?).

You should catch OSError here.

You may only display the memory usage if it changed and start by a sleep.

--

You may also write the watchdog script in .py file instead of passing it on the command line, so it will be easier to maintain it later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14154>
_______________________________________

From report at bugs.python.org  Wed Feb 29 00:00:32 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 28 Feb 2012 23:00:32 +0000
Subject: [issue14136] Simplify PEP 409 command line test and move it to
	test_cmd_line_script
In-Reply-To: <1330309400.02.0.0793594491787.issue14136@psf.upfronthosting.co.za>
Message-ID: <1330470032.4.0.693972542446.issue14136@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Hah, I've been dealing with Python's regression test suite for 8+ years and there are still cases where I don't understand the rationale for testing things a particular way (beyond "it must have seemed like a good idea at the time"). It has a lot more historical cruft than the standard library does :)

The "proper" location for a particular test can be a bit of a coin toss in many cases, but one useful guide (which applies in this case) is to try to avoid adding *new* standard library dependencies to a test module if there's an alternate suitable location that already has those dependencies.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14136>
_______________________________________

From report at bugs.python.org  Wed Feb 29 00:29:49 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 28 Feb 2012 23:29:49 +0000
Subject: [issue14152] setup.py: Python header file dependencies
In-Reply-To: <1330448407.18.0.666571284408.issue14152@psf.upfronthosting.co.za>
Message-ID: <1330471789.82.0.712728849873.issue14152@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

In Python2.6 all headers from Include/ were added:

   # Python header files
   headers = glob("Include/*.h") + ["pyconfig.h"]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14152>
_______________________________________

From report at bugs.python.org  Wed Feb 29 00:34:51 2012
From: report at bugs.python.org (Andrej A Antonov)
Date: Tue, 28 Feb 2012 23:34:51 +0000
Subject: [issue14134] "xmlrpc.client.ServerProxy()" -- need for
	"timeout"-parameter
In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za>
Message-ID: <1330472091.86.0.648684159476.issue14134@psf.upfronthosting.co.za>


Andrej A Antonov <polymorphm at gmail.com> added the comment:

in this subject -- I think about like this changes (see file "example-of-changes.patch")

----------
keywords: +patch
Added file: http://bugs.python.org/file24675/example-of-changes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14134>
_______________________________________

From report at bugs.python.org  Wed Feb 29 00:52:48 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 28 Feb 2012 23:52:48 +0000
Subject: [issue13086] Update howto/cporting.rst so it talks about Python 3
	instead of 3.0
In-Reply-To: <1317466662.3.0.331555988129.issue13086@psf.upfronthosting.co.za>
Message-ID: <E1S2Wqc-0001DY-QC@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset eb88cc90cc56 by Larry Hastings in branch '2.7':
Issue #13086: Update howto/cporting.rst to discuss "Python 3" instead of "3.0".
http://hg.python.org/cpython/rev/eb88cc90cc56

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13086>
_______________________________________

From report at bugs.python.org  Wed Feb 29 00:55:12 2012
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 28 Feb 2012 23:55:12 +0000
Subject: [issue13086] Update howto/cporting.rst so it talks about Python 3
	instead of 3.0
In-Reply-To: <1317466662.3.0.331555988129.issue13086@psf.upfronthosting.co.za>
Message-ID: <1330473312.72.0.241797567598.issue13086@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

@eric.araujo: I talked to Brett about it.  We don't pretend that Python 3.0 never existed; we tell people it's unsupported and unsuitable for production use.  At his suggestion I added a statement to that effect, and left the rest the same.

I'll now manually incorporate this into the 3.2 branch, then forward-port to trunk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13086>
_______________________________________

From report at bugs.python.org  Wed Feb 29 01:24:10 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Feb 2012 00:24:10 +0000
Subject: [issue13053] Add Capsule migration documentation to "cporting"
In-Reply-To: <1317224248.53.0.263122473581.issue13053@psf.upfronthosting.co.za>
Message-ID: <E1S2XKy-0004Ox-Rq@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 28849d00a41e by Larry Hastings in branch '3.2':
Propagate changes for issues #13053 and #13086 from 2.7 to 3.2.  (Doc only.)
http://hg.python.org/cpython/rev/28849d00a41e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13053>
_______________________________________

From report at bugs.python.org  Wed Feb 29 01:24:10 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Feb 2012 00:24:10 +0000
Subject: [issue13086] Update howto/cporting.rst so it talks about Python 3
	instead of 3.0
In-Reply-To: <1317466662.3.0.331555988129.issue13086@psf.upfronthosting.co.za>
Message-ID: <E1S2XKy-0004Ox-Ry@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 28849d00a41e by Larry Hastings in branch '3.2':
Propagate changes for issues #13053 and #13086 from 2.7 to 3.2.  (Doc only.)
http://hg.python.org/cpython/rev/28849d00a41e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13086>
_______________________________________

From report at bugs.python.org  Wed Feb 29 01:30:56 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Feb 2012 00:30:56 +0000
Subject: [issue13086] Update howto/cporting.rst so it talks about Python 3
	instead of 3.0
In-Reply-To: <1317466662.3.0.331555988129.issue13086@psf.upfronthosting.co.za>
Message-ID: <E1S2XRX-0005Fn-37@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c316e8a4a5e2 by Larry Hastings in branch 'default':
Merge: Propagate changes for issues #13053 and #13086 from 2.7 to 3.2.
http://hg.python.org/cpython/rev/c316e8a4a5e2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13086>
_______________________________________

From report at bugs.python.org  Wed Feb 29 01:30:56 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Feb 2012 00:30:56 +0000
Subject: [issue13053] Add Capsule migration documentation to "cporting"
In-Reply-To: <1317224248.53.0.263122473581.issue13053@psf.upfronthosting.co.za>
Message-ID: <E1S2XRX-0005Fn-2y@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c316e8a4a5e2 by Larry Hastings in branch 'default':
Merge: Propagate changes for issues #13053 and #13086 from 2.7 to 3.2.
http://hg.python.org/cpython/rev/c316e8a4a5e2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13053>
_______________________________________

From report at bugs.python.org  Wed Feb 29 01:31:59 2012
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 29 Feb 2012 00:31:59 +0000
Subject: [issue13053] Add Capsule migration documentation to "cporting"
In-Reply-To: <1317224248.53.0.263122473581.issue13053@psf.upfronthosting.co.za>
Message-ID: <1330475519.31.0.258542812814.issue13053@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Now checked in to 2.7, 3.2, and default.  Thanks everyone!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13053>
_______________________________________

From report at bugs.python.org  Wed Feb 29 01:32:17 2012
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 29 Feb 2012 00:32:17 +0000
Subject: [issue13086] Update howto/cporting.rst so it talks about Python 3
	instead of 3.0
In-Reply-To: <1317466662.3.0.331555988129.issue13086@psf.upfronthosting.co.za>
Message-ID: <1330475537.4.0.418249295376.issue13086@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Now checked in to 2.7, 3.2, and default.  Thanks everyone!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13086>
_______________________________________

From report at bugs.python.org  Wed Feb 29 02:31:09 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Wed, 29 Feb 2012 01:31:09 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1330479069.65.0.324797717636.issue13405@psf.upfronthosting.co.za>


Marc Abramowitz <msabramo at gmail.com> added the comment:

For anyone who is curious about the FreeBSD 9.0 DTrace userland problems I experienced, see http://www.freebsd.org/cgi/query-pr.cgi?pr=165541

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Wed Feb 29 02:49:19 2012
From: report at bugs.python.org (Space Li)
Date: Wed, 29 Feb 2012 01:49:19 +0000
Subject: [issue9631] Python 2.7 installation issue for Linux gcc-4.1.0-3
	(Fedora Core 5?)
In-Reply-To: <1282108953.92.0.943632360126.issue9631@psf.upfronthosting.co.za>
Message-ID: <1330480159.89.0.133099991131.issue9631@psf.upfronthosting.co.za>


Space Li <spacelis at gmail.com> added the comment:

Hi,

I recently compiled Python 2.7.2 and got an ImportError on struct module during 'make install'. 

What I found working for me is just to 'make'. Before doing 'make install', copy the lib.linux-xxxxx directory in 'build' to {prefix}/lib/python2.7 and rename it as lib-dynload.

Then find something that looks like followings:
        $(INSTALL_DATA) $(srcdir)/LICENSE $(DESTDIR)$(LIBDEST)/LICENSE.txt
        PYTHONPATH=$(DESTDIR)$(LIBDEST)  $(RUNSHARED) \
                ./$(BUILDPYTHON) -Wi -tt $(DESTDIR)$(LIBDEST)/compileall.py \
                -d $(LIBDEST) -f \
                -x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \
                $(DESTDIR)$(LIBDEST)
        PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \
                ./$(BUILDPYTHON) -Wi -tt -O $(DESTDIR)$(LIBDEST)/compileall.py \
                -d $(LIBDEST) -f \
                -x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \
                $(DESTDIR)$(LIBDEST)
        -PYTHONPATH=$(DESTDIR)$(LIBDEST)  $(RUNSHARED) \
                ./$(BUILDPYTHON) -Wi -t $(DESTDIR)$(LIBDEST)/compileall.py \
                -d $(LIBDEST)/site-packages -f \
                -x badsyntax $(DESTDIR)$(LIBDEST)/site-packages
        -PYTHONPATH=$(DESTDIR)$(LIBDEST):$(DESTSHARED) $(RUNSHARED) \
                ./$(BUILDPYTHON) -Wi -t -O $(DESTDIR)$(LIBDEST)/compileall.py \
                -d $(LIBDEST)/site-packages -f \
                -x badsyntax $(DESTDIR)$(LIBDEST)/site-packages
        -PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \
                ./$(BUILDPYTHON) -Wi -t -c "import lib2to3.pygram, lib2to3.patcomp;lib2to3.patcomp.PatternCompiler()"

Add :$(DESTSHARED) behind each PYTHONPATH. Then it looks like

        $(INSTALL_DATA) $(srcdir)/LICENSE $(DESTDIR)$(LIBDEST)/LICENSE.txt
        PYTHONPATH=$(DESTDIR)$(LIBDEST):$(DESTSHARED)  $(RUNSHARED) \
                ./$(BUILDPYTHON) -Wi -tt $(DESTDIR)$(LIBDEST)/compileall.py \
                -d $(LIBDEST) -f \
                -x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \
                $(DESTDIR)$(LIBDEST)
        PYTHONPATH=$(DESTDIR)$(LIBDEST):$(DESTSHARED) $(RUNSHARED) \
                ./$(BUILDPYTHON) -Wi -tt -O $(DESTDIR)$(LIBDEST)/compileall.py \
                -d $(LIBDEST) -f \
                -x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \
                $(DESTDIR)$(LIBDEST)
        -PYTHONPATH=$(DESTDIR)$(LIBDEST):$(DESTSHARED)  $(RUNSHARED) \
                ./$(BUILDPYTHON) -Wi -t $(DESTDIR)$(LIBDEST)/compileall.py \
                -d $(LIBDEST)/site-packages -f \
                -x badsyntax $(DESTDIR)$(LIBDEST)/site-packages
        -PYTHONPATH=$(DESTDIR)$(LIBDEST):$(DESTSHARED) $(RUNSHARED) \
                ./$(BUILDPYTHON) -Wi -t -O $(DESTDIR)$(LIBDEST)/compileall.py \
                -d $(LIBDEST)/site-packages -f \
                -x badsyntax $(DESTDIR)$(LIBDEST)/site-packages
        -PYTHONPATH=$(DESTDIR)$(LIBDEST):$(DESTSHARED) $(RUNSHARED) \
                ./$(BUILDPYTHON) -Wi -t -c "import lib2to3.pygram, lib2to3.patcomp;lib2to3.patcomp.PatternCompiler()"

After doing so, you can 'make install'.

This is tested on OpenSUSE 10.3 with GCC 4.2.1.

----------
nosy: +spaceli

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9631>
_______________________________________

From report at bugs.python.org  Wed Feb 29 03:10:39 2012
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 29 Feb 2012 02:10:39 +0000
Subject: [issue14146] IDLE: source line in editor doesn't highlight when
	debugging
In-Reply-To: <1330401708.67.0.511106941359.issue14146@psf.upfronthosting.co.za>
Message-ID: <1330481439.22.0.343075119289.issue14146@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I am not seeing this problem under Ubuntu, but I do see this problem on Vista. It looks like the "sel" tags get hidden when a window loses focus under Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14146>
_______________________________________

From report at bugs.python.org  Wed Feb 29 03:12:20 2012
From: report at bugs.python.org (py.user)
Date: Wed, 29 Feb 2012 02:12:20 +0000
Subject: [issue14155] Deja vu in re's documentation
Message-ID: <1330481540.05.0.869825762197.issue14155@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

This paragraph is redundant
http://docs.python.org/py3k/library/re.html#matching-vs-searching

a duplicate
http://docs.python.org/py3k/library/re.html#search-vs-match


the part about match() behavior in multiline mode could be described in note here:
http://docs.python.org/py3k/library/re.html#re.regex.match

----------
assignee: docs at python
components: Documentation
messages: 154592
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: Deja vu in re's documentation
type: enhancement
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14155>
_______________________________________

From report at bugs.python.org  Wed Feb 29 03:53:08 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Feb 2012 02:53:08 +0000
Subject: [issue14153] Expose os.device_encoding() at the C level
In-Reply-To: <1330448630.79.0.296713458855.issue14153@psf.upfronthosting.co.za>
Message-ID: <1330483988.25.0.020605674099.issue14153@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Either that or PyObject *_Py_device_encoding(PyObject *fd) would help since both _io and posixmodule.c will have a PyObject already for the fd.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14153>
_______________________________________

From report at bugs.python.org  Wed Feb 29 04:17:46 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 29 Feb 2012 03:17:46 +0000
Subject: [issue14153] Expose os.device_encoding() at the C level
In-Reply-To: <1330448630.79.0.296713458855.issue14153@psf.upfronthosting.co.za>
Message-ID: <1330485466.84.0.727189344439.issue14153@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think fileutils.c is a good place. Then we can kill the import of "os" in io, which would be nice.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14153>
_______________________________________

From report at bugs.python.org  Wed Feb 29 04:23:32 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Feb 2012 03:23:32 +0000
Subject: [issue14153] Expose os.device_encoding() at the C level
In-Reply-To: <1330448630.79.0.296713458855.issue14153@psf.upfronthosting.co.za>
Message-ID: <1330485812.71.0.100789627766.issue14153@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, then I will make this happen. People care whether it take an int or a PyObject? That seems to be the only open question.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14153>
_______________________________________

From report at bugs.python.org  Wed Feb 29 04:25:14 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 29 Feb 2012 03:25:14 +0000
Subject: [issue14153] Expose os.device_encoding() at the C level
In-Reply-To: <1330485812.71.0.100789627766.issue14153@psf.upfronthosting.co.za>
Message-ID: <CAPZV6o_kRp+V_O_xyS49jxHbEdKtSuVo1QU7CpBQFG8Rzy_NMA@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2012/2/28 Brett Cannon <report at bugs.python.org>:
>
> Brett Cannon <brett at python.org> added the comment:
>
> OK, then I will make this happen. People care whether it take an int or a PyObject? That seems to be the only open question.

Probably int if it goes in fileutils.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14153>
_______________________________________

From report at bugs.python.org  Wed Feb 29 04:35:13 2012
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 29 Feb 2012 03:35:13 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1330486513.13.0.230639159207.issue13405@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Wed Feb 29 05:10:05 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Feb 2012 04:10:05 +0000
Subject: [issue14135] check for locale changes in test.regrtest
In-Reply-To: <1330296468.42.0.0463135348779.issue14135@psf.upfronthosting.co.za>
Message-ID: <1330488605.01.0.680727902166.issue14135@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: check for locale changes in test.support -> check for locale changes in test.regrtest

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14135>
_______________________________________

From report at bugs.python.org  Wed Feb 29 05:13:39 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Feb 2012 04:13:39 +0000
Subject: [issue14149] argparse usage model requires argument names to be
	python identifiers
In-Reply-To: <1330431835.85.0.549489798388.issue14149@psf.upfronthosting.co.za>
Message-ID: <1330488819.93.0.274907288405.issue14149@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If argparse munged foo-bar to foo_bar to allow attribute access, then it?d need to disallow ambiguous cases like add_argument('foo_bar', ...); add_argument('foo-bar', ...).  I?m not sure if there is real, sensible code that does that, though.

> Namespace should act like an object and dict.
I don?t understand, can you rephrase?

----------
nosy: +bethard, eric.araujo
title: Argparse usage model requires argument names to be python identifiers -> argparse usage model requires argument names to be python identifiers
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14149>
_______________________________________

From report at bugs.python.org  Wed Feb 29 05:16:03 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Feb 2012 04:16:03 +0000
Subject: [issue14152] setup.py: Python header file dependencies
In-Reply-To: <1330448407.18.0.666571284408.issue14152@psf.upfronthosting.co.za>
Message-ID: <1330488963.21.0.217359685942.issue14152@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Does the 2.6 code work when you build in a subdirectory?  (I assume that?s why sysconfig is used instead of hard-coding, but I?ll check the VCS log when I have some time to be sure.)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14152>
_______________________________________

From report at bugs.python.org  Wed Feb 29 05:17:19 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Feb 2012 04:17:19 +0000
Subject: [issue14134] xmlrpc.client.ServerProxy needs timeout parameter
In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za>
Message-ID: <1330489039.35.0.993826544769.issue14134@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> test needed
title: "xmlrpc.client.ServerProxy()" --  need for "timeout"-parameter -> xmlrpc.client.ServerProxy needs timeout parameter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14134>
_______________________________________

From report at bugs.python.org  Wed Feb 29 05:17:56 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Feb 2012 04:17:56 +0000
Subject: [issue14155] Deja vu in re's documentation
In-Reply-To: <1330481540.05.0.869825762197.issue14155@psf.upfronthosting.co.za>
Message-ID: <1330489076.72.0.654600155471.issue14155@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +ezio.melotti, pitrou
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14155>
_______________________________________

From report at bugs.python.org  Wed Feb 29 05:19:14 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Feb 2012 04:19:14 +0000
Subject: [issue14152] setup.py: Python header file dependencies
In-Reply-To: <1330448407.18.0.666571284408.issue14152@psf.upfronthosting.co.za>
Message-ID: <1330489154.55.0.758438038012.issue14152@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I actually meant: when you build in any directory other that the top-level checkout directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14152>
_______________________________________

From report at bugs.python.org  Wed Feb 29 08:56:35 2012
From: report at bugs.python.org (=?utf-8?q?Michael=2EElsd=C3=B6rfer?=)
Date: Wed, 29 Feb 2012 07:56:35 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1330502195.53.0.6834423126.issue13968@psf.upfronthosting.co.za>


Michael.Elsd?rfer <michael at elsdoerfer.info> added the comment:

This should absolutely be implemented as **:

- It is pretty much standard. Recursive globbing is not supported everywhere, but when it is, ** is used.

- A separate function will not allow me to let the *user* to decide when recursion should be used. I find this most important. When I need to find files internally, I always do so using os.walk etc. When I use glob, it is because I want to provide an interface to my users. 

- The change to support ** is actually pretty trivial. I have implemented this as a module here: https://github.com/miracle2k/python-glob2/

- It's backwards-compatible - or close enough anyway. ** is currently perfectly nonsensical, making it a meaningful syntax element is acceptable, I think.

----------
nosy: +elsdoerfer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb 29 09:10:46 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 29 Feb 2012 08:10:46 +0000
Subject: [issue14154] reimplement the bigmem test memory watchdog as a
	subprocess
In-Reply-To: <1330469328.03.0.112488412954.issue14154@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3QjUpxpdUFjYNyVov75BmO4x6yugahOM9JtCoiYoVawQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> + f = open(self.procfile, 'r')
>
> 'rb' mode is enough here, no need of Unicode ;-)

Why?
At least to me, 'r' stands for text I/O, whereas 'rb' stands for
binary I/O: here, I want to read /proc/<PID>/statm, which is a textual
representation of the memory usage (entries are separated by space
characters).

> + self.mem_watchdog = subprocess.Popen(..., stdin=f)
>
> Can't you open the /proc/pid/stat file in the child process? It might be an issue with SELinux or Grsecurity, but I don't expect that our buildbot use such security patch.

Yes, SELinux and grsecurity are the first reason I open it in the
parent. The second reason is that, if the parent crashes after the
fork(), but before the child starts, I don't want it to read another
process' /proc/<PID>/statm (I know this would require an immediate
recycling of the PID which is thus really unlikely, but hey).

> + statm = sys.stdin.read()
>
> file_watchdog() did read only 1024 bytes. I don't know if it would be better or not to use an arbitrary limit (to avoid filling the memory?).

"""
$ cat /proc/self/statm
954 106 84 5 0 67 0
"""

I think that should fit in memory ;-)

> You should catch OSError here.

Why? If we get an OSError, we can't do much except exiting anyway.

> You may also write the watchdog script in .py file instead of passing it on the command line, so it will be easier to maintain it later.

Yes, that would be better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14154>
_______________________________________

From report at bugs.python.org  Wed Feb 29 09:11:06 2012
From: report at bugs.python.org (Steven Bethard)
Date: Wed, 29 Feb 2012 08:11:06 +0000
Subject: [issue14149] argparse usage model requires argument names to be
	python identifiers
In-Reply-To: <1330431835.85.0.549489798388.issue14149@psf.upfronthosting.co.za>
Message-ID: <1330503066.13.0.948835326332.issue14149@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

For optional flags like --foo-bar, argparse does munge the "dest" to "foo_bar", following optparse. For positional arguments, arpgarse doesn't munge things this way, but if you want the argument named "foo-bar" in help messages and "foo_bar" on the Namespace object, you just need to do something like:

add_argument('foo_bar', metavar='foo-bar', ...)

Perhaps the docs could make this clearer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14149>
_______________________________________

From report at bugs.python.org  Wed Feb 29 09:19:27 2012
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 29 Feb 2012 08:19:27 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1330503567.87.0.0825926962499.issue13405@psf.upfronthosting.co.za>


Changes by Philip Jenvey <pjenvey at underboss.org>:


----------
nosy:  -pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Wed Feb 29 09:30:08 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 29 Feb 2012 08:30:08 +0000
Subject: [issue13968] Support recursive globs
In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>
Message-ID: <1330504208.35.0.428541084467.issue13968@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

FWIW, I've also come around to the point of view that it's worthwhile to provide stdlib support for the "**" convention (specifically due to the UI aspect that Michael mentions).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________

From report at bugs.python.org  Wed Feb 29 10:02:26 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 29 Feb 2012 09:02:26 +0000
Subject: [issue13053] Add Capsule migration documentation to "cporting"
In-Reply-To: <1317224248.53.0.263122473581.issue13053@psf.upfronthosting.co.za>
Message-ID: <1330506146.41.0.405826980838.issue13053@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage: needs patch -> committed/rejected
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13053>
_______________________________________

From report at bugs.python.org  Wed Feb 29 10:03:10 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 29 Feb 2012 09:03:10 +0000
Subject: [issue13086] Update howto/cporting.rst so it talks about Python 3
	instead of 3.0
In-Reply-To: <1317466662.3.0.331555988129.issue13086@psf.upfronthosting.co.za>
Message-ID: <1330506190.64.0.77333338044.issue13086@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13086>
_______________________________________

From report at bugs.python.org  Wed Feb 29 10:06:52 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Feb 2012 09:06:52 +0000
Subject: [issue14061] Misc fixes and cleanups in archiving code in shutil and
	test_shutil
In-Reply-To: <1329705067.15.0.02936958618.issue14061@psf.upfronthosting.co.za>
Message-ID: <1330506412.27.0.362073752287.issue14061@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

test_shutil contains partial tests for the archiving functionality.  I plan to rewrite some tests so that for example you can see a skip message when bz2 is not available, instead of silent non-testing.  Also, the internal functions _make_tarfile and _make_zipfile are directly tested, but IMO it?d be better to only exercise make_archive.

----------
title: Clean up archiving code in shutil -> Misc fixes and cleanups in archiving code in shutil and test_shutil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14061>
_______________________________________

From report at bugs.python.org  Wed Feb 29 10:08:36 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Feb 2012 09:08:36 +0000
Subject: [issue14154] reimplement the bigmem test memory watchdog as a
	subprocess
In-Reply-To: <CAH_1eM3QjUpxpdUFjYNyVov75BmO4x6yugahOM9JtCoiYoVawQ@mail.gmail.com>
Message-ID: <CAMpsgwa1mRf3rk-2rtNWkvp28+LH8S+QZ8Q12R6r8EzJB0bTxw@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

>> + f = open(self.procfile, 'r')
>>
>> 'rb' mode is enough here, no need of Unicode ;-)
>
> Why?

The parent process doesn't read the file content, only the child. The
parent only needs a file descriptor.

>> + self.mem_watchdog = subprocess.Popen(..., stdin=f)
>>
>> Can't you open the /proc/pid/stat file in the child process? It might be an issue with SELinux or Grsecurity, but I don't expect that our buildbot use such security patch.
>
> (...) I don't want it to read another
> process' /proc/<PID>/statm (I know this would require an immediate
> recycling of the PID which is thus really unlikely, but hey).

Oh ok, this is a good reason. You may document such tricky justifications.

>> You should catch OSError here.
>
> Why? If we get an OSError, we can't do much except exiting anyway.

To not print a traceback if the parent dies.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14154>
_______________________________________

From report at bugs.python.org  Wed Feb 29 10:14:59 2012
From: report at bugs.python.org (Thomas Atkinson)
Date: Wed, 29 Feb 2012 09:14:59 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1330506899.14.0.916591092935.issue2698@psf.upfronthosting.co.za>


Thomas Atkinson <cptn.brittish at gmail.com> added the comment:

This bug is happening in python 3.2 when trying to build pycrypto on Microsoft Windows 7

----------
nosy: +Thomas.Atkinson
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Wed Feb 29 10:50:09 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Feb 2012 09:50:09 +0000
Subject: [issue10713] re module doesn't describe string boundaries for \b
In-Reply-To: <1292461535.35.0.85810781117.issue10713@psf.upfronthosting.co.za>
Message-ID: <E1S2gAh-0001uW-Fb@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fc89e09ca2fc by Ezio Melotti in branch '2.7':
#10713: Improve documentation for \b and \B and add a few tests.  Initial patch and tests by Martin Pool.
http://hg.python.org/cpython/rev/fc89e09ca2fc

New changeset cde7fa40b289 by Ezio Melotti in branch '3.2':
#10713: Improve documentation for \b and \B and add a few tests.  Initial patch and tests by Martin Pool.
http://hg.python.org/cpython/rev/cde7fa40b289

New changeset b78ca038e468 by Ezio Melotti in branch 'default':
#10713: merge with 3.2.
http://hg.python.org/cpython/rev/b78ca038e468

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10713>
_______________________________________

From report at bugs.python.org  Wed Feb 29 10:51:35 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 29 Feb 2012 09:51:35 +0000
Subject: [issue10713] re module doesn't describe string boundaries for \b
In-Reply-To: <1292461535.35.0.85810781117.issue10713@psf.upfronthosting.co.za>
Message-ID: <1330509095.47.0.368316035234.issue10713@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the patch!

----------
assignee: docs at python -> ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10713>
_______________________________________

From report at bugs.python.org  Wed Feb 29 11:08:30 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 29 Feb 2012 10:08:30 +0000
Subject: [issue14152] setup.py: Python header file dependencies
In-Reply-To: <1330448407.18.0.666571284408.issue14152@psf.upfronthosting.co.za>
Message-ID: <1330510110.8.0.828931591881.issue14152@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Dependency support added: 1be93dd179df

Last good version (all Include/*.h): 9705ef3fdb22

Current behavior (only pyconfig.h): fa69e891edf4


To answer your question: Neither of the last two revisions builds
in an out-of-source directory.

Raising the priority to high: The missing dependencies caused a
bug report on core-mentorship that was extremely time consuming
until I finally had the revelation that the submitter did not
run `make distclean` after `hg fetch` (which would not be necessary
with the dependencies in place).

----------
keywords:  -patch
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14152>
_______________________________________

From report at bugs.python.org  Wed Feb 29 11:46:02 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 29 Feb 2012 10:46:02 +0000
Subject: [issue14152] setup.py: Python header file dependencies
In-Reply-To: <1330448407.18.0.666571284408.issue14152@psf.upfronthosting.co.za>
Message-ID: <1330512362.65.0.431985321098.issue14152@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Here's a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file24676/issue14152.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14152>
_______________________________________

From report at bugs.python.org  Wed Feb 29 11:47:18 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 29 Feb 2012 10:47:18 +0000
Subject: [issue14155] Deja vu in re's documentation
In-Reply-To: <1330481540.05.0.869825762197.issue14155@psf.upfronthosting.co.za>
Message-ID: <1330512438.44.0.516283715632.issue14155@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Patch attached.

----------
assignee: docs at python -> ezio.melotti
components: +Regular Expressions
keywords: +patch
nosy: +mrabarnett
stage:  -> patch review
Added file: http://bugs.python.org/file24677/issue14155.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14155>
_______________________________________

From report at bugs.python.org  Wed Feb 29 11:48:31 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 29 Feb 2012 10:48:31 +0000
Subject: [issue14152] setup.py: Python header file dependencies
In-Reply-To: <1330448407.18.0.666571284408.issue14152@psf.upfronthosting.co.za>
Message-ID: <1330512511.29.0.0668314666021.issue14152@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Removed file: http://bugs.python.org/file24673/arraymodule_deps.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14152>
_______________________________________

From report at bugs.python.org  Wed Feb 29 11:48:55 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 29 Feb 2012 10:48:55 +0000
Subject: [issue14152] setup.py: Python header file dependencies
In-Reply-To: <1330448407.18.0.666571284408.issue14152@psf.upfronthosting.co.za>
Message-ID: <1330512535.2.0.737607767229.issue14152@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
stage:  -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14152>
_______________________________________

From report at bugs.python.org  Wed Feb 29 12:01:11 2012
From: report at bugs.python.org (Matt Joiner)
Date: Wed, 29 Feb 2012 11:01:11 +0000
Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
Message-ID: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

If an argument of '-' is handled by argparse.FileType, it defaults to sys.stdin. However a mode of 'rb' is ignored, the returned file object does not work with raw bytes.

----------
components: Library (Lib)
messages: 154612
nosy: anacrolix
priority: normal
severity: normal
status: open
title: argparse.FileType for '-' doesn't work for a mode of 'rb'
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14156>
_______________________________________

From report at bugs.python.org  Wed Feb 29 12:14:56 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Feb 2012 11:14:56 +0000
Subject: [issue14149] argparse: Document how to use argument names that are
	not Python identifiers
In-Reply-To: <1330431835.85.0.549489798388.issue14149@psf.upfronthosting.co.za>
Message-ID: <1330514096.06.0.507440006459.issue14149@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
keywords: +easy
nosy: +docs at python
stage:  -> needs patch
title: argparse usage model requires argument names to be python identifiers -> argparse: Document how to use argument names that are not Python identifiers
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14149>
_______________________________________

From report at bugs.python.org  Wed Feb 29 12:17:35 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Feb 2012 11:17:35 +0000
Subject: [issue14155] Deja vu in re's documentation
In-Reply-To: <1330481540.05.0.869825762197.issue14155@psf.upfronthosting.co.za>
Message-ID: <1330514255.31.0.97503241025.issue14155@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Didn?t review all lines in detail but looks globally good.  I would not remove Fred?s name though, but move it to another section or the top-level of the file.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14155>
_______________________________________

From report at bugs.python.org  Wed Feb 29 12:19:10 2012
From: report at bugs.python.org (Joseph Birr-Pixton)
Date: Wed, 29 Feb 2012 11:19:10 +0000
Subject: [issue14149] argparse: Document how to use argument names that are
	not Python identifiers
In-Reply-To: <1330431835.85.0.549489798388.issue14149@psf.upfronthosting.co.za>
Message-ID: <1330514350.4.0.426847968677.issue14149@psf.upfronthosting.co.za>


Joseph Birr-Pixton <jpixton at gmail.com> added the comment:

> I don?t understand, can you rephrase?

Sorry, I mean making Namespace subscriptable.  eg:

>>> v = argparse.Namespace(abc = 123)
>>> v
Namespace(abc=123)
>>> v.abc
123
>>> v['abc']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'Namespace' object is not subscriptable

> add_argument('foo_bar', metavar='foo-bar', ...)

This works. Thanks!

Cheers,
Joe

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14149>
_______________________________________

From report at bugs.python.org  Wed Feb 29 12:25:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Feb 2012 11:25:07 +0000
Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za>
Message-ID: <1330514707.83.0.999985601592.issue14156@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +bethard, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14156>
_______________________________________

From report at bugs.python.org  Wed Feb 29 12:31:10 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Feb 2012 11:31:10 +0000
Subject: [issue14152] setup.py: Python header file dependencies
In-Reply-To: <1330448407.18.0.666571284408.issue14152@psf.upfronthosting.co.za>
Message-ID: <1330515070.67.0.956599797501.issue14152@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> To answer your question: Neither of the last two revisions builds
> in an out-of-source directory.
My question was more whether the last known good revision did :)

> Here's a patch.
Tested with Python built in the top-level dir and in another dir, works in both cases.  Please apply, but not to security-only branches.

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14152>
_______________________________________

From report at bugs.python.org  Wed Feb 29 12:33:51 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 29 Feb 2012 11:33:51 +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: <1330515231.96.0.40659423792.issue10181@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I'm busy adding the C-API changes to the docs. Regarding the stable ABI:

The general mood was to *keep* the removal of the buffer interface
for some time, did I get that right?

In that case this removal (especially of the Py_buffer struct) should
be documented also for 3.2.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Wed Feb 29 12:40:33 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Feb 2012 11:40:33 +0000
Subject: [issue14155] Deja vu in re's documentation
In-Reply-To: <1330481540.05.0.869825762197.issue14155@psf.upfronthosting.co.za>
Message-ID: <E1S2htX-0003lt-Os@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3958121a027f by Ezio Melotti in branch '2.7':
#14155: remove duplication about search vs match in re doc.
http://hg.python.org/cpython/rev/3958121a027f

New changeset 4114e816a71b by Ezio Melotti in branch '3.2':
#14155: remove duplication about search vs match in re doc.
http://hg.python.org/cpython/rev/4114e816a71b

New changeset 457c3c0cb0a0 by Ezio Melotti in branch 'default':
#14155: merge with 3.2.
http://hg.python.org/cpython/rev/457c3c0cb0a0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14155>
_______________________________________

From report at bugs.python.org  Wed Feb 29 12:45:40 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 29 Feb 2012 11:45:40 +0000
Subject: [issue14155] Deja vu in re's documentation
In-Reply-To: <1330481540.05.0.869825762197.issue14155@psf.upfronthosting.co.za>
Message-ID: <1330515940.18.0.399563034871.issue14155@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed.
I changed something, as suggested by ?ric.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14155>
_______________________________________

From report at bugs.python.org  Wed Feb 29 12:53:08 2012
From: report at bugs.python.org (Robin Becker)
Date: Wed, 29 Feb 2012 11:53:08 +0000
Subject: [issue8170] Wrong Paths for distutils build --plat-name=win-amd64
In-Reply-To: <1268913333.33.0.305416760988.issue8170@psf.upfronthosting.co.za>
Message-ID: <1330516388.66.0.453186908822.issue8170@psf.upfronthosting.co.za>


Robin Becker <rgbecker at users.sourceforge.net> added the comment:

That would be a solution if we had a separate 64 bit machine & extra versions of Visual Studio, but the actual bug is with the cross-compiling behaviour. If it's not supposed to work then this isn't a bug and section 5.4 should go; otherwise  the correct way to do this should be better documented and made to work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8170>
_______________________________________

From report at bugs.python.org  Wed Feb 29 12:55:44 2012
From: report at bugs.python.org (=?utf-8?q?Jan_St=C3=BCrtz?=)
Date: Wed, 29 Feb 2012 11:55:44 +0000
Subject: [issue14150] AIX,
	crash loading shared module into another process than python like
	operator.so results in 0509-130
In-Reply-To: <1330434369.23.0.116359457055.issue14150@psf.upfronthosting.co.za>
Message-ID: <1330516544.32.0.785885636993.issue14150@psf.upfronthosting.co.za>


Jan St?rtz <stuertz at googlemail.com> added the comment:

Created a patch to fix the configure script, to get the "right" python.exp File.

----------
keywords: +patch
Added file: http://bugs.python.org/file24678/Python-2.7.2-configure.aix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14150>
_______________________________________

From report at bugs.python.org  Wed Feb 29 12:57:48 2012
From: report at bugs.python.org (Martin Morrison)
Date: Wed, 29 Feb 2012 11:57:48 +0000
Subject: [issue14157] time.strptime without a year fails on Feb 29
Message-ID: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za>


New submission from Martin Morrison <martin.morrison at gmail.com>:

time.strptime without a year fails on Feb 29 with:

>>> time.strptime("Feb 29", "%b %d")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/_strptime.py", line 454, in _strptime_time
    return _strptime(data_string, format)[0]
  File "/usr/lib/python2.6/_strptime.py", line 440, in _strptime
    datetime_date(year, 1, 1).toordinal() + 1
ValueError: day is out of range for month

This is due to the use of "1900" as the default year when parsing. It would be nice to have an optional "defaults" keyword argument to the strptime function that can be used to override the defaults, thus allowing leap year dates to be parsed without specifying the date.

(Note: the code in question attempted to set the year *after* the parse so that ultimately there is a valid struct_time, but since the parse never succeeds, this can't work).

----------
components: Library (Lib)
messages: 154621
nosy: Martin.Morrison
priority: normal
severity: normal
status: open
title: time.strptime without a year fails on Feb 29
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14157>
_______________________________________

From report at bugs.python.org  Wed Feb 29 13:07:12 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Feb 2012 12:07:12 +0000
Subject: [issue14089] Patch to increase fractions lib test coverage
In-Reply-To: <1329934239.36.0.224119101932.issue14089@psf.upfronthosting.co.za>
Message-ID: <E1S2iJK-0007Nr-Tk@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8e00de3acb44 by Ezio Melotti in branch '2.7':
#14089: increase coverage of the fractions module.  Patch by Oleg Plakhotnyuk.
http://hg.python.org/cpython/rev/8e00de3acb44

New changeset 0bbc2549e1ee by Ezio Melotti in branch '3.2':
#14089: increase coverage of the fractions module.  Patch by Oleg Plakhotnyuk.
http://hg.python.org/cpython/rev/0bbc2549e1ee

New changeset 90f459e986c8 by Ezio Melotti in branch 'default':
#14089: merge with 3.2.
http://hg.python.org/cpython/rev/90f459e986c8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14089>
_______________________________________

From report at bugs.python.org  Wed Feb 29 13:08:02 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 29 Feb 2012 12:08:02 +0000
Subject: [issue14089] Patch to increase fractions lib test coverage
In-Reply-To: <1329934239.36.0.224119101932.issue14089@psf.upfronthosting.co.za>
Message-ID: <1330517283.0.0.758368478351.issue14089@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the patch!

----------
assignee:  -> ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14089>
_______________________________________

From report at bugs.python.org  Wed Feb 29 13:13:43 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 29 Feb 2012 12:13:43 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1330517623.65.0.399240356211.issue13394@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Converting prints to warnings on 3.2 might not be a good idea.  I can probably still apply the rest of the patch there, and change the warnings on 3.3 only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Wed Feb 29 13:18:20 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 29 Feb 2012 12:18:20 +0000
Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises
	OverflowError
In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za>
Message-ID: <1330517900.13.0.447379969673.issue13169@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Matthew, do you think this should be documented somewhere or that the behavior should be changed (e.g. raising a warning when 65535 is used)?
If not I'll just close the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13169>
_______________________________________

From report at bugs.python.org  Wed Feb 29 13:34:34 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 29 Feb 2012 12:34:34 +0000
Subject: [issue13998] Lookbehind assertions go behind the start position for
	the match
In-Reply-To: <1329036883.7.0.662970564139.issue13998@psf.upfronthosting.co.za>
Message-ID: <1330518874.89.0.278373520675.issue13998@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

IMHO the documentation is fine as is.  Using pos in combination with lookarounds that match on the beginning/end of the "slice" seems a rather uncommon corner case, and I don't think it's worth documenting it.  Even if it was documented, as a user, I would just try it from the interpreter anyway, rather than checking the docs for some prose to decipher.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13998>
_______________________________________

From report at bugs.python.org  Wed Feb 29 13:35:58 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 29 Feb 2012 12:35:58 +0000
Subject: [issue9041] raised exception is misleading
In-Reply-To: <1277123013.52.0.887079191328.issue9041@psf.upfronthosting.co.za>
Message-ID: <1330518958.02.0.0345384043982.issue9041@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9041>
_______________________________________

From report at bugs.python.org  Wed Feb 29 13:40:32 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 29 Feb 2012 12:40:32 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1330519232.61.0.786391594816.issue11379@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Wed Feb 29 14:09:46 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Feb 2012 13:09:46 +0000
Subject: [issue9845] Allow changing the method in urllib.request.Request
In-Reply-To: <1284383235.98.0.831352562835.issue9845@psf.upfronthosting.co.za>
Message-ID: <1330520986.48.0.878093182134.issue9845@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Python 3.3 supports this.

----------
resolution:  -> duplicate
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> urllib2 requests history + HEAD support
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9845>
_______________________________________

From report at bugs.python.org  Wed Feb 29 14:11:31 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Feb 2012 13:11:31 +0000
Subject: [issue12640] test_ctypes seg fault (test_callback_register_double);
	armv7; gcc 4.5.1
In-Reply-To: <1311637071.74.0.758300374846.issue12640@psf.upfronthosting.co.za>
Message-ID: <1330521091.85.0.366902391726.issue12640@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12640>
_______________________________________

From report at bugs.python.org  Wed Feb 29 14:18:25 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Feb 2012 13:18:25 +0000
Subject: [issue14152] setup.py: Python header file dependencies
In-Reply-To: <1330448407.18.0.666571284408.issue14152@psf.upfronthosting.co.za>
Message-ID: <E1S2jQF-0005v7-Vx@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1c77eadba9dc by Stefan Krah in branch '3.2':
Issue #14152: Restore the Include/*.h dependencies for extension builds.
http://hg.python.org/cpython/rev/1c77eadba9dc

New changeset c85812b0e97d by Stefan Krah in branch 'default':
Issue #14152: Merge fix from 3.2.
http://hg.python.org/cpython/rev/c85812b0e97d

New changeset 3e2c230f4664 by Stefan Krah in branch '2.7':
Issue #14152: backport fix.
http://hg.python.org/cpython/rev/3e2c230f4664

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14152>
_______________________________________

From report at bugs.python.org  Wed Feb 29 14:26:01 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 29 Feb 2012 13:26:01 +0000
Subject: [issue14152] setup.py: Python header file dependencies
In-Reply-To: <1330515070.67.0.956599797501.issue14152@psf.upfronthosting.co.za>
Message-ID: <20120229132600.GA30577@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

??ric Araujo <report at bugs.python.org> wrote:
> > To answer your question: Neither of the last two revisions builds
> > in an out-of-source directory.
> My question was more whether the last known good revision did :)

That's what I meant. "last two revisions" was intended to refer to
the last two entries in the list. But I see the ambiguity.  :)

Thanks for reviewing!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14152>
_______________________________________

From report at bugs.python.org  Wed Feb 29 14:35:47 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Feb 2012 13:35:47 +0000
Subject: [issue14152] setup.py: Python header file dependencies
In-Reply-To: <1330448407.18.0.666571284408.issue14152@psf.upfronthosting.co.za>
Message-ID: <1330522547.57.0.931440940929.issue14152@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14152>
_______________________________________

From report at bugs.python.org  Wed Feb 29 14:56:22 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 29 Feb 2012 13:56:22 +0000
Subject: [issue14158] test_mailbox fails if file or dir named by
	support.TESTFN exists
Message-ID: <1330523782.18.0.210760102045.issue14158@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

test_mailbox fails if another failed test leaves a file or directory with the name given by support.TESTFN. The attached patch rectifies this, and also uses existing stdlib functionality (shutil.rmtree) to remove a directory tree recursively on tearDown.

----------
components: Library (Lib)
files: test_mailbox.diff
keywords: patch
messages: 154630
nosy: petri.lehtinen, r.david.murray, vinay.sajip
priority: normal
severity: normal
status: open
title: test_mailbox fails if file or dir named by support.TESTFN exists
versions: Python 3.3
Added file: http://bugs.python.org/file24679/test_mailbox.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14158>
_______________________________________

From report at bugs.python.org  Wed Feb 29 14:56:33 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 29 Feb 2012 13:56:33 +0000
Subject: [issue14158] test_mailbox fails if file or dir named by
	support.TESTFN exists
In-Reply-To: <1330523782.18.0.210760102045.issue14158@psf.upfronthosting.co.za>
Message-ID: <1330523793.45.0.440443202413.issue14158@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14158>
_______________________________________

From report at bugs.python.org  Wed Feb 29 15:06:05 2012
From: report at bugs.python.org (Juan Javier)
Date: Wed, 29 Feb 2012 14:06:05 +0000
Subject: [issue13785] Make concurrent.futures.Future state public
In-Reply-To: <1326560835.55.0.282912980665.issue13785@psf.upfronthosting.co.za>
Message-ID: <1330524365.27.0.237816290971.issue13785@psf.upfronthosting.co.za>


Juan Javier <jjdominguezm at gmail.com> added the comment:

The use case is to know the state of a future without having to do something like this

    @property
    def state(self):
        if self.future.running():
            return Process.States.Running
        elif self.future.cancelled():
            return Process.States.Cancelled
        elif self.future.done():
            return Process.States.Done
        return Process.States.Pending

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13785>
_______________________________________

From report at bugs.python.org  Wed Feb 29 15:18:16 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Feb 2012 14:18:16 +0000
Subject: [issue14158] test_mailbox fails if file or dir named by
	support.TESTFN exists
In-Reply-To: <1330523782.18.0.210760102045.issue14158@psf.upfronthosting.co.za>
Message-ID: <1330525096.54.0.938676741027.issue14158@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Why not just call the helper in setUp?  Otherwise, it looks good to me.

This is a bug fix and should be backported, I believe.

----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14158>
_______________________________________

From report at bugs.python.org  Wed Feb 29 15:39:24 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Feb 2012 14:39:24 +0000
Subject: [issue14158] test_mailbox fails if file or dir named by
	support.TESTFN exists
In-Reply-To: <1330523782.18.0.210760102045.issue14158@psf.upfronthosting.co.za>
Message-ID: <1330526364.48.0.464651650496.issue14158@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> test_mailbox fails if another failed test leaves a file or directory
> with the name given by support.TESTFN. The attached patch rectifies this

You should find which test left the file and fix that test instead.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14158>
_______________________________________

From report at bugs.python.org  Wed Feb 29 15:40:09 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Feb 2012 14:40:09 +0000
Subject: [issue14157] time.strptime without a year fails on Feb 29
In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za>
Message-ID: <1330526409.51.0.94895194632.issue14157@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +belopolsky, haypo, hynek
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14157>
_______________________________________

From report at bugs.python.org  Wed Feb 29 15:43:56 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Feb 2012 14:43:56 +0000
Subject: [issue14153] Expose os.device_encoding() at the C level
In-Reply-To: <1330448630.79.0.296713458855.issue14153@psf.upfronthosting.co.za>
Message-ID: <1330526636.07.0.367895492657.issue14153@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Attached is a patch which is trying to do the refactor, but I'm somehow causing a something to be gc'ed when it shouldn't. If anyone spots something obvious let me know, else I will try to debug some more on my way home.

----------
keywords: +patch
Added file: http://bugs.python.org/file24680/crashing_device_encoding.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14153>
_______________________________________

From report at bugs.python.org  Wed Feb 29 15:45:46 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 29 Feb 2012 14:45:46 +0000
Subject: [issue14158] test_mailbox fails if file or dir named by
	support.TESTFN exists
In-Reply-To: <1330523782.18.0.210760102045.issue14158@psf.upfronthosting.co.za>
Message-ID: <1330526746.5.0.0104575572934.issue14158@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> You should find which test left the file and fix that test instead.

Ideally yes, but it's easier said than done. When the failure occurred, there were many failures, and I couldn't locate the place where the file was being left behind. It was a while ago - I was remiss in not logging the issue then, but real life intervened :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14158>
_______________________________________

From report at bugs.python.org  Wed Feb 29 15:55:24 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 29 Feb 2012 14:55:24 +0000
Subject: [issue14159] __len__ method of weakset
Message-ID: <1330527323.97.0.52214771843.issue14159@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

WeakSet has a bug in its '__len__' method, where it performs iteration though 'self.data' without ensuring _IterationGuard.

This leads to some hard to catch errors with the following traceback:


  builtins.RuntimeError: Set changed size during iteration

    File /usr/lib64/python3.2/_weakrefset.py, line 66, in __len__
        return sum(x() is not None for x in self.data)
    File /usr/lib64/python3.2/_weakrefset.py, line 66, in <genexpr>
        return sum(x() is not None for x in self.data)

----------
components: Library (Lib)
files: weakset_len.patch
keywords: patch
messages: 154636
nosy: Yury.Selivanov, pitrou, rhettinger
priority: normal
severity: normal
status: open
title: __len__ method of weakset
type: crash
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24681/weakset_len.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14159>
_______________________________________

From report at bugs.python.org  Wed Feb 29 16:15:37 2012
From: report at bugs.python.org (Jim Jewett)
Date: Wed, 29 Feb 2012 15:15:37 +0000
Subject: [issue13903] New shared-keys dictionary implementation
In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za>
Message-ID: <1330528537.29.0.642752292673.issue13903@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at gmail.com> added the comment:

As of Feb 28, 2012, the PEP mentions an additional optimization of storing the values in an array indexed by (effectively) key insertion order, rather than key position. ("Alternative Implementation")

It states that this would reduce memory usage for the values array by 1/3.  1/3 is a worst-case measurement; average is 1/2.  (At savings of less than 1/3, the keys would resize, to initial savings of 2/3.  And yes, that means in practice, the average savings would be greater than half, because the frequency of dicts of size N decreases with N.)

It states that the keys table would need an additional "values_size" field, but in the absence of dummies, this is just ma_used.

Note that this would also simplify resizing, as the values arrays would not have to be re-ordered, and would not have to be modified at all unless/until that particular instance received a value for a position beyond its current size.

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13903>
_______________________________________

From report at bugs.python.org  Wed Feb 29 16:19:27 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Feb 2012 15:19:27 +0000
Subject: [issue14153] Expose os.device_encoding() at the C level
In-Reply-To: <1330448630.79.0.296713458855.issue14153@psf.upfronthosting.co.za>
Message-ID: <1330528767.26.0.403915015073.issue14153@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't seen any refcounting problem here, but your patch is buggy.
Before patch:

>>> os.device_encoding(0)
'UTF-8'

After patch:

>>> os.device_encoding(0) is None
True

Interestingly, it seems there is no test for os.device_encoding. Perhaps add one to test_os?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14153>
_______________________________________

From report at bugs.python.org  Wed Feb 29 16:25:15 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Feb 2012 15:25:15 +0000
Subject: [issue14153] Expose os.device_encoding() at the C level
In-Reply-To: <1330528767.26.0.403915015073.issue14153@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYWXno28ZVJFAeB3JYW3xopGbvcDoABoXsc0GGAEAKkkw@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> your patch is buggy

It should be a missing #include. Maybe this one:

#ifdef HAVE_LANGINFO_H
#include <langinfo.h>
#endif

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14153>
_______________________________________

From report at bugs.python.org  Wed Feb 29 16:25:32 2012
From: report at bugs.python.org (Steven Bethard)
Date: Wed, 29 Feb 2012 15:25:32 +0000
Subject: [issue14149] argparse: Document how to use argument names that are
	not Python identifiers
In-Reply-To: <1330431835.85.0.549489798388.issue14149@psf.upfronthosting.co.za>
Message-ID: <1330529132.43.0.0764487826357.issue14149@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

> making Namespace subscriptable

This has been discussed before - see issue 11076. I prefer to keep Namespace as simple as possible. For subscripting, just use the standard Python idiom of vars as suggested in the docs:

http://docs.python.org/library/argparse.html#the-namespace-object

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14149>
_______________________________________

From report at bugs.python.org  Wed Feb 29 16:27:10 2012
From: report at bugs.python.org (Steven Bethard)
Date: Wed, 29 Feb 2012 15:27:10 +0000
Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za>
Message-ID: <1330529230.78.0.914309226412.issue14156@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Yes, the problem is in FileType.__call__ - the handling of '-' is pretty simplistic. Patches welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14156>
_______________________________________

From report at bugs.python.org  Wed Feb 29 16:48:42 2012
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 29 Feb 2012 15:48:42 +0000
Subject: [issue14157] time.strptime without a year fails on Feb 29
In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za>
Message-ID: <1330530522.1.0.28036439577.issue14157@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

This strikes me as an implementation artifact.  There is no reason for time.strptime() to validate date triplets.  Applications that require valid dates can use datetime.strptime().  I suggest changing time.strptime() specification to match POSIX strptime().  My understanding is that POSIX only requires field by field range checking (%d range 01 to 31, %m range 01 to 12) and not full structure validation.  This would be consistent with the way leap seconds are currently treated:

>>> time.strptime('60', '%S')[5]
60

----------
assignee:  -> belopolsky
stage:  -> needs patch
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14157>
_______________________________________

From report at bugs.python.org  Wed Feb 29 16:51:00 2012
From: report at bugs.python.org (Matthew Miller)
Date: Wed, 29 Feb 2012 15:51:00 +0000
Subject: [issue14160] Tarfile.extractfile fails to extract targets of
	top-level relative symlinks
Message-ID: <1330530660.51.0.926091322087.issue14160@psf.upfronthosting.co.za>


New submission from Matthew Miller <mattdm at mattdm.org>:

I have a tarfile with relative paths. The tail of tar tvf looks like this:

-rw-r--r-T nobody/nobody  1356 2012-02-28 19:25 s/772
-rw-r--r-- nobody/nobody  1304 2012-02-28 19:25 s/773
-rw-r--r-- nobody/nobody  1304 2012-02-28 19:25 s/774
-rw-r--r-- nobody/nobody  1304 2012-02-28 19:25 s/775
lrw-r--r-- nobody/nobody     0 2012-02-28 19:25 final -> s/772

The docs say:

  TarFile.extractfile(member)

    Extract a member from the archive as a file object. member 
    may be a filename or a TarInfo object. If member is a regular
    file, a file-like object is returned. If member is a link, a 
    file-like object is constructed from the link?s target.

However, what I'm getting is this:

  KeyError: "linkname '/s/772' not found"


It's appending a "/". Why?

Well, in tarfile.py:

        if tarinfo.issym():
            # Always search the entire archive.
            linkname = os.path.dirname(tarinfo.name) + "/" + tarinfo.linkname
            limit = None


Here,  os.path.dirname(tarinfo.name) returns '', and then the "/" is appended, giving an incorrect result.

One solution would be:

   linkname = os.path.join(os.path.dirname(tarinfo.name),tarinfo.linkname)

but I don't think that works on platforms where os.sep is not "/", since tar will want "/" in any case. But that's the correct logic.

I'm filing this against 2.7, but the same issue exists in 3.2.

A work-around in end-user code is to call Tarfile.getmember(filename), check if the result issym(), and replace the result with Tarfile.getmember(tarinfo.linkname). But since the extractfile function is documented as following symlinks, that should not be necessary.

This bug isn't commonly encountered because by convention tarfiles usually contain a subdirectory and everything goes in that. But we should do the right thing.

----------
components: Library (Lib)
messages: 154643
nosy: Matthew.Miller
priority: normal
severity: normal
status: open
title: Tarfile.extractfile fails to extract targets of top-level relative symlinks
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14160>
_______________________________________

From report at bugs.python.org  Wed Feb 29 17:20:33 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Feb 2012 16:20:33 +0000
Subject: [issue14159] __len__ method of weakset
In-Reply-To: <1330527323.97.0.52214771843.issue14159@psf.upfronthosting.co.za>
Message-ID: <1330532433.06.0.802973002051.issue14159@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I can't find a way to reproduce as a unit test.
Here is a patch making __len__ O(1) as well (instead of O(n)). Could you try it?

(note : AFAICT, a similar issue exists for weak dicts)

----------
stage:  -> needs patch
versions: +Python 2.7
Added file: http://bugs.python.org/file24682/weaksetlen.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14159>
_______________________________________

From report at bugs.python.org  Wed Feb 29 17:24:26 2012
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 29 Feb 2012 16:24:26 +0000
Subject: [issue13903] New shared-keys dictionary implementation
In-Reply-To: <1330528537.29.0.642752292673.issue13903@psf.upfronthosting.co.za>
Message-ID: <4F4E513C.2010906@hotpy.org>


Mark Shannon <mark at hotpy.org> added the comment:

Jim Jewett wrote:
> Jim Jewett <jimjjewett at gmail.com> added the comment:
> 
> As of Feb 28, 2012, the PEP mentions an additional optimization of storing the values in an array indexed by (effectively) key insertion order, rather than key position. ("Alternative Implementation")
> 
> It states that this would reduce memory usage for the values array by 1/3.  1/3 is a worst-case measurement; average is 1/2.  (At savings of less than 1/3, the keys would resize, to initial savings of 2/3.  And yes, that means in practice, the average savings would be greater than half, because the frequency of dicts of size N decreases with N.)
> 

I presume you mean to allocate a values array of size == actual keys
rather than size == usable keys.

Making the  values array smaller than the the number of usable keys
causes a number of issues:

1. The values_size will need to be kept in the dict, not in the keys, 
which would make the dict larger for size 3 or 5, the same size for
size 2 or 4, but it would save memory for sizes 6-8 (see below).
So it might not save memory at all, it depends on the distribution of 
the sizes of shared-key dicts.
2. dk_usable would need to be reverted to dk_fill (c.f ma_fill) in order
to quickly allocate values arrays. This would slow down the resizing 
check, which is now done before insertion, so might be slower.
(not really a problem, but it might slow down inserts)
3. An extra check needs to be performed for each read to ensure the 
index is in-bounds
(again not really a problem, but it might slow down reads)

Comparative sizes of values array (including size field):

Items Proposed    Alternative    Other Alternative    Delta
                (size == usuable) (size == keys (+1))
   1      4           3                 2              -1	
   2      4           3                 3               0
   3      4           3                 4              +1
   4      8           5                 5               0
   5      8           5                 6              +1
   6     16          10                 7              -3
   7     16          10                 8              -2
   8     16          10                 9              -1
   9     16          10                10               0
  10     16          10                11              +1
  12     32          21                13              -8
  14     32          21                15              -6

The memory savings of the two alternative implementations are broadly
similar.

Clearly, either of the alternatives are attractive in terms of memory 
use. I think it is definitely worth investigating further, but I would 
like to get the proposed implementation into CPython first.

> It states that the keys table would need an additional "values_size" field, but in the absence of dummies, this is just ma_used.

values_size != ma_used
values_size is the size of the values array, not the number of values.

Don't forget deletions or the case where items are inserted in a 
different order from that of another dict sharing the same keys.
Although there are no dummies, (key != NULL, value == NULL) is a legal
pair representing a missing or deleted value.

Cheers,
Mark.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13903>
_______________________________________

From report at bugs.python.org  Wed Feb 29 17:37:48 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 29 Feb 2012 16:37:48 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1330533468.82.0.275971200388.issue11379@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The wording in msg152836 is fine with me, in particular as it doesn't make any performance claims.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Wed Feb 29 17:41:58 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Feb 2012 16:41:58 +0000
Subject: [issue14159] __len__ method of weakset
In-Reply-To: <1330527323.97.0.52214771843.issue14159@psf.upfronthosting.co.za>
Message-ID: <1330533718.07.0.703843288071.issue14159@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

New patch addressing similar issue with weak dicts, and adding more tests.

----------
Added file: http://bugs.python.org/file24683/weaksetlen2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14159>
_______________________________________

From report at bugs.python.org  Wed Feb 29 17:42:06 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 29 Feb 2012 16:42:06 +0000
Subject: [issue14159] __len__ method of weakset
In-Reply-To: <1330527323.97.0.52214771843.issue14159@psf.upfronthosting.co.za>
Message-ID: <1330533726.57.0.66241329262.issue14159@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Yes, I couldn't reproduce it either.  However it frequently occurs on our buildbot, so tomorrow I'll give you an update if this patch resolves the issue or not.

In any way, your patch fixes the current implementation at least from the performance perspective.  I think it should be applied to 'WeakValueDictionary.__len__' as well.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14159>
_______________________________________

From report at bugs.python.org  Wed Feb 29 17:43:30 2012
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Wed, 29 Feb 2012 16:43:30 +0000
Subject: [issue14161] python2 file __repr__ does not escape filename
Message-ID: <1330533810.56.0.673512322833.issue14161@psf.upfronthosting.co.za>


New submission from Ronny Pfannschmidt <ronny.pfannschmidt at gmail.com>:

behaviour:
>>> name = 'woo\raa'
>>> open(name, 'w')
aa', mode 'w' at 0x295a8a0>

expected:
>>> name = 'woo\raa'
>>> open(name, 'w')
<open file 'woo\raa', mode 'w' at 0x295a8a0>

note:
don't ask why i tried this chunk of code in the first place

----------
messages: 154649
nosy: Ronny.Pfannschmidt
priority: normal
severity: normal
status: open
title: python2 file __repr__ does not escape filename
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14161>
_______________________________________

From report at bugs.python.org  Wed Feb 29 17:53:35 2012
From: report at bugs.python.org (Piotr Dobrogost)
Date: Wed, 29 Feb 2012 16:53:35 +0000
Subject: [issue4080] pyunit - display time of each test case - patch
In-Reply-To: <1223497696.14.0.913391715353.issue4080@psf.upfronthosting.co.za>
Message-ID: <1330534415.77.0.99148470212.issue4080@psf.upfronthosting.co.za>


Piotr Dobrogost <pd at python.dobrogost.net> added the comment:

@Michael Foord

> I am in the process of creating an extension mechanism for unittest
> which will make adding this sort of use case to unittest much easier

How is it going?

----------
nosy: +piotr.dobrogost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4080>
_______________________________________

From report at bugs.python.org  Wed Feb 29 17:54:31 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Feb 2012 16:54:31 +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: <E1S2mnN-0005GJ-N8@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9d3c7dd55c7f by Stefan Krah in branch 'default':
Issue #10181: Add warning that structure layouts in memoryobject.h and
http://hg.python.org/cpython/rev/9d3c7dd55c7f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Wed Feb 29 18:41:44 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Feb 2012 17:41:44 +0000
Subject: [issue14153] Expose os.device_encoding() at the C level
In-Reply-To: <1330448630.79.0.296713458855.issue14153@psf.upfronthosting.co.za>
Message-ID: <1330537304.92.0.697146551077.issue14153@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Victor's point fixed my issue.

As for a test, I will happily write one, but what can I test? A string for fd 0 and None for fd -1 (or is there some os call I can make to find the largest fd so I can test fd+1)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14153>
_______________________________________

From report at bugs.python.org  Wed Feb 29 18:51:51 2012
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 29 Feb 2012 17:51:51 +0000
Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises
	OverflowError
In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za>
Message-ID: <1330537911.28.0.655242344999.issue13169@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Ideally, it should raise an exception (or a warning) because the behaviour is unexpected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13169>
_______________________________________

From report at bugs.python.org  Wed Feb 29 18:57:32 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Feb 2012 17:57:32 +0000
Subject: [issue14153] Expose os.device_encoding() at the C level
In-Reply-To: <1330537304.92.0.697146551077.issue14153@psf.upfronthosting.co.za>
Message-ID: <1330538024.3399.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> As for a test, I will happily write one, but what can I test? A string
> for fd 0 and None for fd -1 (or is there some os call I can make to
> find the largest fd so I can test fd+1)?

For fd 0, it should be a string if the fd is a tty.
(it should also point to a valid codec)
You can also try fd 42 (same, call isatty() on it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14153>
_______________________________________

From report at bugs.python.org  Wed Feb 29 19:05:04 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Feb 2012 18:05:04 +0000
Subject: [issue14162] Implementation of the PEP 416 (Add a builtin frozendict
	type)
Message-ID: <1330538704.6.0.815931694291.issue14162@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

Patch to implement the PEP 416.

----------
components: Interpreter Core
files: frozendict.patch
keywords: patch
messages: 154655
nosy: haypo
priority: normal
severity: normal
status: open
title: Implementation of the PEP 416 (Add a builtin frozendict type)
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file24684/frozendict.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14162>
_______________________________________

From report at bugs.python.org  Wed Feb 29 19:08:42 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Feb 2012 18:08:42 +0000
Subject: [issue14162] Implementation of the PEP 416 (Add a builtin frozendict
	type)
In-Reply-To: <1330538704.6.0.815931694291.issue14162@psf.upfronthosting.co.za>
Message-ID: <1330538922.22.0.0217240949552.issue14162@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file24684/frozendict.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14162>
_______________________________________

From report at bugs.python.org  Wed Feb 29 19:08:59 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 29 Feb 2012 18:08:59 +0000
Subject: [issue14161] python2 file __repr__ does not escape filename
In-Reply-To: <1330533810.56.0.673512322833.issue14161@psf.upfronthosting.co.za>
Message-ID: <1330538939.17.0.216936889593.issue14161@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Interpreter Core
nosy: +eric.araujo, ezio.melotti, pitrou
stage:  -> needs patch
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14161>
_______________________________________

From report at bugs.python.org  Wed Feb 29 19:15:19 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Feb 2012 18:15:19 +0000
Subject: [issue14162] Implementation of the PEP 416 (Add a builtin frozendict
	type)
In-Reply-To: <1330538704.6.0.815931694291.issue14162@psf.upfronthosting.co.za>
Message-ID: <1330539319.56.0.463536134066.issue14162@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file24685/frozendict.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14162>
_______________________________________

From report at bugs.python.org  Wed Feb 29 19:20:03 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Feb 2012 18:20:03 +0000
Subject: [issue14162] Implementation of the PEP 416 (Add a builtin frozendict
	type)
In-Reply-To: <1330538704.6.0.815931694291.issue14162@psf.upfronthosting.co.za>
Message-ID: <1330539603.29.0.751371089486.issue14162@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

There is no documentation update yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14162>
_______________________________________

From report at bugs.python.org  Wed Feb 29 19:24:19 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Feb 2012 18:24:19 +0000
Subject: [issue14153] Expose os.device_encoding() at the C level
In-Reply-To: <1330538024.3399.1.camel@localhost.localdomain>
Message-ID: <CAMpsgwYibcm_YNA79ZdmoRb-CWaHbyHY6G0Lpx4v4r+fQj26ow@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> For fd 0, it should be a string if the fd is a tty.

os.device_encoding() returns None on a non-Windows OS without langinfo support.

locale.nl_langinfo(locale.CODESET) may be used in such test. (to check
for nl_langinfo() support?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14153>
_______________________________________

From report at bugs.python.org  Wed Feb 29 19:38:09 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Feb 2012 18:38:09 +0000
Subject: [issue14153] Expose os.device_encoding() at the C level
In-Reply-To: <1330448630.79.0.296713458855.issue14153@psf.upfronthosting.co.za>
Message-ID: <1330540689.78.0.762669968512.issue14153@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, so if on windows or isatty + nl_langinfo + CODESET, check fd 0 for a returned string that codecs.lookup and find something for. fd 42 (if not a tty) should return None.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14153>
_______________________________________

From report at bugs.python.org  Wed Feb 29 19:54:25 2012
From: report at bugs.python.org (Shawn)
Date: Wed, 29 Feb 2012 18:54:25 +0000
Subject: [issue14157] time.strptime without a year fails on Feb 29
In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za>
Message-ID: <1330541665.38.0.00380983944229.issue14157@psf.upfronthosting.co.za>


Shawn <swalker at opensolaris.org> added the comment:

I'm seeing this when a year *is* specified with Python 2.6 and 2.7:


import time
time.strptime("20090229T184823Z", "%Y%m%dT%H%M%SZ")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/_strptime.py", line 454, in _strptime_time
    return _strptime(data_string, format)[0]
  File "/usr/lib/python2.6/_strptime.py", line 440, in _strptime
    datetime_date(year, 1, 1).toordinal() + 1
ValueError: day is out of range for month


import datetime
datetime.datetime.strptime("20090229T184823Z", "%Y%m%dT%H%M%SZ")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/_strptime.py", line 440, in _strptime
    datetime_date(year, 1, 1).toordinal() + 1
ValueError: day is out of range for month

----------
nosy: +swalker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14157>
_______________________________________

From report at bugs.python.org  Wed Feb 29 20:04:54 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 29 Feb 2012 19:04:54 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1330542294.1.0.323337754649.issue11379@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I'm attaching a patch for Doc/library/xml.dom.minidom.rst 

It adds the note as phrased by Stefan, with a tiny wording change to make the first sentence less ambiguous.

----------
keywords: +patch
Added file: http://bugs.python.org/file24686/issue_11379.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Wed Feb 29 20:05:45 2012
From: report at bugs.python.org (Shawn)
Date: Wed, 29 Feb 2012 19:05:45 +0000
Subject: [issue14157] time.strptime without a year fails on Feb 29
In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za>
Message-ID: <1330542345.4.0.0233010144807.issue14157@psf.upfronthosting.co.za>


Shawn <swalker at opensolaris.org> added the comment:

I'm an idiot; nevermind my comment.  The original date was bogus.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14157>
_______________________________________

From report at bugs.python.org  Wed Feb 29 20:17:59 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 29 Feb 2012 19:17:59 +0000
Subject: [issue14158] test_mailbox fails if file or dir named by
	support.TESTFN exists
In-Reply-To: <1330523782.18.0.210760102045.issue14158@psf.upfronthosting.co.za>
Message-ID: <1330543079.24.0.866532532631.issue14158@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
hgrepos: +115

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14158>
_______________________________________

From report at bugs.python.org  Wed Feb 29 20:19:08 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 29 Feb 2012 19:19:08 +0000
Subject: [issue14158] test_mailbox fails if file or dir named by
	support.TESTFN exists
In-Reply-To: <1330523782.18.0.210760102045.issue14158@psf.upfronthosting.co.za>
Message-ID: <1330543148.51.0.449589647925.issue14158@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


Added file: http://bugs.python.org/file24687/b0da15d31aec.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14158>
_______________________________________

From report at bugs.python.org  Wed Feb 29 21:43:00 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Wed, 29 Feb 2012 20:43:00 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2 and
	python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1330548180.93.0.398319999566.issue6784@psf.upfronthosting.co.za>


Merlijn van Deen <valhallasw at gmail.com> added the comment:

Added tests in Lib/test format.

After applying pickle.py.patch and BytestrPickler_c.diff, 
    ./python -m test -v -m PyPicklerBytestrTests test_pickle
returns 12 tests, no errors, while 
    ./python -m test -v -m CPicklerBytestrTests test_pickle
only passes
test_dump_bytes_protocol_0 (test.test_pickle.CPicklerBytestrTests) ... ok
test_dump_bytes_protocol_1 (test.test_pickle.CPicklerBytestrTests) ... ok
test_dump_bytes_protocol_2 (test.test_pickle.CPicklerBytestrTests) ... ok
test_dump_bytes_protocol_3 (test.test_pickle.CPicklerBytestrTests) ... ok

and has 8 errors (as expected).

----------
Added file: http://bugs.python.org/file24688/test_pickle.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Wed Feb 29 21:46:45 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Wed, 29 Feb 2012 20:46:45 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>
Message-ID: <1330548405.81.0.808132047015.issue12659@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

Patch updated.

BTW, I didn't get any email due the review that ?ric did (does one has to be registered? I've done that now).

----------
Added file: http://bugs.python.org/file24689/issue12659_434cd2fedf81.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12659>
_______________________________________

From report at bugs.python.org  Wed Feb 29 21:53:18 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Wed, 29 Feb 2012 20:53:18 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>
Message-ID: <1330548798.46.0.704097746351.issue12659@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

> Patch looks good, thanks!  BTW are you running a coverage tool to see > how far along we are?

Yes, always. The classes tested in that patch are at 100%.

The overall coverage is:

Name                          Stmts   Miss  Cover   Missing
-----------------------------------------------------------
Lib/packaging/tests/support     173     34    80%   296-301, 306-310, 334-337, 341-347, 371-390, 395-396

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12659>
_______________________________________

From report at bugs.python.org  Wed Feb 29 22:18:38 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 29 Feb 2012 21:18:38 +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: <1330550318.07.0.584193062605.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

For 3.2, there's no removal to document - we asked MvL to drop the buffer APIs from PEP 384, so they've never been part of the stable ABI.

>From the PEP: "The buffer interface (type Py_buffer, type slots bf_getbuffer and bf_releasebuffer, etc) has been omitted from the ABI, since the stability of the Py_buffer structure is not clear at this time. Inclusion in the ABI can be considered in future releases."

I agree we shouldn't be hasty in making even the updated buffer interface implementation officially part of the stable ABI. Better to leave it out for 3.3, get some real world feedback on the latest version, then commit to stability for 3.4+.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Wed Feb 29 23:06:44 2012
From: report at bugs.python.org (py.user)
Date: Wed, 29 Feb 2012 22:06:44 +0000
Subject: [issue14155] Deja vu in re's documentation
In-Reply-To: <1330481540.05.0.869825762197.issue14155@psf.upfronthosting.co.za>
Message-ID: <1330553204.22.0.318967507999.issue14155@psf.upfronthosting.co.za>


py.user <port139 at yandex.ru> added the comment:

the multiline mode affects on regex.match()

>>> p = re.compile(r'^a')
>>> p.match('abc\nabc')
<_sre.SRE_Match object at 0xb749bf38>
>>> p.match('abc\nabc').span()
(0, 1)
>>> p.match('abc\nabc', 4)
>>> 
>>> p = re.compile(r'^a', re.M)
>>> p.match('abc\nabc', 4)
<_sre.SRE_Match object at 0xb749bf38>
>>> p.match('abc\nabc', 4).span()
(4, 5)
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14155>
_______________________________________

From report at bugs.python.org  Wed Feb 29 23:51:03 2012
From: report at bugs.python.org (Mark Hammond)
Date: Wed, 29 Feb 2012 22:51:03 +0000
Subject: [issue8170] Wrong Paths for distutils build --plat-name=win-amd64
In-Reply-To: <1268913333.33.0.305416760988.issue8170@psf.upfronthosting.co.za>
Message-ID: <1330555863.22.0.156285424628.issue8170@psf.upfronthosting.co.za>


Mark Hammond <skippy.hammond at gmail.com> added the comment:

Those instructions in section 5.4 do seem wrong.  On first reading they imply that you need to start with a clean source tree on your 32bit Windows, then build the 64bit version of Python.  So far so good.  However, then you need to run python.exe - which must be a 32bit version of Python or it wouldn't start.

So I *guess* the instructions really should say to build *both* the 32 and 64bit versions in the same source tree - in which case I can see why your patch would be necessary.

Can you confirm the process you used?  I assume you did build both versions in the same tree, but you also mentioned copying the .lib files around - was that an attempt to work around this bug?

But yeah, sorry for the distraction - given 5.4 I think this bug is probably valid, but the patch should probably include updated instructions in 5.4 to make it more clear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8170>
_______________________________________