python-committers March 2013

python-committers@python.org

33 participants
12 discussions

Please don't commit to 3.2 branch anymore
by Georg Brandl 31 Mar '13

31 Mar '13

Hi all, with 3.2.4 being the last regular 3.2 maintenance release and the rc out of the door, the 3.2 branch should only be committed to for security releases. So please don't commit anything there anymore. To help everyone remember, I've configured the push hook to reject changesets to the 3.2 branch. cheers, Georg

9 15

SSH fingerprint
by Roger Serwy 26 Mar '13

26 Mar '13

Hi All, What should be the ssh fingerprint be for hg.python.org? I am receiving 63:75:9b:14:b7:b2:dc:e7:cd:42:d7:19:48:6a:68:8e, but I can't verify if it's correct. Thank you, Roger

10 21

[RELEASED] Python 3.2.4 rc 1 and Python 3.3.1 rc 1
by Georg Brandl 25 Mar '13

25 Mar '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team, I am pleased to announce the first release candidates of Python 3.2.4 and 3.3.1. Python 3.2.4 will be the last regular maintenance release for the Python 3.2 series, while Python 3.3.1 is the first maintenance release for the 3.3 series. Both releases include hundreds of bugfixes. There has recently been a lot of discussion about XML-based denial of service attacks. Specifically, certain XML files can cause XML parsers, including ones in the Python stdlib, to consume gigabytes of RAM and swamp the CPU. These releases do not include any changes in Python XML code to address these issues. Interested parties should examine the defusedxml package on PyPI: https://pypi.python.org/pypi/defusedxml These are testing releases: Please consider trying them with your code and reporting any bugs you may notice to: http://bugs.python.org/ To download Python 3.2.4 or Python 3.3.1, visit: http://www.python.org/download/releases/3.2.4/ or http://www.python.org/download/releases/3.3.1/ respectively. Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and all contributors) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlFRRIoACgkQN9GcIYhpnLD6jACgnzYdYRKZ4kwkKeN3zSLSZ3Zr M/IAn17vlpxI3a3xk+i/ODOrCkMnRZro =B5sA -----END PGP SIGNATURE-----

1 0

2.7.4rc1 tagged
by Benjamin Peterson 23 Mar '13

23 Mar '13

The 2.7.4rc1 tag is in the main hg repo. -- Regards, Benjamin

1 0

Commit privileges for Roger Serwy for IDLE
by Ned Deily 21 Mar '13

21 Mar '13

