Thoughts on the Evolution of Python (the language)

I’m a fan of Python. I’ve been using Python since the 1.5.2 version. The first time I looked at it, though, I hated it. I thought, what a stupid way to design a language… white space at the beginnings of lines actually has meaning to the program. I didn’t look any further than that, with memories of FORTRAN coding forms dancing in my head.

But then Linux Journal devoted an issue to Python, and Eric Raymond, a fellow I have tremendous respect for, wrote an article on the language. He told me, clearly and elegantly, why I really wanted to be using this language.

So I downloaded and printed out the manuals, and I gave it another try… and I loved it. I found the whitespace thing was a non-issue. Python was at one time elegant and pragmatic, easy to write and easy to read. It’s been called “executable pseudocode,” and for good reason.

I’ve written thousands of lines of Python (which, if you’re familiar with the language, you’ll realize is roughly equal to hundreds of thousands of lines of C), and I can read all those programs easily, even years later.

When 2.0 came out, and 2.1 after it, I liked them. Some of the warts I had found and disliked in the language just evaporated, and the backwards compatibility level was very high. I’ve upgraded to each new version fairly soon after release, up to the 2.6 version. But I noticed, as time went on, that Python was absorbing syntax and semantics from other languages. This is nothing really new… remember I said that Python is pragmatic. If the other guys have a good way to do something, it’s entirely reasonable for Python to borrow it.

But some of those new goodies are really hard to read, in my opinion. List comprehensions, for instance, are just ugly. Saving a few lines of code is not much of a win to me, especially in a language that is already as concise as it really needs to be, and I always have to look up in the docs when I see one to figure out what’s happening. Don’t post a comment and tell me how stupid I am… I’ll admit it. I’m a bear of little brain, but writing in a subset of Python which might be considered “1.5 with the warts off,” I’ve written a bunch of very useful code. I think I have good enough reason for my opinion on the matter.

For the most part, this didn’t matter to me. I can still write that subset of Python in the 2.6 version and it works just fine. Backwards compatibility remains really good.

Then came Python 3.0, sometimes called Python 3000 (which was sort of the code name for the project to create it). Python 3.0 breaks a lot of things; it’s not backward compatible, and this was by design. I understand the desire by Guido and company to do this. But I don’t like the results.

Sure, they say, the 2.x line will be supported for some time to come, in parallel with 3.x. I’ve seen this before, though, and it doesn’t work that well. Since modules written for one version need to be modified to work with the other, module authors must maintain two versions (if they care at all). In practice, this means that as soon as a module author has upgraded his or her development system to 3.x, the 2.x module versions will fall to the bottom of the priority queue (or fall off entirely). 2.x will become a wasteland, module-wise.

I’m not sure how this will affect me, but I do know that all the modules and all the applications I’ve written are very un-compatible with 3.x. Worse, as I no longer have a Windows development environment at all (just Linux), I can’t build my own 3.x module binaries for the Windows modules I’ve published on my website. As a non-upgrader, I’m beginning to feel like an outcast in the Python world.

It sucks, honestly.