Something has been making me restless lately. Maybe it’s the periodic need to shake things up; maybe it’s the growing sense that I may be getting a little parochial in the Microsoft-centric alternative reality that I’ve lived in for the past 15 years or so; maybe it’s simply indigestion. Whatever the reason, I’ve been looking for a high-level language to add to my tool kit that is expressive, flexible, reliable, reasonably fast, and not strictly tied to Windows and Microsoft –nor, on the other hand, to a knee-jerk anti-Microsoft bias, either. And I think I may have found it in Python.
A useful language is more than just a particular syntax and vocabulary; it’s more than an ability to express your software ideas and execute them quickly enough. It’s also an ecosystem. There has to be reasonably wide adoption, a fairly healthy user community, and a steady supply of libraries, plug-ins, add-ons and frameworks in the pipeline. At the same time, there needs to be cohesiveness — community interest needs to be coalescing around some tools and libraries and conventions that are clear winners.
SmallTalk has always appealed to me in theory, but the reference implementations seem to be hell-bent on hiding behind some pathologically non-standard GUI so that your programs will make your users go “huh?!” no matter what OS they prefer.
PHP has wide adoption and I even sling a bit of it, working on the side with WordPress. But it’s crufty, showing its age. Its object model seems bolted on.
Ruby has promise, but there’s an air of intellectual arrogance and True Believerism to its user community that turns me off.
Python seems to hit a sweet spot for me, enough at least that I’m in the process of buying books, and sorting out my learning entry point. A general purpose Python program is capable of running on Windows, Mac OS/X or Linux with little or no change — and that includes GUI apps. It’s a great language for the web server and some popular web development and CRM frameworks make use of it.
Python is compiled to an intermediate bytecode format by the interpreter; it can be precompiled as well, but unlike .NET applications, the bytecode doesn’t masquerade as an executable.
Most interestingly to me as someone who earns his bread and butter from Microsoft development platforms, Python is not afraid of .NET. With the appropriate library, you can consume .NET class libraries; if you wish, you can even run Python directly on under .NET using Iron Python, which is a very active project on CodePlex that is, as I write this, in release candidate status and should be RTM by the end of this year.
For someone like myself approaching Python seriously for the first time, the main question is what version to learn. The venerable Python 2.x releases, particularly 2.5 and 2.6, are the versions of the interpreter installed on most systems.
But Python’s developers have made a necessarily painful and inherently courageous decision with Python 3.x, which is to make some breaking changes to the language itself in order to remove cruft, inconsistencies, and hacks that have accumulated over the years. These changes do things like properly integrate Unicode strings into the language, but they also clear the way for some new capabilities to evolve more naturally.
Python 3.x, sometimes referred to as Python 3000, was released early in 2009 and currently stands at version 3.1. The problem is that a lot of OS distros are still putting 2.5 or 2.6 out there, and satellite projects like Iron Python are still mired in the Python 2.x world. It will take many Python-based products / open source projects / frameworks a year or two to digest Python 3.x.
To that end, a two year moratorium on further language changes has been declared, to give the rest of the community a chance to catch up and synchronize.
To summarize for those who are still confused: the lead team developing Python, the Python Software Foundation, is responsible for what is often referred to as CPython, after the fact that the interpreter is written in C (in contast to Jython, which is written in Java and runs on the Java VM, and Iron Python, which runs on the CLR). CPython is currently at version 3.1 but adoption of 3.x is slowed by breaking changes and most of the Python code base in the world currently runs on CPython 2.4, 2.5 or 2.6 or on sister versions like Iron Python that currently focus on 2.x compatibility. CPython 2.7 will be the last of the 2.x series and within the next year or two existing code bases in active development and maintenance will jump the hurdle to 3.x. One can reasonably expect, unfortunately, that the 2.x code base will hang around for some years to come, but it’s not the happening place any more.
All of this seems well-managed and sensible. I’m going to focus on Python 3.1, figuring that by the time I’m up to speed with it in my copious (ha!) spare time, I will be pretty much in sync with the rest of the Python community. In other words I will start just a bit ahead of the curve.
Will I do Python projects for hire? Likely I will do pieces of things in Python. It has potential to become my prototyping / scripting language of choice, at least for certain things. Politically, in the Wintel world at least, it probably isn’t feasible to do entire projects in Python, unless and until Iron Python becomes a first-class CLR language, meaning that it installs along with C# and VB.NET when you install Visual Studio. Microsoft doesn’t seem ready to back it to that degree; their involvement with Python and Ruby seem to be hedged bets more than strategic moves.
Regardless, though, Python will hopefully stimulate fresh ideas and expose me to a more OS-agnostic and VM-agnostic world. It’s not an accident that I bought a Mac Pro within the past year and have Windows 7 running in a virtual machine there; I’m not about to let the wider software development world pass me by entirely.
I will be posting in more detail about my progress in the weeks and months to come.
