We have to adopt a style for presenting Python. We won't present a complete set of coding standards , instead we'll present examples. This section has some justification of the style we use for the examples in this book.

Just to continune this rant, we find that actual examples speak louder than any of the gratuitously detailed coding standards which are so popular in IT shops. We find that many IT organizations waste considerable time trying to write descriptions of a preferred style. A good example, however, trumps any description. As consultants, we are often asked to provide standards to an inexperienced team of programmers. The programmers only look at the examples (often cutting and pasting them). Why spend money on empty verbiage that is peripheral to the useful example?

One important note: we specifically reject using complex prefixes for variable names. Prefixes are little more than visual clutter. In many places, for example, an integer parameter with the amount of a bet might be called pi_amount where the prefix indicates the scope ( p for a parameter) and type ( i for an integer). We reject the pi_ as useless and uninformative.

This style of name is only appropriate for primitive types, and doesn't address complex data structures well at all. How does one name a parameter that is a list of dictionaries of class instances? pldc_?

In some cases, prefixes are used to denote the scope of an instance variables. Variable names might include a cryptic one-letter prefix like “f” to denote an instance variable; sometimes programmers will use “my” or “the” as an English-like prefix. We prefer to reduce clutter. In Python, instance variables are always qualified by self., making the scope crystal clear.

All of the code samples were tested on Python 2.5 for MacOS, using an iMac running MacOS 10.5. Additional testing of all code was done with Windows 2000 on a Dell Latitude laptop, as well as a Dell Precision running Fedora Core.