The Anchor Website: .py in the Sky: PART 1

When I was first asked to write content for our new developer portal I was given the mandate of producing interesting, relevant content that would differentiate Anchor from "The Rest". Adding to this my own perogatives of becoming an international super villain and rock star, the choice was simple: Write a ray-tracer in Javascript. Unfortunately my little Athlon 1800 hasn't yet finished even the first execution of that code, so it is with great sadness and no small amount of remorse that I present to you this somewhat drier subject area. I'll help you dominate the web, but you'll have to take care of moving from there to THE WORLD.

Whinging Snakes

The most common question we get about anchor.com.au is "What are those damn .py files?", and it's a good place to start. The "py" extension is short for Python and refers to the Python programming language. For those of you unfamiliar with Python, I would characterise it as a "strictly dynamically typed, strongly object-oriented, byte compiled and EXTREMELY WHINGEY language". It's actually this last point -- "EXTREMELY WHINGEY" -- that is most endearing to us. Having programmed extensively in PHP and Perl, I know very well that there are two tasks that make the web-programmer's job miserable:

• Dealing with designers; and
• Debugging

Python can't (yet) help you with the first point, and I'll be sure to write a complete article on my thoughts on that. The "EXTREMELY WHINGEY" property helps immensely with the second point however. Some of you are probably thinking "nah, no way. Perl/php's 'Do What I Mean' code is really good. I've never had a bug in a perl/php program, and I don't have to waste my time tracking down those boring, pedantic errors and prey to the gods of computer science that my latest offering of source code should be accepted by the Mighty Compiler.". I know I sure used to think that. Then I got a series of bug reports and started auditing my code. I should have moved house and been done with it.

Let's have a whinge

So, here's what I see whenever anything goes wrong in some of the code on our staging server (I suggest you open that in another window so you can follow the rest of this article).

Let me explain how to read that, so you can appreciate just what a big help it is. The technical term for that is a stack trace. Python's stack traces are especially helpful because Python's introspection can extract all manner of helpful information about what was happening when the code exploded. So, you read these pages backwards -- bottom to top. At the very bottom is a textual description of what went wrong. The important part is the line that says "TypeError: unsubscriptable object". Once you start looking at these things you very quickly learn exactly what type of error produces that message. That particular one says that I'm using the square braces ([]) on something that I shouldn't be, which probably means that my "something" didn't end up being what I expected it to.

Going back up the page we see a pink line with some code in it. It looks like this:

That's the line that caused the error. If you look just below that block of code, Python has reported some variables that it thinks are relevant to this error:

None is Python's equivalent of perl's undef or php's NULL. So, the error is very simply that I've treated this emtpy variable like it was an array. There's a lot more information in this page though. Each level of information is telling you about the code that called the layer beneath it. To explain a little more, the layer above this one has highlighted a section of code which reads:

The important part is the getWizard part. That's a function call, and if you look closely you'll see that the code we were examining previously is entitled:

Each strata of the error report is informing you how the next level down was called. It's a complete history of everything that happened to cause this error. Python's error handling is light years ahead of anything in php or Perl, and that on it's own would be enough reason to use it in a system that needs to be reliable. It was this argument that finally convinced my superiors that Python was the direction to move to from the abomination that the existing TCL system was.

Just before we move on from error handling, I'd like to address one concern you may have -- how do you stop your clients seeing those AWFUL, UGLY purple screens when stuff breaks? in PHP or Perl you generally just tell it to ignore any errors and be done with it. When clients call up and say there was an error, you are unlikely to get any information about it. On our live site we have Python configured to write the purple screen out to a file, and display a short message to the user informing them that there was an error. We get the log and they know that we're looking into the problem.