As you may have read in a previous post, we've loosened up and now support and fund sprints of just about any kind. PyPy took advantage of this almost immediately for their sprint in Switzerland, and we got two more sprints scheduled right behind them. This is awesome, and we're hoping more sprints keep rolling in. This is great not only for Python, but for the groups doing the work.
Since then we've been busy drumming up ideas for this group, for PyCon (you should go), and for all of this east coast snow, but we haven't forgotten to update our Call for Applications which we said we'd do. The update formalizes what we've been leading up to: we'll fund any Python-related sprint. Want to work on Stackless? Go for it. Does the buzz around Pyramid interest you? Go help them out, we got you.
Oh, and another thing you might like: we raised the amount we can fund up to $300 per sprint. That's up from our previous amount of $250. As with before, you can use it for anything from buying pizzas to renting a meeting space. Do some of your users have to travel to get to meetings? Throw them a few bucks to cover their ride. Whatever it takes to get your group together, we want to make it happen.
We're happy to announce another sponsored sprint, this time at Software Carpentry in July 2011! Full details aren't yet available, but previous events have been held at Univeristy of Toronto and University of Alberta.
Software Carpentry is about educating scientists and engineers on various software related skills such as version control, databases, testing, and of course, Python. Greg Wilson and company are planning a five-day "train the trainers" workshop at SC and plan to follow it up with a two-day sprint. Some of their goals include contributing to the standard and third-party libraries used during the course, e.g., NumPy and PyGame, along with working up extended examples targeted at their scientific crowd.
If you are hosting a Python sprint and are interested in funding, send us an email at firstname.lastname@example.org.
It looks like the widening of our scope worked. The next sprint will be coming from Ghana as part of the Python African Tour on the 18th through 22nd of January, 2011.
This is really exciting because it's different than anything we've sponsored yet. It's kind of like a mini-conference that the group has been doing for the last few years. Two years ago they met in Rabat, Morocco, then Dakar, Senegal, and lastly Abuja, Nigeria this past summer. They plan to have three days of tutorials on Python, Django, and SciPy, followed by a two-day sprint on those topics and more.
We'd love to sponsor more events, especially ones like this, so contact us!
We're happy to announce the sponsorship of the PyPy Winter Sprint! The crew is getting together in Leysin, Switzerland from the 16th through the 22nd of January, and given their usual achievments and a week spent together, we're sure they are going to put together some great stuff.
Plans for the sprint include work on their "fast-foward" branch, which brings their level of support up to Python 2.7 (they are jumping over 2.6). As usual, various parts of the JIT are scheduled to get attention as well, including a JIT backend for ARM. Along with the coding fun, there's also winter fun: they plan to take a day for skiing.
We hear they are also putting together a group dinner on one of the nights. Gotta feed the snake to make it faster.
More details on their mailing list.
As always, contact us at email@example.com if you're planning a sprint.
We're very pleased to announce a change in the "PSF Sprints" charter which will allow us to better serve, and help, the Python Community as a whole.
We initially set out with the goal to start with a simple target - improving the "core" of Python via targeted sprints. These sprints would be focused on core documentation, bug fixes/triage, porting of libraries to Python 3, etc.
However, in the last few months the sprints team as a whole has realized that fundamentally - Python would not be where it is without the Python ecosystem as a whole (outside of core). Everything from multiple virtual machines, web frameworks, libraries that go ping - everything in the community is important to the future of Python as a whole. We wouldn't be here writing this post and rallying people together if it weren't for this ecosystem -- an ecosystem which needs support just as much support as Python itself.
Therefore, we are happy to announce that starting immediately, the charter of the project has been changed (via a board vote) to allow us to fund any Python related sprint. This means Django Sprints, PyPy sprints, Stackless sprints, learning Python or learning Twisted style sprints - all applications will be accepted (they will still go through an approval process, obviously).
If you're working on something that makes Python better for everyone, we want to help. We can reimburse your sprint group up to $250 USD to cover some of your expenses, from buying lunch to paying for train tickets.
The PyPy developers have gotten together a few times this year to sprint, most recently at the University of Düsseldorf. We'd love to chip in for their next sprint and see what kind of awesome stuff they can come up with once again. IronPython recently had a changing of the guard, so it would be great to see some users get together and turn into contributors.
Groups like Montréal-Python never seem to stop sprinting. These guys and girls have done a ton of sprints this year and they aren't stopping yet. Django, like many other web frameworks, is very important to the Python ecosystem, and we'd like to extend our services to those working on Django or any other framework out there.
If you are organizing a sprint relating to Python, let us know at firstname.lastname@example.org and we'll see what we can do.
p.s. We'll be following up shortly with a post where we introduce the updated Call For Applications. PyCon work kept us very busy the last few weeks so it took a while to get this news out there. Oh, yeah, PyCon "Early Bird" registration is open. Hurry, the rates go up January 17, and registration is capped at 1500 attendees.
Just a quick note: As we previously mentioned, Python bug weekend is rapidly approaching. Yep, it's this weekend, November 20 and 21. If you act fast, there's still time to make arrangements to fund your bug weekend sprints with up to $250 USD.
I just heard that the NYCPython and DCPython groups are putting on sprints of their own this weekend, here and here, respectively. Rodrigo from the Sao Paolo Python Users Group just informed me that they are also sprinting. You should follow their lead -- round up your friends, power up your laptops, check out the bug tracker, and hack away.
If you're hosting a sprint this weekend or any other time, let us know at email@example.com.
As Python 3.2 nears release, the python-dev team has organized a Bug Weekend, November 20-21, to follow up the release of the first beta. The primary goal of the weekend is to polish the 3.2 codebase by fixing as many bugs as possible, and the team invites everyone to get involved. Sounds like a perfect time to organize a sprint in your area!
This is a great time for Python users of any skill level to get involved in the development of Python itself. Most of the core developers hang out in #python-dev on freenode IRC (they even have a web interface) and they are willing to help anyone who wants to give their time to fix Python. There's plenty of work to be done, obviously including a lot of Python code, but also plenty of C code and documentation (using Sphinx) to go around. Check out bugs.python.org to see what needs to be done, especially the issues tagged as easy if you're looking for some good starter bugs.
If you're interested in contributing for Bug Weekend (or any time!), check out our beginners guide to get setup, and read the original announcement. Additionally, run your projects on Python 3.2 and bring up any issues you find!
If you are planning a sprint for Bug Weekend or any other time, let us know at firstname.lastname@example.org. We can subsidize your sprint with up to $250 USD to help you rent a room, buy lunch, fill up on coffee, or whatever helps you help Python.
In case you missed it, the Cape Town Python Users Group recently did a sprint to port Genshi to Python 3. Their experience is a great example of what a group can complete when it comes to porting, and it's something we'd love to support more of. Do you have a module or package holding you up from switching to Python 3? Get a group together and let us know at email@example.com, we'd be happy to fund your efforts.
Additionally, we'd like to supplement your porting work with yet another guide: The Python Sprints Porting Guide. As with the core development guide, it's still in progress but covers a significant amount of material so far. Much of the guide is written using notes from a recent porting effort, but also borrows from a number of the existing Python 3 porting resources listed here. There are some obvious holes that we need to fill, so if you're interested in helping out, we'd love it.
The guide is written with the intent that you can easily find topics that affect you, then get one or more solutions. For example, the most commonly discussed 3.x change is moving print from a statement to a function, which we cover here. Thanks to the __future__ module, users of recent 2.x versions can make a very simple transition to print-as-a-function. However, if you support versions of Python prior to 2.6, we show how you can effectively "print" across older 2.x versions and 3.x at the same time via sys.stdout.
There's also a section on porting strategies which could use a little help from those who have gone through this. We cover the idea of having a mixed-version source, as well as 2.x or 3.x plus the use of an automated conversion. Tools like six, 2to3, and 3to2 are helpful in this area so we briefly introduce each of them.
The next guide we're working on is for porting C extensions. If you have any input from your own extension porting efforts, let us know!
I'm pleased to announce the addition of a new donor to the PSF sprint initiative: Trading Technologies from Chicago, IL, USA!
Commonly referred to as "TT", they develop both desktop and server products on Windows for trading on the world's financial markets. Although their products are written C++, Python has a huge presence inside TT, especially in their quality engineering group.
Starting with a single developer writing test tools for a trade database, TT's Python user base grew to 15 in fairly short order. Their application of Python includes heavy use of multiprocessing, Boost.Python and Python's C API, and a domain specific language for creating test suites. Additionally, a number of test management tools are written in Python, from handling VMWare deployment to test result storage and display. There are even teams using Python 3 exclusively!
TT has gotten incredible value from Python and wants to thank and support the efforts of those working to make it even better.
If you or your company are interested in donating, contact firstname.lastname@example.org.
As originally announced, we here at the sprint group are coming up with a number of guides to aid the efforts of sprint participants, especially those who are interested in the development of Python itself.
There can be many barriers to entry when it comes to working with free software projects such as Python, but the Beginners Guide to Python Core Development tries to get you up and running as quick as possible. It includes a number of helpful tips to maximize your contributions and minimize common roadblocks that new contributors face.
The guide contains not only the steps to get your own build running, but gives you some helpful hints to consider while preparing your work for submission to the Python team. If you've ever had a patch shot down, don't worry, we cover why that might have happened and give you tips on creating patches the Python core developers are looking for. Did you consider PEP-8 while coding up your next great feature? Are you aware of the emphasis on code review in Python development? How about the importance of accurate reporting on bugs.python.org? The guide provides a number of helpful hints to newcomers, with the goal of helping everyone make the transition from user to contributor.
As with any work we do, it's open to suggestion...especially the Mac/Linux tool setup (written by a Windows guy :). If you have any comments or corrections, feel free to post them. If you are interested in helping with the guides themselves, we'd love your help.
Awesome Sprint report from Simon Cross:
Nine of us gathered at the Yola offices in Cape Town on the morning of September 4th to attempt porting Genshi to Python 3.
The first hour passed quickly, taken up by exploring the Genshi code base and reading up on others' experiences migrating to Python 3. Various admin tasks -- dishing out repository access and making coffee -- happened in the background.
Once everyone had set up and had some idea of the scope of the task at hand we settled on a two-phase approach. The first phase would be to create a branch that would pass Genshi's test suite under Python 3 but without maintaining compatibility with Python 2. When that was complete we would move on to creating a single codebase that supported both Python 2 and 3, possibly via 2to3.
We kicked off the first phase by running 2to3 and committing the result to the branch. This left us with syntactically valid Python 3 code and a lot of failing tests. The majority of failures resulted from:
- Python 2 strings that needed to be changed to byte strings. - Python 2 AST node handling that needed to be updated. - Unicode string literals in doctest results and inside other string constants that needed to be translated.
We eventually created a custom 2to3 fixer for handling the unicode string literals.
Genshi supports both encoded streams of bytes and unicode strings in its parsers and generators and it handles the two cases quite cleanly but defaults to assuming that input and output are UTF-8 bytes. This made sense for Python 2 where byte strings are the default (or at least one less character to type) but makes less sense for Python 3 where unicode strings are the default. We made a decision to change the Genshi defaults in our port to unicode for both Python 2 and 3 (with the hopes of helping users of Genshi support both Python 2 and 3 more easily in their own code). This API change didn't require changes to the applications we tested against but we haven't tried any particularly large or complex ones yet.
Around dinner time we had a branch that passed the test suite under Python 3 and ran some simple example applications (for the purposes of which we did a very rough port of FormEncode) so we broke for pizza.
Fuelled by pizza and coffee from our Zen-of-Python mugs we dived into stage two. This consisted of grabbing sets of changes from phase one and deciding how best to incorporate them in a unified code base. We settled on a hybrid approach using a combination of running 2to3 from setup.py (via Distribute), a small module of useful compatibility utilities and some "if IS_PYTHON2: ... else: ..." blocks.
We had originally thought we might avoid the use of 2to3 and simply have one codebase but the number of simple cases handled successfully by 2to3 convinced us that including it was worth the slight inconvenience.
Once stage two was under control there was a sub-sprint to port Genshi's C extension module which went surprisingly swiftly and smoothly (a scattering of #ifdefs and it was done).
At around 2:00am on Sunday morning, after roughly fifteen hours of coding, we had a branch that passed the entire test suite under Python 2.4 to 2.6 and under Python 3.1 after applying 2to3 so we declared victory and staggered home.
Of course the sprint is never truly over until the code is committed -- currently the patch has been posted to the Genshi mailing list and discussions are underway to get it included (as is often the case the biggest stumbling block is finding someone with time and commit access :).
The two-stage approach worked well for us, allowing us to concentrate on discovering what changes were needed in the first stage without the overhead of continually running 2to3 or mentally switching between Python 2 and Python 3.
Links to the sprint repository available on the sprint planning page: http://ctpug.org.za/wiki/Meeting20100904.
We've added a new donated site (Yola) in South Africa where sprints can be held - go check out the donated sites page to see if there's a place near you!
I'm pleased to announce another sponsorship we have lined up - this time the Sprints team will be helping to sponsor the AFPY Computer Camp Sprint, lead by Tarek Ziade (see his blog post here). This sprint will be focused on packaging and testing topics and will be happening in Turcey - Burgundy, France
You can see pictures from the last camp Tarek lead here, the PSF Sponsorship money will go to helping pay for the travel for some of the contributors Tarek has lined up to attend.
If you're interested in attending, add your name here - note that space is limited!
The PSF Sprints team is happy to announce we'll be helping to sponsor yet another sprints! The announcement follows:
On the weekend of September 4th, the Cape Town Python Users Group will be sprinting to port Genshi to Python 3. Genshi is the templating engine used by Trac, so porting Genshi is one of the many prerequisites for porting Trac itself.
The local Capetonians will be meeting at the Yola offices in central Cape Town around 10am (8am GMT), but we'll also be hanging out on our IRC channel if those from further afield would like to join in the fun. Anyone with experience in porting C extensions to Python 3 would be particularly welcome.
More details available on the sprint planning page.
This year, PyOhio (July 31 - August 3, Columbus, OH) includes two evenings and two full days of sprints, including a Python Core sprint. The core sprint is part of an integrated program (http://www.pyohio.org/Contribute) to recruit new core contributors at the conference, train them, and get them started working in a mentored environment... all in one four-day event.
PyOhio is a free annual conference on all aspects of Python development. We hope to see you there!
I've just added the "Locations" page to the upper nav bar - this page includes people and/or companies whom have offered up space for sprints. This is a great way to "help the cause" if you or your company/organization have space which could be used by potential sprinters.
Contact email@example.com if you have space you wouldn't mind sprinters asking to use if they need it!
From Michael Foord: This year EuroPython had an amazing turnout for the sprints. On the first day we had 83 sprinters and more than half of them stayed through for the second day. People were sprinting on PyPy, Plone, csp (a form of concurrency and a hot topic during the conference) and a whole host of topics - but of particular interest here is the core Python sprint.
There were around twenty five people in the core-sprint room, here's a photo from the first day:
Core developers present included me (Michael Foord), Ezio Melotti, Georg Brandl, Martin von Loewis, Mark Dickinson, Ronald Ousseron, Richard Jones, Steve Holden, Steven Bethard, and Brett Cannon. My apologies to anyone I have missed out, but there were a lot of people there! Other Python luminaries like Dr Ali Afshar, Armin Ronacher, and Nicholas Tollervey joined us as well.
During the conference Ezio Melotti gave a talk on contributing to Python development. Several of the folk who turned up were new to Python development and had been inspired by Ezio's talk. Here's a quote from one of the sprinters:
"Ezio Melotti followed after the break with a useful overview of the Python development process, which inspired me to join the Python Core sprint on Friday. I’ve already contributed my first couple of patches to Python 3.2 – the first of which has been committed to trunk already. "
Dr Brett Cannon gave an introductory talk and collected contributor agreements from the sprinters. Ezio and Brett worked together with the new sprinters on improving test coverage. There were quite a few patches committed during the sprint towards this end. Dmitry of Jetbrains looked at testing the nntplib for Python 3, only to discover that it wasn't correctly handling bytes / strings. He produced a patch to fix this.
Other sprinters worked on a range of different topics. I started a prototype of a plugin system for unittest which is nearly ready to be announced and discussed to iron the wrinkles out of it. Mark Dickinson spent his time learning about the Mercurial API and hooks mechanisms in order to start developing the commit hooks that Python will need when it transitions to Mercurial.
Richard Jones worked on tests for the smtpd module which had no direct tests. He also added various new features to the PyPI web interface, including a new JSON rpc interface.
Martin von Loewis summarised his work during the sprints:
"I worked on PyPI (the Cheese Shop). I added support for running it locally with sqlite, and added some demo data. I also started on implementing a mirror on AppEngine. I then also resolved a few bug reports and support requests. "
The changes Martin and Richard Jones made to PyPI were summarized on the catalog-sig:
- There is now a way to request release information in JSON (see http://tinyurl.com/38lefsp)
- It's possible to run the code base locally using sqlite (see the README)
- There is now demodata available (see README); people won't need a full database dump anymore to develop on the code.
- In addition, pypi.appspot.com is likely to become mirror E (perhaps B instead, so that E can have an A record).
Ezio Melotti did a lot of work on improving the Python bug tracker, a continuation of what he has been doing for google summer of code. He fixed and/or worked on:
Georg Brandl worked on Sphinx and also with Martin. He provided this summary of what he did:
- Prepared and finished Sphinx 1.0 release, switched Python trunk to use it.
- Got PyPI running locally, fixed 3-4 minor tracker items and the broken setup.py register.
- Worked on pdb issues (none committed yet though).
Ronald Ousseron worked on a host of minor issues, mainly but not exclusively Mac OS X related issues. Steven Bethard was only around for the first day and spent most of it transferring issues from the old argparse issue tracker onto the Python issue tracker. He is notable as being the only sprinter who actively increased the number of open issues rather than reducing them.
Łukasz Langa was another sprinter new to Python development who had his first patches to Python accepted during the sprint. Since the sprint he has continued to work on Python, in particular fixing bugs and adding new functionality to the configparser module.
This sprint was particularly successful as not only did many issues get closed and patches committed, but several new contributors were inspired to work on core-Python.
Just a reminder - we've got a call for applications going on right now! Actually, consider this a standing one for as long as this project has funding. If you have a sprint you're considering holding in the next few months, and want/need some sponsorship, please - drop us an application!
We've already funded one sprint - and we have another one coming this week. We want to hear from everyone, even if you're just asking the question "Should I hold a sprint?".
We will be putting up pages on how/where/what to donate, as well as a page containing information on organizations or companies which have generously offered sprint spaces.
So - drop us a line! We look forward to hearing from you.
On behalf of the sprints team, I'd like to announce our second sponsored sprint - this time at EuroPython in Birmingham UK July 22nd through the 24th. Michael Foord (fuzzyman) sent us the application - they had already planned on having a "Python Core" sprint, with the rooms supplied by EuroPython. Our sponsorship will go towards other things such as refreshments and food for the participants.
A sampling of those who will be in attendance - Michael Foord, Ronald Ousseron, Georg Brandl, Brett Cannon, Ezio Melotti, Mark Dickinson, Tim Golden and more.
The primary focus of the sprint - beyond general core "things" according to Michael is the migration of Python-Core to mercurial - something long on the to do and wish list of python core. Here's the quote from Michael's application:
We would like to make the mercurial transition the focus of the sprint. At the very least coming out of the sprint with a clear idea (specific list) of what needs to be done.
During the conference both Brett Cannon and Martin von Loewis will be present, so we have a good opportunity to discuss this during the language summit and come away from that with some clear "todos". Ezio Melotti will also be working on roundup -> mercurial integration.
If we have a lot of "beginner" (non-core) sprinters then we will make "how to fix a Python bug", including the whole process from bug tracker to fix, the focus for these people.
This sounds like an awesome place to get introduced to everything you could possibly want to know about core - I know that personally my first Python-Core sprint at Pycon in the US sticks in my mind to this day as a major highlight.
So, if you're going to be at EuroPython - and you're staying for the sprints - drop on in! If you hadn't planned on staying for the sprints - please do! They're an awesome time, and help everyone learn and grow and get awesome things done.
You can also see, on the right hand side bar - we've added a Google Calendar with entries for this sprint, and we hope to be adding more. If you have an upcoming sprint or hackfest, and you want us to write a post to help advertise or add it to the calendar - even if we're not sponsoring it - drop us an email.