8 Jan 2005 titus   » (Journeyer)

"Batteries included" may be a bad term

After some of the recent types kerfuffle, I decided I didn't like the "batteries included" description of Python. Let me explain.

Python-the-language is great, and fits most of my needs. Heck, it's done that since before 2.0 came out. It's always nice to discover that some nifty new feature (like list comprehensions) has been added, and often I can take advantage of them to write tighter/neater/more understandable code. Nonetheless, I'm fundamentally a systems & application programmer, and I don't generally write language frameworks, toolkits, etc., so these new features aren't usually all that critical to my work.

What is critical is the fantastic standard library that comes with Python. It has been steadily expanded in the years that I've been a Python programmer, to the point that when I'm looking around on the 'net for some functionality it's already in the Python lib more often than not. This saves me a lot of time & trouble installing new products. (I've also said that I think that the state of the included Python code, as well as the quality of the documentation & example code, plays a big part in educating new Pythonistas about acceptable coding practices with Python. The Python cookbook is a particularly nice collection of code, too. These both play a big role in the success of Python, IMO.)

So, batteries are included, if you think of the library as the "batteries" -- something essential to function, yet not terribly interesting in its own right. Looking at that description of batteries, though, it sounds more like it fits my conception of the Python language, though. After all, the language that things are written in is essential, yet not always all that interesting; doing things in the real world is more interesting. For that you usually need to interact with users or protocols, and that means some sort of interface, and ... you end up with a library of code that enables a lot of standard interactions. In Python, that code is distributed with the interpreter, which enables a stunningly wide range of functionality in your basic Python installation.

In other words, I think the included library & modules are more interesting than the word "batteries" might imply ;).

There may be a deeper schism lurking behind the recent decorator & types controversy: language vs tools. It's very sexy to work on extending the language: there are plenty of deep problems to be tackled, much thought must be expended, and only really really smart thoughtful people can do it well. As Iwan van der Kleyn pointed out, though, there are other things to do that will extend Python's reach, power, and utility. It might be worth the core team having a look at those, if their goal is to advance Python as a whole. If, instead, the goal is to advance Python-the-language, then I think they're doing a fantastic job of it & should keep it up. Personally I'm more worried about the future of the library.

UPDATE: AMK posted about this months ago, and got a lot of responses. I think that's what got me started...

And, before the naysayers get up & yell at me for my multitude of sins, I do have some specific work and proposals in mind. It's hard to grasp the library as a whole, though. (It's easier to write a criticism than it is to do the work, too, that's for sure.) Watch This Space.

As for the long-term future of Python, Guido's first priority clearly needs to be to grow a beard.


Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!