[Baypiggies] The (lack of) design patterns in Python
aleax at google.com
Tue Aug 4 19:37:40 CEST 2009
On Tue, Aug 4, 2009 at 9:06 AM, Bill Janssen<janssen at parc.com> wrote:
> Sounds like you and Joe are in complete agreement. His whole point is
> that the design patterns so necessary in Java are mostly unused in
> Python, because Python has lots of powerful built-in capabilities that
> Java lacks. If it's a language feature, you just use it; if it isn't,
> you need a design pattern to imitate it.
"Design Patterns are language-specific" is smack up front in the gang
of 4 book, smack up front in my classic presentations on Design
Patterns in Python, etc, etc -- it's hardly a new message, IOW.
The concept of "factory" is crucial -- the fact that the
implementation differs by language is minor in comparison. The bad
example of strategy pattern his presentation gives is bad simply
because the "strategies" in question don't use `self` (and so are
better represented in Python as free-standing functions -- just as
they might be in C++, say) -- far from meaning, as he argues, that
said strawman example shows Strategy DP is no use in Python, it just
shows that it is quite possible to use excessive ceremony and
mechanism where a lighter-weight approach would serve as well or
better. (wikipedia's wrong about first class functions being
sufficient to make Strategy "invisible" -- that only applies directly
to strategies that KEEP NO STATE; the somewhat-goofy approach of
explicitly passing [and possibly returning] a state object, needed in
functional languages missing the code/data coupling of OO, is
generally inappropriate where you CAN use that coupling -- as in Java,
Python, and C++).
"Meta-programming" (which he shows simply as monkeypatching an
attribute into a class) is one tool, and often overused (Simionato in
particular has written a lot on the subject). It has nothing to do
with making design patterns disappear.
What's his point on the Iterator DP? It's best implemented in modern
Java by implementing the interface Iterator<sometype> and may be
accessed via `foreach` (or may be accessed directly at a lower level
via `next` &c); it's best implemented in modern Python by implementing
the abstract base class collections.Iterator and may be acessed via
`for` (or may be accessed directly at a lower level via `next` &c).
C++ iterators are somewhat different (while Java and Python are quite
similar on this point) but it's still much the same design pattern in
a slightly varying guise. Certainly not a sign of LACK OF design
patterns in any of the three languages.
Implementing the Observer DP by wrapping and monkeypatching as he does
cries out for vengeance to the heavens -- just imagine you add three
observers by this [expletive deleted] approach and then the second one
wants to remove itself. Shudder. A good understanding of design
patterns, starting with the Forces section of well-written-out DPs,
would save otherwise-inexperienced designers from perpetrating such
horrors. That's a lot of what DPs are all about: *best practices* that
extract crucial aspects of the living experience of advanced
designers, people who have "been there, done that" and have the scars
to show for it -- and there is no lack of them in Python, as there
isn't in any other comparable technology.
And don't get me started on PyCSP -- Twisted easily twists it around
its pinky. The left one. Of course, Twisted *centers* on an
implementation of the Reactor DP -- "lack of DPs" my foot -- and that
exactly where it gets most of its power and ease of integration with
other event loops (e.g. from GUI toolkits), because different Reactor
implementations can be plugged in as necessary. Try _that_ w/PyCSP;-).
More information about the Baypiggies