Last month I wrote about knowing why you choose your tools. Rather than just leave it at that, I figured it’d be good for me to demonstrate that process by applying it to my own tools of preference. That said, this month I’ll focus on my programming language of choice.
I don’t make any effort to hide the fact that I love Python. Pretty much anywhere I’m presented with a box in which I’m required to describe myself, the word ‘Pythonista’ shows up. I’ve got lots of reasons for this, both personal and professional, and it would be most useful to talk about the more objective professional reasons.
You have to know where you’re going before you can get there
First of all, I need to start off by figuring out what my requirements are. Remembering the main lesson from last month’s post, you have a harder time talking about how “something is good”, but you can talk about how “something is good for X.” So here are my requirements/usage patterns for my programming language:
- Web development
- General purpose
- Quick development
The majority of work I do is on the web, so whatever language I use must have tools and frameworks available to help me with this. However, although a majority of my work is web, not ALL of it is, so it’d be nice if I could use this language for other things as well. This helps with maintanibility, because having fewer moving parts in your stack makes it easier to manage.
As for quick development: I bill by the hour and I have a busy life, so the faster I can get things out, the more value I provide and the more free time I have. There must be tools that help me prototype quickly, get things done fast, and if I have to change direction, pivot just as quickly.
Python has a ton of stable, mature frameworks for web development. For a larger including-the-kitchen-sink framework, you have Django. For an event-loop based framework built for scaling out concurrent requests, there’s Tornado. For a smaller no-frills web framework, there are things like web.py, Flask, and Bottle. There are generally client libraries to access most everything necessary to run a proper web app. There are high quality connectors for pretty much every database system out there, and access to other tools that provide things like caching or long running backend processes.
As far as a general purpose goes, Python has a lot going for it. The standard library is chock full of tools to handle a variety of tasks and supports a variety of programming paradigms (procedural, object oriented, and functional programming). There is a very high quality image processing library (PIL) and also a library for scientific number crunching (numpy and scipy). GUI applications can also be written in Python, as it has mature bindings for both GTK and QT. In the wild, python has been the language behind web servers, shell scripts, mail routers, client side applications, and many others.
As far as the web goes, the Python frameworks are very good at enabling quick development. For instance, Django provides a lot of bits that are common to most sites (forms, site admin, built-in user and group permissions) and most of them are modular. The framework also promotes reusable apps, modular sections of your app that can be reused in other projects. So if you’ve integrated Facebook comments on one site, you can save that piece of code to use in another project. That way, you don’t have to keep implementing the same thing again the next time around.
Also, most Python frameworks comes with a development server, and tied with the fact that if you use the Django ORM, you can easily switch between different database backends by only changing one line of code. So you can deploy your app using a real database like postgres, and you can work on your local machine using sqlite. So long as you do not stray into any complicated queries (and 99% of the projects I’ve encountered do not) the difference is rather negligible. Thus, you can work on your code pretty much anywhere, by running it all locally, and without impacting your base system by having to install/setup servers and databases.
The ruby frameworks generally have the same advantage. Ruby on Rails and Django are pretty much feature for feature on par with each other. While PHP is generally thought to be more portable than others (due to the fact that it’s ubiquitously supported in all hosting environments) I actually find PHP is harder to make portable. It lacks an equivalent to Python’s virtualenv or Ruby’s rvm, both tools that help manage language versions and package dependencies. Getting up to speed on a new machine with a python project takes around 5 commands (create virtual environment, checkout code, install dependencies, load database fixtures, run dev server), all of which can be basically scripted into one. Things are looking up for PHP though, which as of 5.4 has a built in development server. Previously, getting a development environment on a local machine involved installing apache and mysql and setting those up properly.
It’s not all a bed of roses
Of course, things aren’t perfect in the world of Python. There are lots of disadvantages in choosing Python, but we have to keep in mind our original requirements, and see whether these cons affect those.
The main issue with Python would be speed. While it is generally pretty fast (and the pypy project is looking to speed things up a lot), it can’t hold a candle to the speed of C, Java, or any other compiled language. However, for the purpose of web development, code execution speed is generally not the bottleneck of any application, but rather database access, network and disk IO is what slows down a web site.
Another issue would be the lack of compile time type checking, which can catch problems with your code before you deploy. Of course, this doesn’t mean the lack of any bugs, so you still need robust logging and failover, both of which can be had in a Python deployment. But still, there are some things that a compiler can assist you with, and that’s a major downside to using Python.
At the end, a tool is still a tool
Despite all this, there are times I’ll choose another tool over Python. You should not hold yourself to using one tool, but be comfortable with many. In fact, if the stars had aligned differently I might be a Rubyist – the two languages very similar and for any one project written in Ruby there’s probably a counterpart or port of it in Python, and vice-versa.
Shu is a father, husband, (and if you couldn’t tell yet) Python evangelist and open source enthusiast. He does freelance design and development as one-half of FreelanceDreams LLC.[/author_info]