

Patterns in Python - limist
http://www.suttoncourtenay.org.uk/duncan/accu/pythonpatterns.html

======
tptacek
If you're a Python (or Ruby) dev, and this stuff is interesting to you, that's
a symptom of a problem. The problem is that you haven't read this:

<http://norvig.com/design-patterns/>

~~~
regularfry
If your point is that design patterns only exist because of insufficiently
powerful languages, I disagree. Iterator and Strategy, for instance, are
useful concepts to be able to talk about in any language, no matter whether
they're first-class or not, or how simple the implementation is. If you've got
a bunch of lambdas that define alternative ways to accomplish the same end,
then why the hell _not_ call them Strategies?

I'd also take issue with the implication that Python is powerful enough for
the common patterns to disappear completely. it doesn't have macros, for a
start, so implementing coupled Strategies of any complexity means you're back
in class FooStrategy() land.

Recognising when you are or should be implementing a recognised pattern means
that you can rely on a lot of analysis of that pattern, largely without paying
attention to the environment in which that analysis was performed. That's
potentially a big win.

I guess what I'm getting at is that throwing away patterns means throwing away
a decent lingua franca for talking about the anatomy of your code. Given that,
as someone far smarter than me once said, code is primarily for humans to read
and only incidentally for computers to execute, that seems like a poor
decision.

~~~
tptacek
While recognizing the validity of your argument I am having a hard time
resisting the urge to point out that we are commenting on code that uses the
"Observer pattern" to construct a class hierarchy with accessors for "second",
"minute", and "hour" to implement a "digital clock".

The code in this article confirms the suspicion of pattern skeptics that GoF-
style patterns lead to code constructed out of pick-and-mix patterns instead
of actual sensible code.

~~~
regularfry
You're right, of course. It's all about operating at a suitable level of
abstraction; any technique can be misapplied.

------
cubes
I'm really glad the article includes a warning against trying not to overuse
design patterns. I sometimes wonder if teaching design patterns causes people
to rely on pattern matching as a crutch, and hampers the development of
creative thinking skills required to solve new engineering problems.

~~~
digitallogic
I used to be of a similar mindset, that tools/ideas/practices should possibly
be avoided as they can sometimes have a negative affect on people who don't
fully comprehend them (such as using design patterns when they're not
applicable or where an alternative design would prove to be a better fit).

However, I've since come to believe that it's not the ideas that are harmful,
it's the people that use them without comprehending them. If this is the case,
avoiding a concept that would provide benefit is limiting yourself without any
benefit as the people that would misuse them will probably find something else
to screw up anyway.

Or, to put it more succinctly: "You can write Fortran in any language"

------
torial
At the very bottom:

View document source. Generated on: 2003-02-28 11:59 UTC.

I was thinking I'd seen this before -- a long time ago. How much still
applies?

~~~
limist
I was wondering the same thing, given python 2.6 and 3.1, and leafing through
the GoF book lately. Exploring that line of inquiry would make for a good
article (or two, or more).

------
dkarl
These are patterns from the GoF book. Learning to use these patterns in Python
is like learning Esperanto so you can pray. Python doesn't need these patterns
any more than God needs you to speak Esperanto.

~~~
limist
Well yes, arguably learning Esperanto and speaking it for any purpose is
already a sincere form of prayer. :)

Python may not "need" these patterns, but python programmers might. At the
minimum, I find it useful to know how design patterns from Java, Smalltalk,
etc. are done in Python, especially if it gives me bragging rights that a
pattern can be implemented in a fraction of the LoC needed for those other
languages.

------
SlyShy
Interesting. I sort of assumed Python had singletons natively, because I'm so
used to using them in Ruby.

This guy doesn't do it here, but you can make singletons relatively painless
in Python by using decorators.

~~~
torial
Looks like decorators were after the article was written:

<http://www.python.org/dev/peps/pep-0318/>

E.g. 2/28/2003 vs 6/5/2003

~~~
SlyShy
Yeah, it wasn't meant as a criticism of the article. More of a "Python can do
nice things too" shout out to other Rubyists. I don't know about them, but I
find myself translating code between Ruby and Python for various reasons and
it is nice to learn the parallels in idioms and such.

So, upvoted.

