Lesson Three - Style is Also Substance

If you know only one thing about Python it is most likely the very well-known fact that Python has some unusual requirements related to a program's format. Other popular languages like C, Java, and Perl were created in reaction to the rigidity of the formatting rules of older, more stubbornly capitalized languages like FORTRAN and COBOL. The fussiness exhibited by these languages' formatting rules were assumed to be a pointless imposition (and perhaps that was true). The problem was that once programmers were given the freedom to organize the layout of their code in a completely arbitrary way, they did. This style is certainly more convenient while one is actually typing in some code. However, there is a problem and it's extremely critical: if there is no consistency in the layout of the code, then code can not be as easily assimilated by other programmers. Even if you're not concerned about anyone but yourself, it's been pretty well demonstrated by now that even a single programmer incurs a nasty penalty for inconsistent style when trying to comprehend his/her own work.

Good programmers of C and Perl quickly started to catch on to the fact that just because one was free to do anything, it wasn't necessarily a good idea. Programming conventions arose. "Good programmers" did things like match their curly braces on corresponding columns and indenting control structures to indicate vague concepts of level.

This created a weird situation where "good programmers" did things in one of a few different styles and "bad programmers" took little notice of these mores at all. Companies started writing down these unwritten rules in an attempt to produce some consistency in their code. This was fine until the company needed to incorporate code from other organizations.

Python goes a long way towards solving this problem. There is still plenty of flexibility in coding style, but compared to C formatting, there are also major constraints. These major constraints do an excellent job of enforcing a universally consistent-looking code base. That is not the end of the story, however. Unlike FORTRAN, Python's parser is as sophisticated as any language's. Instead of needing formatting constraints so that the compiler has a sporting chance of understanding what you want, as in early FORTRAN, Python was designed so that it's formatting idiosyncracies would ultimately be a blessing for the aforementioned "good programmers".

By the time Python arrived, "good programmers" were already fastidiously organizing their code into very consistent self-imposed forms. What Python did was to basically make this good practice officially required. In return, much of the stuff that was required in C-formatted languages was no longer necessary. It turns out that Python got a real bargain in this trade. Perhaps the most obvious things missing from Python's syntax is the notion of block delimiters, i.e. {curly braces} in C/Perl, and end of statement delimiters, i.e. semi-colons in C/Perl. After using Python for a while, you'll probably say good riddance!

Let's compare the formatting style of the most crucial programming construction, the if statement, in Perl and Python. Don't worry about what this code does; we're interested in how complex it looks.

# In Perl (C too basically) if ($c == '\n') { $s[$i] = $c; ++$i; }

# In Python if c == '\n': s[i] = c i += 1

Since we don't care what this code is doing, let's pull out the specific variable names and have a look at the skeletal structure.

# In Perl if ($ == '') { $[$] = $ ; ++$ ; }

# In Python if == '': [] = += 1

Obviously the Python code is a lot easier on the eye. It turns out that the main thing Python gives up for such an elegant syntax is the ability to do things like this:

if ($ == '') { $ [$ ] = $ ; ++$ ; }

There are tons of ways you CAN scramble and obfuscate your programs in Python if you really need to, but Python programmers generally regard this reduced obfuscation ability as one of the most profound advantages of the language.

The point of this lesson was to help you understand the rationale for the idiosyncratic Python formatting requirements. In the next lesson, I will explain the specific rules in more detail.