Guido van Rossum created the Python language, which is one of a multitude of popular dynamic languages available these days to script popular 3D packages including Maya, Cinema 4D, LightWave and Modo.

Last Sunday, van Rossum, a staff software engineer at Google, presented at the PyCon conference in Silicon Valley, then talked with editor-at-largew of our sister site InfoWorld Paul Krill, elaborating on Python and responding to critics.


InfoWorld: You answered critics who said that Python is too slow. You said every time you try to write something in Python, it is fast enough. Why is there criticism that it is too slow?

Van Rossum: What people of course do is they pick a tool and they build something incredible, and as part of the incredible thing they're building, they're doing crazy stuff, and sometimes some of the crazy stuff involves doing a whole bunch of computation, crawling through a graph of a billion social contacts or analyzing a trillion email messages or whatever.

At some point, you end up with one little piece of your system, as a whole, where you end up spending all your time. If you write that just as a sort of simple-minded Python loop, at some point you will see that that is the bottleneck in your system. It is usually much more effective to take that one piece and replace that one function or module with a little bit of code you wrote in C or C++ rather than rewriting your entire system in a faster language, because for most of what you're doing, the speed of the language is irrelevant.

InfoWorld: Which is the current version of the language?

Van Rossum: There are two different versions out right now. There are two branches of the language that we're trying to unify eventually. We're trying to kill off the Python 2 branch, so that the last leaf on the Python 2 branch is Python 2.7. But you still see a lot of Python 2.6 and 2.5. With the Python 3 branch, the current release is 3.2, and we just released an alpha of 3.3, so in a few months, 3.3 will be available.

InfoWorld: What's the main attraction of the Python 3 branch?

Van Rossum: Python 2 had accumulated multiple ways of doing the same thing. Also, Python 2 had introduced a way of dealing with Unicode; when we introduced it in 2000, we were very proud of our Unicode support and the way it was backward-compatible. By the time 2006-07 rolled along, we realized that we needed a completely different approach to Unicode, and we couldn't come up with a way of making that new correct approach to Unicode compatible with the old version of the language.

That was one thing that made us think that instead of having point releases that are constrained by pretty severe compatibility requirements, let's have one new release, Python 3. We're going to clean up a bunch of things and we're going to throw away features that were already deprecated. Users will know Python 3 is incompatible with Python 2, but it feels still like pretty much the same language.

InfoWorld: If it's incompatible, do you have to recompile your Python 2 apps?

Van Rossum: You have to change the source code of your Python 2 apps in the most general case. We provided a tool named 2to3 that does most of the changes to your source code automatically. But there are some things that you can't automate, so you have to manually revise them. Since then, people have also come up with strategies of writing in a restricted version of Python 2, by just not using certain features, and magically their source code is already compatible with Python 3.

InfoWorld: You talked about the arguments for and against dynamic typing. You said that if you trust your compiler to find all the bugs in your program, you've not been doing software development for very long. So you're satisfied with Python being dynamic?

Van Rossum: Absolutely. The basic philosophy of the language is not going to change. I don't see Python suddenly growing a static subdivision or small features in that direction.

InfoWorld: You mentioned at some point you expect global static analysis of Python programs would be realistic. What would the benefit be for Python developers?

Van Rossum: What you can do with global static analysis is you can find certain types of bugs. Another thing you can do is optimization.

InfoWorld: Is Python's GIL (Global Interpreter Lock) an impediment to doing multicore programming, or is that not the story?

Van Rossum: That is actually more or less the story. If you have multiple cores, you cannot have each core execute Python bytecodes in parallel with the others because Python bytecode runs with the GIL, and only one of the cores can have the GIL. What Python threads can do when they don't hold the GIL is just wait for I/O, or they can invoke code that was written in C or C++.

For example, in NumPy, which does large matrix manipulations, when you give a matrix to NumPy or a big array and you tell it to go compute this function over these 10 million points, it releases the GIL that can be executed on a core. I don't know if NumPy has parallelization machinery, but you could even imagine that if you had 10 cores, you could parcel out work to 10 cores, and those could run in parallel on different pieces of data, and none of them needs the GIL because they're not manipulating Python objects.