Skip to main content

Python Contributor!

I'm rather proud to report that my first contribution to the Python code base has been committed in changeset 80421. To aid in my nostalgia I'm going to discuss what I did and why.

It started a long time ago, I think this post by Jesse Noller inspired me. A new mailing list was set up to encourage more core development, the aim was to get new contributors to the Python codebase. At the same time the Python developers guide was  heavily edited and was made available at

The call was put out for simple contributions - documentation, examples, improving testing coverage for the standard library and relatively easy beginner tasks to become familiar with the development process.

Using a coverage tool written by Ned Batchelder I generated a list of test coverage for each standard library module. After looking down the list of modules with low test coverage I decided to tackle functools. This was a good trade off in terms of its test coverage was really low (~30%), and personal interest as its a module that I regularly use.
The functools module is for higher-order functions: functions that act on or return other functions. In general, any callable object can be treated as a function for the purposes of this module.
After a look though the source code it appeared the coverage is so low because a function that is implemented in Python get unconditionally replaced with a C equivalent (if present). There were others functions implemented in C that could have been written in pure Python as well.

Modifying the functools module slightly and creating a few more tests was relatively straight forward. I created an issue on Python's bug tracker: and uploaded my patch.

I emailed the core mentorship mailing list to get advice with one design decision and received awesome replies from some core developers that I highly respect; Nick Coghlan, Raymond Hettinger, Antoine Pitrou, √Čric Araujo and Ezio Melotti all went out of their way to help. There was a little bit of debate over the changes and the review cycle went around five times over the course of a year.

I must admit I was surprised by how long it would take for feedback after I uploaded a new revision of the patch. At my work code reviews are rather highly prioritized, although I understand the nature of open source means people will contribute their time where and when they want. Code coverage patches don't really feature highly on most peoples interests, although I think it helped that I had emailed the core mentorship group - at least some people were aware it would be my first contribution.

That said I use Python so much and really wanted to get involved. My itch wasn't a particular issue - I wasn't passionate about the test coverage but rather I just wanted to give something back. Sure I've been using and promoting javascript more and more recently but Python will always be my language in a time of need.

Popular posts from this blog

My setup for downloading & streaming movies and tv

I recently signed up for Netflix and am retiring my headless home media pc. This blog will have to serve as its obituary. The box spent about half of its life running FreeNAS, and half running Archlinux. I’ll briefly talk about my experience with FreeNAS, the migration, and then I’ll get to the robust setup I ended up with.

The machine itself cost around $1000 in 2014. Powered by an AMD A4-7300 3.8GHz cpu with 8GB of memory. A SilverStone DS380 case is both functional, quiet and looks great. The hard drives have been updated over the last two years until it had a full compliment of 6 WD Green 4TiB drives - all spinning bits of metal though.

Initially I had the BSD based FreeNAS operating system installed. I had a single hard drive in its own ZFS pool for TV and Movies, and a second ZFS pool comprised of 5 hard drives for documents and photos.

FreeNAS is straight forward to use and setup, provided you only want to do things supported out of the box or by plugins. Each plugin is install…

Driveby contribution to Python Cryptography

While at PyConAU 2016 I attended the Monday sprints and spent some time looking at a proposed feature I hoped would soon be part of cryptography. As most readers of this blog will know, cryptography is a very respected project within the Python ecosystem and it was an interesting experience to see how such a prominent open source project handles contributions and reviews.

The feature in question is the Diffie-Hellman Key Exchange algorithm used in many cryptography applications. Diffie-Helman Key Exchange is a way of generating a shared secret between two parties where the secret can't be determined by an eavesdropper observing the communication. DHE is extremely common - it is one of the primary methods used to provide "perfect forward secrecy" every time you initiate a TLS connection to an HTTPS website. Mathematically it is extremely elegant and the inventors were the recipients of the 2015 Turing award.

I wanted to write about this particular contribution because man…

Python, Virtualenv and Docker

Unsurprisingly I use some very popular Scientific Python packages like Numpy, Scipy and Scikit Learn. These packages don't get on that well with virtualenv and pip as they take a lot of external dependencies to build. These dependencies can be optional libraries like libblas and libatlas which if present will make Numpy run faster, or required dependencies like a fortran compiler.

Back in the good old days you wouldn't pin all your dependency versions down and you'd end up with a precarious mix of apt-get installed and pip installed packages. Working with other developers, especially on different operating system update schedules could be a pain. It was time to update your project when it breaks because of a dependency upgraded by the operating system.

Does virtualenv fully solve this? No, not when you have hard requirements on the binaries that must be installed at a system level.

Docker being at a lower level gives you much more control without adding too much extra comp…