Mailman 3 March 2012 - Python-Dev

Re: [Python-Dev] [Python-checkins] cpython (2.7): Fixes Issue 14234: fix for the previous commit, keep compilation when
by Jim Jewett March 19, 2012

March 19, 2012

Does this mean that if Python is updated before expat, python will compile out the expat randomization, and therefore not use if even after expat is updated? -jJ On Thu, Mar 15, 2012 at 2:01 PM, benjamin.peterson <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/ada6bfbeceb8 > changeset: 75699:ada6bfbeceb8 > branch: 2.7 > user: Gregory P. Smith <greg(a)krypto.org> > date: &… [View More]

2 1

Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives
by Andrey Petrov March 19, 2012

March 19, 2012

Hi Pythonistas, I've had the pleasure of speaking with Guido at PyCon and it became evident that some of Python's included batteries are significantly lagging behind the rapidly-evolving defacto standards of the community—specifically in cases like urllib and urllib2, which lack important features provided by alternatives like httplib2, requests, and my own urllib3. Part 1: I propose we add a snippet to the top of the documentation of specific archaic standard modules which encourages users … [View More]to investigate third-party alternatives if they find the standard module frustrating or otherwise lacking. These notes would target new users, including those coming from other languages where the third-party library choices are not nearly as amazing as they are in Python. (For what it's worth, Guido has verbally agreed to a proposal of this nature.) What such a snippet might look like: "Batteries are included with Python but sometimes they are old and leaky—this is one of those cases. Please have a look in PyPI for more modern alternatives provided by the Python community." Additionally, I would like for us as a community to identify which other standard libraries (cgi? ssl? others?) are candidates for this kind of messaging in the official Python documentation. Part 2: I propose we add a new category of package identifiers such as "Topic :: Standard Library Alternative :: {stdlib_package_name}" which authors of libraries can tag themselves under. The documentation warning snippet will provide a link to the appropriate PyPI query to list packages claiming to be alternatives to the stdlib package in question. Objections? Concerns? Improvements? What is the next step to making this happen? Pythonically yours, - Andrey (on behalf of Ori Livneh, Kenneth Reitz, Brandon Rhodes, David Wolever, and everyone else who contributed to this letter during our PyCon sprint.) P.S. Appendix: Here are some additional snippet alternatives that were proposed: > Batteries are included with Python but sometimes they are old and leaky—this is one of those cases. Please have a look in PyPI for more modern alternatives provided by the Python community. > While this module has served Python programmers faithfully for many years, there are now many powerful alternatives available as third-party modules. To learn more about them, view the Python Package Index results for the category "Topic :: Standard Library Alternative :: asyncore." — [With the topic name as a hyperlink] > This module has been identified by the community as crusty, a signal that better alternatives exist outside the standard library. Because the Python standard library is constained to maintain backward-compatibility, it does not always reflect what is current or common in the Python community. If you are not constrained to support legacy code, you may wish to browse the Python Package Index for alternatives to this module. [View Less]

20 46

Re: [Python-Dev] [Python-checkins] cpython: Issue #14347: Update Misc/README list of files.
by Brett Cannon March 19, 2012

March 19, 2012

The two files that were added back in should probably just disappear (README.aix and README.coverty). Anyone disagree? On Sat, Mar 17, 2012 at 13:52, ned.deily <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/65a0a6fab127 > changeset: 75797:65a0a6fab127 > user: Ned Deily <nad(a)acm.org> > date: Sat Mar 17 10:52:08 2012 -0700 > summary: > Issue #14347: Update Misc/README list of files. > (Initial patch by Dionysios … [View More]

2 1

inspect.py change for pygame
by ncdave4life March 18, 2012

March 18, 2012

I noticed that pydoc doesn't work for pygame under python 3.2.1 for Win32: NotImplementedError: scrap module not available (ImportError: No module named scrap) I made a small patch to inspect.py to solve the problem (I just added a try/expect around the failing statement in ismethoddescriptor). Here's the diff: http://www.burtonsys.com/python32/inspect.diff http://www.burtonsys.com/python32/inspect.diff With that patch, pydoc works with pygame, and reports just a few issues: *scrap* = … [View More]

2 2

Re: [Python-Dev] cpython: PEP 417: Adding unittest.mock
by Georg Brandl March 18, 2012

March 18, 2012

On 14.03.2012 20:25, michael.foord wrote: > http://hg.python.org/cpython/rev/2fda048ee32a > changeset: 75632:2fda048ee32a > user: Michael Foord<michael(a)voidspace.org.uk> > date: Wed Mar 14 12:24:34 2012 -0700 > summary: > PEP 417: Adding unittest.mock > > files: > Lib/unittest/mock.py | 2151 ++++++++++ > Lib/unittest/test/__init__.py | 1 + > Lib/unittest/test/testmock/__init__.py … [View More]

7 8

[RELEASED] Second release candidates for Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3
by Benjamin Peterson March 18, 2012

March 18, 2012

We're chuffed to announce the immediate availability of the second release candidates for Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3. The only change from the first release candidates is the patching of an additional security hole. The security issue fixed in the second release candidates is in the expat XML parsing library. expat had the same hash security issue detailed below as Python's core types. The hashing algorithm used in the expat library is now randomized. A more thorough explanation of … [View More]the "hash attack" security hole follows. The main impetus for these releases is fixing a security issue in Python's hash based types, dict and set, as described below. Python 2.7.3 and 3.2.3 include the security patch and the normal set of bug fixes. Since Python 2.6 and 3.1 are maintained only for security issues, 2.6.8 and 3.1.5 contain only various security patches. The security issue exploits Python's dict and set implementations. Carefully crafted input can lead to extremely long computation times and denials of service. [1] Python dict and set types use hash tables to provide amortized constant time operations. Hash tables require a well-distributed hash function to spread data evenly across the hash table. The security issue is that an attacker could compute thousands of keys with colliding hashes; this causes quadratic algorithmic complexity when the hash table is constructed. To alleviate the problem, the new releases add randomization to the hashing of Python's string types (bytes/str in Python 3 and str/unicode in Python 2), datetime.date, and datetime.datetime. This prevents an attacker from computing colliding keys of these types without access to the Python process. Hash randomization causes the iteration order of dicts and sets to be unpredictable and differ across Python runs. Python has never guaranteed iteration order of keys in a dict or set, and applications are advised to never rely on it. Historically, dict iteration order has not changed very often across releases and has always remained consistent between successive executions of Python. Thus, some existing applications may be relying on dict or set ordering. Because of this and the fact that many Python applications which don't accept untrusted input are not vulnerable to this attack, in all stable Python releases mentioned here, HASH RANDOMIZATION IS DISABLED BY DEFAULT. There are two ways to enable it. The -R commandline option can be passed to the python executable. It can also be enabled by setting an environmental variable PYTHONHASHSEED to "random". (Other values are accepted, too; pass -h to python for complete description.) More details about the issue and the patch can be found in the oCERT advisory [1] and the Python bug tracker [2]. These releases are releases candidates and thus not recommended for production use. Please test your applications and libraries with them, and report any bugs you encounter. We are especially interested in any buggy behavior observed using hash randomization. Excepting major calamity, final versions should appear after several weeks. Downloads are at http://python.org/download/releases/2.6.8/ http://python.org/download/releases/2.7.3/ http://python.org/download/releases/3.1.5/ http://python.org/download/releases/3.2.3/ Please test these candidates and report bugs to http://bugs.python.org/ With regards, The Python release team Barry Warsaw (2.6), Georg Brandl (3.2), Benjamin Peterson (2.7 and 3.1) [1] http://www.ocert.org/advisories/ocert-2011-003.html [2] http://bugs.python.org/issue13703 [View Less]

1 0

Re: [Python-Dev] [Python-checkins] cpython (2.7): Closes #14306: clarify expensiveness of try-except and update code snippet
by Nick Coghlan March 18, 2012

March 18, 2012

On Sun, Mar 18, 2012 at 1:58 AM, georg.brandl <python-checkins(a)python.org> wrote: > +catching an exception is expensive. In versions of Python prior to 2.0 it was > +common to use this idiom:: Actually, given the "prior to 2.0" caveat, "mydict.has_key(key)" is right: the "key in mydict" version was only added in 2.2. This answer probably needs more improvements than just modernising the example that is already there. Cheers, Nick. -- Nick Coghlan | &… [View More]

1 0

Re: [Python-Dev] cpython (2.6): Added tag v2.6.8rc2 for changeset bd9e1a02e3e3
by Georg Brandl March 18, 2012

March 18, 2012

On 03/18/2012 12:15 AM, Éric Araujo wrote: > Hi, > > Le 17/03/2012 19:03, Georg Brandl a écrit : >> On 03/17/2012 11:43 PM, Barry Warsaw wrote: >> I'm afraid it's the latter: tags are entries in .hgtags. So when you completely >> null-merge your 2.6 changes into 2.7, you are basically removing the tag from >> the 2.7 branch. And since to find tags, Mercurial looks in the .hgtags files >> of all active branch heads, you are basically hiding the tag when … [View More]

1 0

Re: [Python-Dev] [Python-checkins] cpython (2.6): Added tag v2.6.8rc2 for changeset bd9e1a02e3e3
by Barry Warsaw March 17, 2012

March 17, 2012

On Mar 17, 2012, at 07:15 PM, Éric Araujo wrote: >Note that duplicate entries in .hgtags (when a tag was redone) should >not be “cleaned up”: the presence of the old changeset hash greatly >helps conflict resolution. (If someone pulled the repo with the old tag >and later pulls and updates, then they don’t have to find out which hash >is the right tag, they just accept all changes from the updated file >into their local file.) But if someone wants to grab the 2.6.8rc2 tag, … [View More]

1 0

Re: [Python-Dev] [Python-checkins] cpython (2.6): Added tag v2.6.8rc2 for changeset bd9e1a02e3e3
by Barry Warsaw March 17, 2012

March 17, 2012

On Mar 18, 2012, at 12:03 AM, Georg Brandl wrote: >I'm afraid it's the latter: tags are entries in .hgtags. So when you >completely null-merge your 2.6 changes into 2.7, you are basically removing >the tag from the 2.7 branch. And since to find tags, Mercurial looks in the >.hgtags files of all active branch heads, you are basically hiding the tag >when you merge 2.6 into 2.7, at which point it becomes an inactive branch >head. D'oh. Okay, so leave the .hgtags file alone … [View More]

1 0