I would like to propose Roger Serwy be given commit privileges to work on IDLE. Roger has demonstrated long-term interest in IDLE and has been contributing to IDLE in a number of ways for years. He has submitted many patches for IDLE to the tracker since at least April 2008. He has developed a number of IDLE extensions (http://idlex.sourceforge.net), some of which he has proposed for inclusion in the standard library. He is also active in triaging and commenting on the bug tracker and has had developer privileges on the tracker for the past 12 months. He has also already signed the contributor agreement and I know he has been interested in becoming a core developer for IDLE. I've informally discussed this with a few other core developers here at PyCon and I think there is general agreement that having Roger be able to contribute more directly to IDLE would be a really good thing. I would certainly be willing to help mentor him as necessary. -- Ned Deily, nad(a)acm.org

13 20

Re: [python-committers] [Infrastructure] test suite dependencies on www.python.org
by Trent Nelson 20 Mar '13

20 Mar '13

On Wed, Mar 20, 2013 at 12:47:09PM -0700, Noah Kantrowitz wrote: > > On Mar 20, 2013, at 12:44 PM, Martin v. Löwis wrote: > > > Am 20.03.13 04:27, schrieb R. David Murray: > >> Example: > >> > >> request = > >> urllib.request.Request("http://www.python.org/~jeremy/") > >> > >> And then there are things like: > >> > >> h = client.HTTPSConnection('svn.python.org', 443, > >> context=context) > >> > >> I don't think there are a huge number of these, but we will need to > >> deal with them. > > > > In the past, we just let them break and then fix the test case, > > which is not the best solution, but also not overly tragic (IMO). > > > > Note that the redesign project includes an objective of URL > > stability. The test suite is here of least concern, as there are > > thousands of incoming links to various pages. These need to be > > preserved as much as feasible (possibly using redirects). > > +1 on let them break, but when they get fixed it should be against a > dedicated testing endpoint if possible, preferably something internal > to the test suite. Maybe spawn an HTTP server in a background > thread/proc? I would very much like the web infra to not be a runtime > dependency if possible. FWIW, that approach isn't possible in all cases. Perfect example was http://bugs.python.org/issue15285, which required very specific TCP/IP behavior (specifically with regards to RST) that you simply can't simulate easily on a localhost. I set up two services, blackhole and whitehole.snakebite.net, that have been fulfilling this need for the past ~10 months now. Relevant blurb below: def testConnectTimeout(self): # Testing connect timeout is tricky: we need to have IP connectivity # to a host that silently drops our packets. We can't simulate this # from Python because it's a function of the underlying TCP/IP stack. # So, the following Snakebite host has been defined: blackhole = ('blackhole.snakebite.net', 56666) # Blackhole has been configured to silently drop any incoming packets. # No RSTs (for TCP) or ICMP UNREACH (for UDP/ICMP) will be sent back # to hosts that attempt to connect to this address: which is exactly # what we need to confidently test connect timeout. # However, we want to prevent false positives. It's not unreasonable # to expect certain hosts may not be able to reach the blackhole, due # to firewalling or general network configuration. In order to improve # our confidence in testing the blackhole, a corresponding 'whitehole' # has also been set up using one port higher: whitehole = ('whitehole.snakebite.net', 56667) # This address has been configured to immediately drop any incoming # packets as well, but it does it respectfully with regards to the # incoming protocol. RSTs are sent for TCP packets, and ICMP UNREACH # is sent for UDP/ICMP packets. This means our attempts to connect to # it should be met immediately with ECONNREFUSED. The test case has # been structured around this premise: if we get an ECONNREFUSED from # the whitehole, we proceed with testing connect timeout against the # blackhole. If we don't, we skip the test (with a message about not # getting the required RST from the whitehole within the required # timeframe). # For the records, the whitehole/blackhole configuration has been set # up using the 'pf' firewall (available on BSDs), using the following: # # ext_if="bge0" # # blackhole_ip="35.8.247.6" # whitehole_ip="35.8.247.6" # blackhole_port="56666" # whitehole_port="56667" # # block return in log quick on $ext_if proto { tcp udp } \ # from any to $whitehole_ip port $whitehole_port # block drop in log quick on $ext_if proto { tcp udp } \ # from any to $blackhole_ip port $blackhole_port # Regards, Trent.

1 0

Re: [python-committers] [Infrastructure] test suite dependencies on www.python.org
by R. David Murray 20 Mar '13

20 Mar '13

On Wed, 20 Mar 2013 12:47:09 -0700, Noah Kantrowitz <noah(a)coderanger.net> wrote: > +1 on let them break, but when they get fixed it should be against a > dedicated testing endpoint if possible, preferably something internal > to the test suite. Maybe spawn an HTTP server in a background > thread/proc? I would very much like the web infra to not be a runtime > dependency if possible. Keep in mind that it isn't only us running the test suite; but, yeah, this is what we've done in the past. Just don't do the cutover near when one of the release managers is trying to produce a release :) We've been converting tests to use internal services as we've noticed them for one reason or another, and when possible. The example I quoted should be converted. There are tests that we don't have the infrastructure to move into the test harness, but I don't think any of the ones that reference www.python.org should be among those at this point. --David

1 0

Re: [python-committers] [Infrastructure] test suite dependencies on www.python.org
by R. David Murray 20 Mar '13

20 Mar '13

On Mon, 18 Mar 2013 15:17:23 -0700, Noah Kantrowitz <noah(a)coderanger.net> wrote: > As part of the PyCon sprints I would like to move python.org off > dinsdale to a VM at OSL. Due to the build system being tied to SVN, > I'll also migrate that service on the same VM. Do any SVN repos other > than www/ need to remain available? This would require at least some > period of not changing the website, probably a few hours, but I don't > think that would be a problem. This is mostly a legacy move so I'm not > going to clean it up much, we'll have a new site soon enough. While working on tests at the sprint I was reminded that there are various tests in the Python standard library that depend on resources in specific resources in specific locations at python.org. We will need a plan for finding and dealing with these before (or as?) the new web site is turned up. Example: request = urllib.request.Request("http://www.python.org/~jeremy/") And then there are things like: h = client.HTTPSConnection('svn.python.org', 443, context=context) I don't think there are a huge number of these, but we will need to deal with them. --David

3 2

PyCon US 2013 attendees
by Chris Jerdonek 16 Mar '13

16 Mar '13

Is the attendee list for next March's PyCon available to registrants? What core developers are attending? Maybe members of this list that are going can reply to this e-mail, or someone more familiar with the speaker list can at least start the list off. I'm attending. Thanks, --Chris

19 28

Tracker settings for Peter Moody
by Nick Coghlan 16 Mar '13

16 Mar '13

Could someone with sufficient privileges please flip Peter Moody's commit bit in the tracker: http://bugs.python.org/user9293 Reminder to everyone else: if you have commit privileges, but don't have the Python logo showing up next to your name on bugs.python.org (and have "Is Committer: No" in your user profile), we missed a step when granting you commit access, and it needs to be fixed so you appear in the "Assigned To" dropdown properly. (the "nosy" magic draws from the experts index instead, so it can work even if this setting is wrong) Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

4 3

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-committers March 2013