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 19 Mar '12

19 Mar '12

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: Wed Mar 14 18:12:23 2012 -0700 > summary: > Fixes Issue 14234: fix for the previous commit, keep compilation when > using --with-system-expat working when the system expat does not have > salted hash support. > > files: > Modules/expat/expat.h | 2 ++ > Modules/pyexpat.c | 5 +++++ > 2 files changed, 7 insertions(+), 0 deletions(-) > > > diff --git a/Modules/expat/expat.h b/Modules/expat/expat.h > --- a/Modules/expat/expat.h > +++ b/Modules/expat/expat.h > @@ -892,6 +892,8 @@ > XML_SetHashSalt(XML_Parser parser, > unsigned long hash_salt); > > +#define XML_HAS_SET_HASH_SALT /* Python Only: Defined for pyexpat.c. */ > + > /* If XML_Parse or XML_ParseBuffer have returned XML_STATUS_ERROR, then > XML_GetErrorCode returns information about the error. > */ > diff --git a/Modules/pyexpat.c b/Modules/pyexpat.c > --- a/Modules/pyexpat.c > +++ b/Modules/pyexpat.c > @@ -1302,8 +1302,13 @@ > else { > self->itself = XML_ParserCreate(encoding); > } > +#if ((XML_MAJOR_VERSION >= 2) && (XML_MINOR_VERSION >= 1)) || defined(XML_HAS_SET_HASH_SALT) > + /* This feature was added upstream in libexpat 2.1.0. Our expat copy > + * has a backport of this feature where we also define XML_HAS_SET_HASH_SALT > + * to indicate that we can still use it. */ > XML_SetHashSalt(self->itself, > (unsigned long)_Py_HashSecret.prefix); > +#endif > self->intern = intern; > Py_XINCREF(self->intern); > #ifdef Py_TPFLAGS_HAVE_GC > > -- > Repository URL: http://hg.python.org/cpython > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins >

2 1

Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives
by Andrey Petrov 19 Mar '12

19 Mar '12

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 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.

20 46

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

19 Mar '12

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 Kalofonos) > > files: > Misc/README | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > > diff --git a/Misc/README b/Misc/README > --- a/Misc/README > +++ b/Misc/README > @@ -8,7 +8,6 @@ > ---------------- > > ACKS Acknowledgements > -build.sh Script to build and test latest Python from the > repository > gdbinit Handy stuff to put in your .gdbinit file, if you > use gdb > HISTORY News from previous releases -- oldest last > indent.pro GNU indent profile approximating my C style > @@ -19,6 +18,8 @@ > python.pc.in Package configuration info template for > pkg-config > python-wing*.wpr Wing IDE project file > README The file you're reading now > +README.AIX Information about using Python on AIX > +README.coverity Information about running Coverity's Prevent on > Python > README.valgrind Information for Valgrind users, see > valgrind-python.supp > RPM (Old) tools to build RPMs > svnmap.txt Map of old SVN revs and branches to hg changeset > ids > > -- > Repository URL: http://hg.python.org/cpython > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins > >

2 1

inspect.py change for pygame
by ncdave4life 19 Mar '12

19 Mar '12

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* = <pygame.MissingModule object> *sndarray* = <pygame.MissingModule object> *surfarray* = <pygame.MissingModule object> Sorry, I'm a newbie to python-dev, so please forgive my ignorance, but what do I need to do get this fix (or something similar) into a future release? -- View this message in context: http://python.6.n6.nabble.com/inspect-py-change-for-pygame-tp4631993p463199… Sent from the Python - python-dev mailing list archive at Nabble.com.

2 2

Re: [Python-Dev] cpython: PEP 417: Adding unittest.mock
by Georg Brandl 19 Mar '12

19 Mar '12

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 | 17 + > Lib/unittest/test/testmock/support.py | 23 + > Lib/unittest/test/testmock/testcallable.py | 159 + > Lib/unittest/test/testmock/testhelpers.py | 835 +++ > Lib/unittest/test/testmock/testmagicmethods.py | 382 + > Lib/unittest/test/testmock/testmock.py | 1258 +++++ > Lib/unittest/test/testmock/testpatch.py | 1652 +++++++ > Lib/unittest/test/testmock/testsentinel.py | 28 + > Lib/unittest/test/testmock/testwith.py | 176 + > 11 files changed, 6682 insertions(+), 0 deletions(-) I hope we also get some Dock/ ;) Georg

7 8

[RELEASED] Second release candidates for Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3
by Benjamin Peterson 19 Mar '12

19 Mar '12

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 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

1 0

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

18 Mar '12

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 | ncoghlan(a)gmail.com | Brisbane, Australia

1 0

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

18 Mar '12

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 you merge >> 2.6 into 2.7, at which point it becomes an inactive branch head. > > The plus side to this concept of tags as entries in a file is that it’s > trivial to add the missing 2.6 tags in the 2.7 branch. > > 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.) I don't understand that argument: especially when there is no change in the tree between the two tags. Georg

1 0

Re: [Python-Dev] [Python-checkins] cpython (2.6): Added tag v2.6.8rc2 for changeset bd9e1a02e3e3
by Barry Warsaw 18 Mar '12

18 Mar '12

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, which changeset do they get? I guess the last one... maybe? >This problem in the future can be avoided by merging all changesets from >X.Y to X.Y+1, not null-merging, unless I misunderstand something. Except in this case, there's probably not much useful in the 2.6.8 changes that are appropriate for 2.7. -Barry

1 0

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

17 Mar '12

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 when null merging 2.6->2.7. Actually, that probably applies to all forward merges, so I think this would be useful information for either the devguide or PEP 101, or both. I updated the latter right at the --tag step. Thanks, -Barry

1 0