...and I'm pretty happy about that.
Most Python developers have written at least one tool, script,
library or framework that others would find useful. My goal in this article
is to make the process of open-sourcing existing Python code as clear
and painless as possible. And I don't simply mean, "create GitHub repo,
git push, post on Reddit, and call it a day." By the end of this article,
you'll be able to take an existing code base and transform it into an open source
project that encourages both use and contribution.
While every project is different, there are some parts of the process of open-sourcing existing code that are common to all Python projects. In the vein of another popular series I've written, "Starting a Django Project The Right Way," I'll outline the steps I've found to be necessary when open-sourcing a Python project.
There is an activity I enjoy more than any other. My profession is based on it, as are most of my hobbies. Creation. I love to make things that didn't previously exist. The fact that I can do this at all fascinates me.
Most of my creations are software. They are the result of both planning and execution. Oftentimes, my software creations must be explicitly released. Simply creating is not enough. I must take concrete steps to make my creation available to the world. In some cases, my creations must be looked after and managed in some way, requiring ongoing care.
When you're in the creation business, the release process for a creation is important. Especially when the creation will be integrated into existing systems, ensuring those systems are ready to handle the new creation is vital. A premature release on unsuspecting systems may have negative consequences.
At work on Friday, I found myself wishing there was a simple way to automatically generate a HATEOAS-based service with a REST API from an existing database. I've lost count of the number of times I've "decided" to build a REST API for a legacy database only to give up when I realized just how much boilerplate ORM code I'd need to write.
One of the first long-form articles I ever posted to this blog was a piece about Python's Global Interpreter Lock (GIL) entitled "Python's Hardest Problem". Two weeks ago, it was posted to Hacker News and sat on the front page for a while, driving a lot of traffic to the blog.
In the discussion on Hacker News, some commenters mentioned that I had neglected
to mention the various ways of working around the GIL. While that information
didn't fit the purpose of the original article, it is nonetheless useful.
In this article, I'll describe the various ways the Python community has
discovered/created to mitigate the effects of the
GIL. I hope this information
is helpful to those who want practical advice for how to take advantage of
concurrency in Python.