plonewars.com

Five Easy Pieces – Simple Python Non-Patterns from Alex Martelli
was something that I had tagged toread for quite a while now, and it
turned out to be a very interesting read.

The most important point that Martelli makes in this paper is that in
Python, some of the traditional software design patterns don’t
apply, because the Python programmer has facilities that other OO
languages lack, the lack of which makes certain patterns necessary in
other languages that seem superfluous in Python.

It’s nice how Martelli puts context into this topic, by explaining
some of the background of patterns. Most notably, he references a
book called A Pattern Language – Towns, Buildings, Construction by
Christopher Alexander and a paper called The Structure of Pattern
Languages by Nikos Salingaros, which is available online.

There’s quite a nice analogy between software patterns and
architectural design patterns. The dictionary of design patterns of
Christopher Alexander lists examples for patterns found in
architecture like SMALL PARKING LOTS, for which the summarizing
statement is Vast parking lots wreck the land for people.

Interestingly, both Alexander and Salingaros are harsh critics of
modern architecture. Salingaros writes:

Architecture has changed in this century from being a trade serving
humanity with comfortable and useful structures, to an art that
serves primarily as a vehicle for self-expression for the
architect. In the current architectural paradigm, the emotional and
physical comfort of the user are of only minor importance.

Well, this reminds me of software architects who care more about
their design than users. The Big Design Up Front page in the PPR
has some nice quotes and statements that go with this.

It makes sense to me when Martelli explains how some patterns are
unnecessary in Python and others that tend to be involved in other
languages are very easy in Python. Need a Singleton? Just create an
instance of a class and have clients access that instance by its name.
Need a registry? Make a module global instance of a list or
dict, and have append and remove be your register and
unregister functions. In Eby’s article Python is not Java, one
reads about a software project:

So, the sad thing is that these poor folks [a team of former Java
developers who were new to Python] worked much, much harder than
they needed to, in order to produce much more code than they needed
to write, that then performs much more slowly than the equivalent
idiomatic Python would.

Simplicity is the key to quality, and simple definitely beats complex.
Test-first is probably a good way to create simple designs. The
KISS principle represents:

If you have a choice between a simple solution and a complex one,
then opting for complexity would be stupid.

And:

All design should be as simple as possible, but no simpler. [...]
the more elegant designs are usually the more simple ones. Simple
also does not mean quick and dirty. In fact, it often takes a lot
of thought and work over multiple iterations to simplify.

Python code is by nature simpler than code in many other languages,
because it lets you focus on your actual problem — making simplicity
a built-in feature, and apparent that the source code is the
design. Finally, a nice quote from Kent Beck found in the PPR:

As a consultant, 80% of the time my job involves taking out
premature abstraction so we can get the damned thing out the door.

For me, the PPR is an enormous repository of insightful ideas about
software development. I’ve already emptied my cup and I’m surfing for
my next zen slap!