Mailman 3 January 2013 - Python-Dev

PandaBoard, Raspberry Pi coming to Buildbot fleet
by Brian Curtin Jan. 4, 2013

Jan. 4, 2013

Last week in Raymond's dictionary thread, the topic of ARM came up, along with the relative lack of build slave coverage. Today Trent Nelson received the PandaBoard purchased by the PSF, and a Raspberry Pi should be coming shortly as well. http://blog.python.org/2012/12/pandaboard-raspberry-pi-coming-to.html Thanks to the PSF for purchasing and thanks to Trent for offering to host them in Snakebite!

9 18

Posting frequent spurious changes in bugtracker
by Jesus Cea Jan. 4, 2013

Jan. 4, 2013

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This happens to me very frequently. I get the notification about new issues open in the bugtracker. If I see an interesting "bug", I usually open a Firefox tab with it, to monitor it, decide if I will work on it in the future, whatever. When I have time to decide, I proceed. If I find the issue interesting but don't have the time to work on it, or somebody else is taking care of it, I just add myself to the nosy list, and close the tab. The problem with this is that even if I reload the tab, flags are usually stale and when I add myself to the nosy list, I revert flags to the old value. This happens frequently. Last time: <http://bugs.python.org/issue16833#msg178917> I think tracker should keep a "version" hidden field, and refuse to act if the version on server is different that the just posted changes. Or something. Or am I doing something fundamentally wrong?. I reflesh 99% of the time, but could forget sometimes, and some other times I need a "shift+reload" to bypass browser cache. PS: Tracker tells me about conflicts ocasionally, but most of the time the stale flags are not noticed. - -- Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQCVAwUBUOXi2Zlgi5GaxT1NAQK6ewQAlCv0RKb3/y6tzdjggm4JqOjt0E9vYyZJ o0FIC+KBTrVtWrACiBOKCHPVsvJ1KB+6RzQ4FJdIyeOzG8Kv/E0HUNDufLGjr41C NCd4O8FN0tpHIfJkpC3PbkinyhZpviQL7YindAteb92sa+QFm8Rp+QCKBFRecMUX A7WLf+Gk8pE= =famI -----END PGP SIGNATURE-----

5 6

PyTypeObject type names in Modules/
by Eli Bendersky Jan. 3, 2013

Jan. 3, 2013

Hello and happy 2013, Something I noticed earlier today is that some C versions of stdlib modules define their name similarly to the Python version in their PyTypeObject. Some examples: Decimal, xml.etree's Element. Others prepend an understore, like _pickle.Pickler and many others. What are the tradeoffs involved in this choice? Is there a "right" thing for types that are supposed to be compatible (i.e. the C extension, where available, replaces the Python implementation seamlessly)? I can think of some meanings for pickling. Unpickling looks at the class name to figure out how to unpickle a user-defined object, so this can affect the pickle/unpickle compatibility between the C and Python versions. What else? Eli

3 10

test___all__ polluting sys.modules?
by Eli Bendersky Jan. 3, 2013

Jan. 3, 2013

Hi, This came up while investigating some test-order-dependency failures in issue 16076. test___all__ goes over modules that have `__all__` in them and does 'from <module> import *' on them. This leaves a lot of modules in sys.modules, which may interfere with some tests that do fancy things with sys,modules. In particular, the ElementTree tests have trouble with it because they carefully set up the imports to get the C or the Python version of etree (see issues 15083 and 15075). Would it make sense to save the sys.modules state and restore it in test___all__ so that sys.modules isn't affected by this test? Eli

12 22

hgweb misconfiguration
by Michael Foord Jan. 2, 2013

Jan. 2, 2013

