There’s some kerfluffle in the community for the Python programming language. I would not be among that community; I experimented with Python for a bit, and didn’t hate it, but I also played with Ruby and found it to be more my style - but ultimately went crying back to PHP due to its ease of setup and omnipresence among web hosts. But for others, that’s not an obstacle. To each their own.
Anyway, the contention is about the recent release of the Python 3.0 interpreter. This version of the language breaks backward compatibility bi-directionally; code written for previous versions of the Python interpreter will generally not work with the Python 3.0, and code written for Python 3.0 will not run on previous versions of the interpreter.
The changes in the new version of the language are quite extensive. Many antiquated or redundant libraries were tossed out, and standard 8-bit Python string types were obliterated - all strings are in Unicode now.
The changes are going to mean bajillions of man-hours of labor to convert older codebases to the new system. Many Python-powered web sites use a framework such as Django or Pylons; the substantial codebases of these frameworks are going to have to be rewritten themselves before the sites using them can take advantage of Python 3’s improvements. It’s quite likely that many of these larger projects are going to be maintaining two codebases for a while (just as the Python organization themselves are) - one for Python 2.6 users, and another for Python 3.0 users.
For some, this is ludicrous. Python user Jens Alfke asks, on his blog, “Python 3.0: What’s The Point?” He argues that the improvements to the language are not worth the jarring and rewriting the 3.0 transition is going to cause.
On the other side one James Bennett, who titles his post, “Let’s talk about Python 3.0.” With a humorous story about monkeys, bananas and a fire hose, Bennett makes the argument that Python and its users are going to end up for the best in the end by implementing Python 3.0’s improvements now rather than later.
I see parallels with Drupal. With every major Drupal release, changes to the API mean that modules and templates for the previous version are not likely to work with the current one - and this is happening every eighteen months or so when a new major version of Drupal is released. Many developers have difficulty working with this concept. The result is that, even though Drupal 6 is the current version (its first standard release was in February) and Drupal 7 development is occurring full steam ahead, Drupal’s own main site still frequently showcases on its front page sites built with Drupal 5 - and the Drupal.org site itself is still using Drupal 5. Gradual process in the porting of many frequently-used modules such as Views to Drupal 6 forced many site admins to wait until the modules they depended on were upgraded before taking the plunge. In the [Drupal modules] and themes directory, you will to this day find many projects which do not have Drupal 6 versions available, even in pre-release form - and every once in a while you’ll come across a project which doesn’t even have a Drupal 5 version available, the coder instead going no further than one of the Drupal 4.x releases. It’s aggravating sometimes, and it’s going to all happen again when Drupal 7 is released.
And yes, some people whine and complain that all this updating and breakage is doing more harm than good. But I side with Bennett and those who think of the progress as a feature, not a bug. From a programmer’s perspective, the improvements in Drupal 6 over Drupal 5 are substantial - the menu system is much improved, and the improvements to the templating system are powerful and certainly make life easier. And when Drupal 7 hits, its new database interface is going to be a dream - but all Drupal 6 modules will have to be rewritten to take advantage of it.
But that’s progress. Look at the Mac. The transition from Mac OS 9 to Mac OS X required applications to be rewritten, sometimes substantially. The transition from PowerPC to Intel processors also caused some pain for Mac developers. Next around the bend is the transition to 64-bit codebases, which already has Adobe smarting. But the Mac is incalculably better than it was in the OS 9, PowerPC-only days - and it can keep its svelteness without Classic mode and Rosetta (backwards compatibility tech in OS X to run OS 9 and PowerPC apps, respectively) gunking it up.
Upgrades - and break-ups - can be painful. But life will be better if you do it sooner rather than later. Time to make a clean break, Python users.
