Open Source is a great way to learn and grow – to look at huge codebases written by world class developers, and to be mentored by them when you try to write a patch for an existing issue. You learn the entire workflow of starting a patch to having it committed to the central source code repository, which can be a very enriching experience. The discussions that accompany the process are also priceless in terms of how much you learn about software development as well as practicality.
Earlier this year I had decided that I would start with contributing to the Python project. Being one of my favorite languages with a vibrant, large and intellectual community (and also increasing industry support – check out the sponsors at PyCon 2013), it was a natural choice. I might decide to get involved with the Scala community at a later point as well – which is fast becoming my other favorite language 🙂 But that story belongs to another blog post.
A lot has been written about how to start contributing to Python here, here, and here. After the idea had been incubating in my subconscious for too long, I decided it was now or never. As a first step, I downloaded and built CPython on a Linux virtual machine, but gave up because of several issues – mostly it was very inconvenient to fire up a virtual machine every time I wanted to do something with the source, and Virtual Box does not really provide the smoothest experience. I decided to build the CPython source on OS X eventually, which also worked without issues.
The official Python bug list is maintained here. A natural first step to starting is to look for some ‘easy’ task – specifically, at the tests that accompany the project under consideration, and to try to refine and enhance them, thereby increasing the test coverage. A lot of people also start with documentation fixes, which is obviously a lot easier than actually trying to take a stab at the code. Furthermore, the parts of Python that are written in Python would probably be easier to handle than the parts that are C. Still, it could be a daunting task to actually find an issue to work on. Luckily for me, I found something between the two extremes -coding and documentation, to get my hands dirty.
The official Python documentation has a lot of example code, and there is a mechanism which automatically tests the code and the results given in the documentation against what actually happens when Python runs that piece of example code. As it turns out, because of several reasons – some legacy, some pedantic, and some errors and omissions – there are a lot of failing test cases for doctest (the automatic mechanism that checks the example code against reality). I found some easy changes to make that fixed some of the issues, and submitted two patches, here and here. The discussions and even the code diffs should be visible publicly, even if you do not have an account on the bug list.
The community has been great, very welcoming and very professional. Of course, the next steps are for me to look at the comments made by the core committers on my patches, and enhance the patches themselves until they are good candidates for being accepted to the codebase. A common question that arises is how exactly to bundle the changes, and which changes can be bundled as one patch and which ones should be a patch of their own. Another one is to make sure that the problem that the patch is trying to address is also solved for the different versions of Python – 2.5, 2.6, 2.7, 3.1, 3.2, 3.3 and 3.4 – which, to be very honest, is the only thing I really dislike about Python – the existence of so many flavors concurrently. It also complicates my workflow a little bit – to make sure I have access to all these versions at any given time.
All the same, I am hopeful that these patches will eventually be accepted, and also that eventually I’ll be able to make contributions to the codebase itself which would be more valuable than what I have done so far – which might pave the way to the possibility of becoming a core committer – which is ambitious for me at this stage and depends upon how much time I would have in the near future. Very proud at the prospect of having my name listed along with all the contributors to the Python project!
Ravi Sinha's Weblog 