Man, it's great to be a Python developer! I'm in awe of Guido van Rossum, who made the conscious decision when he created Python to force developers to keep their code neatly formed and readable. He did this in the simplest way: format your code nicely or else it won't run.
This is based on indentation used in the code samples. For example, the following code sample will not run:
def say_hello():
print "hello!"
print "hola!"
The function attempts to say "Hello" in two different languages. Notice that, inside of say_hello(), the indentation isn't consistent. This causes Python to raise an IndentationError exception.
This constraint may seem fastidious, but it's brilliant in it implications. Mr. van Rossum is telling you to keep your code pretty or it won't run. He based this on the insightful observation that code is read much more often than it is written. Even code that a developer has written becomes alien to the person who wrote it after only a short period of time.
This is innovation in engineering at its finest. The use of curly braces to denote context in computer code has been inherited by many languages, from C to C++ to Java to C#. Python's creator saw a problem with the status quo, and he chose to do something about it. He made his programming language much more usable than several others that came before and after it.
Creating a new programming language is not something most people, even programmers, can do. It's even rarer that people innovate in this fashion. Guido van Rossum did both; this is the reason that he now works for Google.
For this reason, I urge any developer getting started with Python (Django developers, this includes you!) to read the Python Style Guidelines in PEP 8. These guidelines have been put forth by Mr. van Rossum himself. If you're a Python developer and you haven't read PEP 8 yet, go read it now before you write any more code. It's well worth your time.
Of course, a lot of the recommendations made in the document are just that: recommendations. Your code will run just fine even if you don't adhere strictly to every last one of these guidelines. However, in order to keep number of broken windows in Python community code to a minimum (higher quality code = happier developers), you should be following these guidelines whenever you can.
One of the suggestions is to use four spaces for each level of indentation. (The document cautions against using tabs, but if you're going to use them, set the tab width to four character spaces.) Unfortunately, while I was writing Beginning Django E-Commerce, I was using two separate computers to write code and write the book. For this reason, some code samples in the book use four spaces for indentation, while others use five. I didn't catch this error before the book went to press since the Word template uses a very narrow font for code samples in the text. (They come out much wider in print.)
This does NOT mean the book's code is broken. Python allows you to mix different indentation lengths, just not within a single code block. As you're reading, you'll probably notice the difference in indentation between code in earlier chapters and later ones. It's unfortunate, but not a deal breaker. And the source code you can download from the Apress web site uses 4 space tabs for indentation, consistently.
Just something to keep in mind while you're pounding out Django code while working through the book: you are encouraged to use 4-space indents. Do as Guido says...not as I do.
