Home > Blogs > Starting Core Python

Starting Core Python

By  Jun 19, 2008

Topics: Programming

This is the first of several posts I am writing about the book Core Python. I am currently reading the book and using this as sort of a journal of my thoughts as I read. From the very beginning, the book begins delivering immediate dividends.

I am starting this blog to track my progress through the book Core Python by Wesley Chun. I am not completely new to Python, but pretty close to it. However, I have been programming for a long time. I learned Basic back in fourth grade. My first "real" language was Pascal, when I was in high school. I also learned C in high school, and programmed in it and C++ in college at Caltech. While in college, I also learned Perl, and my first website was written using Perl. It was not a CGI style site, instead it was a Perl script that would generate (static) HTML.

Most of my professional career has been spent programming in Java. I have also done some more Perl along the way. More recently I have also programmed in Ruby and ActionScript. Speaking of ActionScript, I have been programming JavaScript for a long time as well. Even more recently, I have been programming in Scala. I cannot speak enough about Scala, but that's not the point of this blog.

So why Python and why now? Three words: Google App Engine. I am very interested in GAE, for a variety of reason, and GAE is only supporting Python. In all honesty, Python is not that hard to learn. Of course I once thought the same thing about Java. Over the years I learned that while it is easy to program in Java, it is a lot harder to program well in Java. So that is why I am reading core Python. I can probably learn to program through simple trial-and-error, and consulting online docs as needed, but I think core Python will provide a more complete understanding of Python.

Now you know how I have arrived at the book. So far I have read the first four chapters of the book. This is the easy stuff, but yet there have already been numerous interesting nuggets. The first big revelation for me was that Python has been around since 1989. Now it is not like I thought "oh Python has been around since XYZW" -- I had no idea when it was invented. Still 1989 was surprising to me.

The next big revelation about Python was that it compiled to bytecode. This should not have surprised me -- I had noticed the .pyc files. For some reason I thought that this was the product of using a debugger (I like to use PyDev plugin from Eclipse, once again showing my Java roots.) So I felt pretty dumb when I read that Python compiles to bytecode. Now I was intrigued to learn about Python bytecode.

There was actually not too much about .pyc and .pyo files in the book, so I consulted Python docs. It turns out that compiled Python only makes Python files faster to start up, especially if they are loading standard modules. Actually execution is not any different. The optimized version removes a few things like assert statements to make execution slightly faster. Not too much going on here, but still interesting to know. It also leaves the door open for more improvements. Python has a reputation of being relatively fast, especially compared to Ruby. I love Ruby, but it is painfully slow. I thought that maybe Python bytecode explained some of Python's supposed performance advantage, but apparently not.

Of course bytecode reminded me of Java. Another early topic in the book that reminded me of Java is garbage collection. Python has a garbage collector, just like any "modern" language (even Objective C has one now.) The Java garbage collector is quite sophisticated, and pluggable. Sun's JVM has several to choose from, each with different algorithms optimized for environments (i.e. number of processors) and tasks (speed vs. throughput vs. consistency, etc.) Actually explaining garbage collection is a common interview question for senior Java engineers. Reference count always comes up, because of its flaws. So I was slightly surprised to see that Python uses reference count collector. Circular references are the Achilles heel of ref-count collectors, so I was pleased to see that Python has another collector used to identify circular references and collect them as well.

So that's it for the first two chapters. There are a lot more interesting things to talk about in the next couple of chapters, especially around dynamic code execution in Python. I will save those for the next post.