Wandering Thoughts archives

Why speeding up (C)Python matters

The simple answer to why speeding up Python matters is that speed creates freedom.

Right now there are unquestionably a lot of things that you can't do in (C)Python because they're too slow. Some of these are large macro things like certain sorts of programs; others are more micro things like use complicated data structures or do versions of things implemented in C. Speeding up Python creates the straightforward freedom to do more and more of these things.

In turn, this creates another freedom, the freedom to write code without having to ask yourself 'is this going to be too slow because of Python?'. Again, this is both at the macro level of what problems you tackle in Python and the micro level of how you attack problems. With speed comes the freedom to write code in whatever way is natural, to use whatever data structure is right for the problem, and so on. You don't have to contort your code to optimize for what your Python environment makes fast (in CPython, C level modules; in PyPy, whatever the JIT can do a good job recognizing and translating).

There is a whole universe of Python code that reasonably experienced CPython programmers know you simply don't write because it would be too slow, create too much garbage, and so on. Speed creates the freedom to use more and more of that universe too, in addition to the Python universe that we already program in. This freedom matters even if none of the programs we write are ever CPU-bound to any particular degree.

(Admittedly there's a peculiar kind of freedom that comes from having a slow language, but that's another entry.)

(This is not particularly novel and I've orbited the core of this thought in earlier entries. I just feel like writing it down explicitly today after writing about why I care about how fast CPython is, partly because a rejoinder to that entry is 'why do we care if CPython isn't really fast?'.)

Why I care about how fast CPython is

Python is not really a fast language. People who use Python (me included) more or less accept this (or else it would be foolish to write things in the language), but still we'd often like our code to be faster. For a while the usual answer to this has been that you should look into PyPy in order to speed up Python. This is okay as far as it goes, and PyPy certainly can speed up some things, but there are reasons to still care about CPython's speed and wish for it to be faster.

The simple way of putting the big reason is to say that CPython is the universal solvent of Python. To take one example, Apache's mod_wsgi uses CPython; if you want to use it to deploy a WSGI application in a relatively simple, hands-off way, you're stuck with however fast CPython is. Another way that CPython is a universal solvent is that CPython is more or less everywhere; most Unix systems have a /usr/bin/python, for example, and it's going to be some version of CPython. Finally, CPython is what most people develop with, test against, write deployment documentation for, and so on; this is both an issue of whether a package will work at all and an issue of whether it's doing that defeats much of PyPy's speedups.

Thus, speeding up CPython speeds up 'all' Python in a way that improvements to PyPy seem unlikely to. Maybe in the future PyPy will be so pervasive (and so much a drop in replacement for CPython) that this changes, but that doesn't seem likely to happen any time soon (especially since PyPy doesn't yet support Python 3 and that's where the Python world is moving).

(Some people will say that speeding up things like Django web apps is unimportant, because web apps mostly don't use CPU anyways but instead wait for IO and so on. I disagree with this view on Python performance in general, but specifically for Django web apps it can be useful if your app uses less CPU in order to free up more of it for other things, and that's what 'going fast' translates to.)

I should find some good small packages for templates and forms for CGIs

I recently wrote about how we shouldn't be making up new (web) templating packages but instead should just use existing ones. This leads me to admit that I have a little problem here with Python, in that I don't currently have one of these that I'd use. Well, sort of.

If I was to write another relatively substantial web application, I'd unquestionably use Django (and thus I'd use Django's templating system and form handling). It's what I know, it works, and we already have one Django web app so adding a second is relatively low overhead. But the problem with Django (and other big systems) is that their deployment story is kind of heavyweight and a pain in the ass. We have a number of small, simple things that are easiest to handle as just CGIs, and we'll probably get more.

(This may be over-estimating the hassles of deploying a second mod_wsgi based thing when we already have one, but wrangling Django kind of makes me grumpy in the first place.)

This means that I should really find an existing Python templating system that is right-sized for use in CGIs, meaning that it is not too big itself, does not have big dependencies, starts up relatively fast, and ideally can take its templates from embedded strings in the program instead of loading them from the filesystem. I haven't previously looked in this area (partly because Django met what I thought of as all of my needs here), so I'm not familiar with what's available.

(For simple CGI-like things, embedded the templates in the CGI's Python code makes for easier deployments, by which I mean that the whole CGI will be just one file and I'll copy it around.)

In the same spirit of 'don't roll your own half-solution when other people have done better ones', I should also get an existing package to handle forms for my CGIs. This is likely to interact with the choice of templating system, since you often want to use your template system to automatically render forms in clever ways instead of basically embedding fixed HTML for them.

Probably I want to start my investigation with, say, the Python wiki's entry on web frameworks. I'm going to not mention any project names here for now, since what comes to mind is basically influenced by the project's PR (or lack of it), not any actual knowledge on my part.

PS: This walks back from my views on templates versus simple HTML. I still believe them, but I also believe that it's probably not worth fighting city hall in most cases. A full template system may be vast overkill for many things, but there's a great virtue in standardizing on a single solution that can be learned once and is then familiar to people.

(Templates also have the virtue that the HTML and the fixed text content are both obvious, so it's easy for people to find it and then make simple brute force modification because, for example, we've decided to change some names we use to refer to our systems in order to confuse users less. You don't even really need to know the templating system for this, you just have to be able to find the text.)

Increasingly, I no longer solidly and fully know Python

There once was a time where I felt that I more or less solidly knew and understood Python. Oh, certainly there were dark corners that I wasn't aware of or that I knew little or nothing about, but as far as the broad language went I felt that I could say that I knew it. Whether or not this was a correct belief, it fed my confidence in both writing and reading Python code. Of course the wheels sort of started to come off this relatively early, but still I had that feeling.

For various reasons, it's clear to me that those days are more and more over. Python is an increasingly complicated language (never mind the standard library) and I have not been keeping up with its growth. With Python 3 I'm basically hopeless; I haven't been attempting to follow it at all, which means that there's whole large areas of new stuff that I have no idea about. But even in Python 2 I've fallen out of touch with new areas of the language and core areas of the standard library. Even when I know they're there, I don't know the detailed insides of how they work in the way that I have a relatively decent knowledge of, say, the iterator protocol.

(One example here is context managers and the "with" statement.)

I'm pretty sure that this has been part of my cooling and increased ambivalence with Python. Python has advanced and I haven't kept up with it; there's a distance there now that I didn't feel before. Python 3 is an especially large case because it feels that lots has changed and learning all about it will be a large amount of work. Part of me wonders if maybe Python (at least Python 3) is now simply too large for me to really know in the way that I used to.

You might ask if actually knowing a language this way is even important. My answer is that it is for me, because knowing a language is part of how I convince myself that I'm not just writing Fortran in it (to borrow the aphorism that you can write Fortran in any language). The less I know a language, the less I'm probably writing reasonably idiomatic code in it and the more I'm writing bad code from some other language. This especially matters for me and Python 3, because if I'm going to write Python 3 code, I want to really write in Python 3; otherwise, what's the point?

(I don't have any answers here, in part because of a circular dependency issue between my enthusiasm for writing stuff in Python and my enthusiasm for coming back up to full speed on Python (2 or 3).)