Hey folks, Likely the wrong place to report this, but I couldn't work out the best place and figured this is only as bad as anywhere else. A user has reported to webmaster that hgweb is misconfigured (or at least the server configuration is interfering with hgweb). The symptom is that this url is incorrectly a 404: http://hg.python.org/cpython/file/3.3/Doc/tools/sphinxext/static/version_sw… His diagnosis: >> the web server is misconfigured to serve the hgweb static >> files for any directory named 'static'. It is appropriate for it to do >> this for http://hg.python.org/static/ and maybe even >> http://hg.python.org/cpython/static/ and the other repositories, but >> it is inappropriate for it to serve the hgweb static files within the >> repository contents. What should have happened: The web server passes on the request to hgweb, which notices that it is supposed to retrieve a particular version of a file from the Mercurial repository and show it to the user. This works successfully for URLs not containing '/static/' (ending slash significant), e.g., <http://hg.python.org/cpython/file/3.3/Doc/tools/sphinxext/static>. You can see that hgweb successfully displays the directory listing. However, try adding a slash onto the end of that. The web server picks up '/static/' and takes over the request, listing its static files (rather than letting hgweb display the 'static' directory from the Mercurial repository). The static files shown by the web server's directory listing are used for the user interface of hgweb; for example, the logo <http://hg.python.org/cpython/static/hglogo.png>. It should be serving those static files on <http://hg.python.org/static/> and <http://hg.python.org/repo/static/> (where repo is a repository name like cpython), but it is also serving on <http://hg.python.org/repo/file/.../static/>, which is inappropriate, because it makes it impossible to view version_switch.js and the other files in that directory with the hgweb interface. -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html

1 0

PEPs in progress
by Christian Heimes Jan. 2, 2013

Jan. 2, 2013

Good morning and happy new year! I would like to let you know that I'm working on two new PEPs. The first PEP addresses hash collision attacks as discussed in http://bugs.python.org/issue14621. I'm planing to make the internal string and bytes hash function more secure, pluggable and even faster. DJB's SipHash is part of the plan as well. Users will be able to choose an algorithm on startup and embedders will be able to provide their own hash function, too. The second PEP addresses key derivation functions for secure password hashing. I like to add PBKDF2, bcrypt and scrypt facilities to the standard library. Regards, Christian

3 5

Re: [Python-Dev] cpython (3.3): configparser: preserve section order when using `__setitem__` (issue #16820)
by Antoine Pitrou Jan. 1, 2013

Jan. 1, 2013

On Tue, 1 Jan 2013 22:37:56 +0100 (CET) lukasz.langa <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/f580342b63d8 > changeset: 81205:f580342b63d8 > branch: 3.3 > parent: 81203:b8b5303ac96f > user: Łukasz Langa <lukasz(a)langa.pl> > date: Tue Jan 01 22:33:19 2013 +0100 > summary: > configparser: preserve section order when using `__setitem__` (issue #16820) Would this deserve some NEWS entry? Regards Antoine.

2 1

question about packaging
by Doug Hellmann Jan. 1, 2013

Jan. 1, 2013

A couple of us from the OpenStack project are interested in getting involved in the packaging rewrite/update project. I was following that work for a while, but have lost track of its current state. Can someone point me to the right mailing list, and maybe a status page or something so I can start figuring out where we might be able to help? Thanks, Doug

5 8

Branch ancestry hiccup on the Mercurial repo
by Antoine Pitrou Jan. 1, 2013

Jan. 1, 2013

Hello, For the record, due to a bug in the "hg graft" command, a recent changeset of mine basically merged branch 2.7 into 3.2: $ hg log -r "ee8d999b6e05 or parents(ee8d999b6e05)" -G o changeset: 81129:ee8d999b6e05 |\ branch: 3.2 | | parent: 81124:e4ea38a92c4d | | parent: 81128:3436769a7964 | | user: Antoine Pitrou <solipsis(a)pitrou.net> | | date: Fri Dec 28 19:07:43 2012 +0100 | | summary: Forward port new test for SSLSocket.connect_ex() | | | o changeset: 81128:3436769a7964 | | branch: 2.7 | | user: Antoine Pitrou <solipsis(a)pitrou.net> | | date: Fri Dec 28 19:03:43 2012 +0100 | | summary: Backport Python 3.2 fix for issue #12065, and add another test for SSLSocket.connect_ex(). | | o | changeset: 81124:e4ea38a92c4d | | branch: 3.2 | | parent: 81118:b2cd12690a51 | | user: Serhiy Storchaka <storchaka(a)gmail.com> | | date: Fri Dec 28 09:42:11 2012 +0200 | | summary: Issue #16761: Raise TypeError when int() called with base argument only. | | The first symptoms were reported in http://bz.selenic.com/show_bug.cgi?id=3748 but the actual cause of the issue is http://bz.selenic.com/show_bug.cgi?id=3667. Chances are the problem won't be very annoying in practice, but just FYI. Regards Antoine.

3 2