Pythonic design patterns

[Slaunger]

Hi comp.lang.python

I am this novice Python programmer, who is not educated as a computer
scientist (I am a physicist), and who (regrettably) has never read the
GOF on design patterns.

I find myself spending a lot of time in Python making some designs, to
solve some task, which is the end turn out to be closely related to
well established design patterns / programming idioms, which other
users in this forum has been kind enough to point out. Only my
implementations are often not that clean, and I may call things
something different than the normal convention, which is a source of
confusion for myself and others trying to communicate with me.

I guess I could boost my productivity by learning these well-proven
and well-established design patterns by heart.

I was therefore wondering if you could recommend a book or a resource
concerning design patterns with special focus on the possibilities in
Python?

In that manner I may be able to both learn programming more pythonic
AND learn the design patterns.

-- Slaunger

 

[Michele Simionato]

Hi comp.lang.python

I am this novice Python programmer, who is not educated as a computer
scientist (I am a physicist), and who (regrettably) has never read the
GOF on design patterns.

I find myself spending a lot of time in Python making some designs, to
solve some task, which is the end turn out to be closely related to
well established design patterns / programming idioms, which other
users in this forum has been kind enough to point out. Only my
implementations are often not that clean, and I may call things
something different than the normal convention, which is a source of
confusion for myself and others trying to communicate with me.

I guess I could boost my productivity by learning these well-proven
and well-established design patterns by heart.

I was therefore wondering if you could recommend a book or a resource
concerning design patterns with special focus on the possibilities in
Python?

In that manner I may be able to both learn programming more pythonic
AND learn the design patterns.

-- Slaunger

The Python Cookbook (the printed version) is the best you can find in
this direction.
Also, consider the more recent "Expert Python Programming" by Tarek
Ziade'.

 

[James Stroud]

Hi comp.lang.python
I was therefore wondering if you could recommend a book or a resource
concerning design patterns with special focus on the possibilities in
Python?

In that manner I may be able to both learn programming more pythonic
AND learn the design patterns.

-- Slaunger

Check the python cheat sheet for the most common idioms:
http://rgruet.free.fr/PQR25/PQR2.5.html#Workspace. You should also check
out http://effbot.org/zone/index.htm and peruse Fredrik Lundh's code.
His blog is worth a look as well. He is a master of pythonic idioms and
patterns.

The cookbook has a lot of complex examples and may not provide you with
the insight you are looking for. Only a small fraction of the recipes do
this.

--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com

 

[Michele Simionato]

The cookbook has a lot of complex examples and may not provide you with
the insight you are looking for. Only a small fraction of the recipes do
this.

Whereas I agree that the online cookbook has too many complex recipes,
as far I can
remember most recipes in the printed version were quite generic and
worth to study.
Another good book I did not mention before is "Dive into Python" by
Mark Pilgrim
which is also available on line (Google is your friend).

 

[Gerhard Häring]

Hi comp.lang.python

I am this novice Python programmer, who is not educated as a computer
scientist (I am a physicist), and who (regrettably) has never read the
GOF on design patterns. [...]

I guess I could boost my productivity by learning these well-proven
and well-established design patterns by heart.

At least for me I only getter better by actually training. For
programming this means: write code. Revisit it later, improve on it.

Of course one often wants to apply all cool new tricks you've learnt.
That's normal, but remember:

"""
Brian Kernighan Law of Debugging Difficulty

Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it. -- Brian Kernighan

"""

I was therefore wondering if you could recommend a book or a resource
concerning design patterns with special focus on the possibilities in
Python? [...]

I have this in my bookmarks:

http://www.suttoncourtenay.org.uk/duncan/accu/pythonpatterns.html

-- Gerhard

 

[Steven D'Aprano]

I find myself spending a lot of time in Python making some designs, to
solve some task, which is the end turn out to be closely related to well
established design patterns / programming idioms, which other users in
this forum has been kind enough to point out. Only my implementations
are often not that clean, and I may call things something different than
the normal convention, which is a source of confusion for myself and
others trying to communicate with me.

I guess I could boost my productivity by learning these well-proven and
well-established design patterns by heart.

This is all very good, but don't drink the design pattern Kool-Aid and
start pushing design patterns everywhere. (Not everything needs to be a
singleton. No, really.)

I think the risk with design patterns is that in the hands of an over-
enthusiastic new convert, they encourage over-engineering, excessive
abstraction and Big Design Up Front thinking. Patterns are useful,
there's no doubt about it, but patterns should for the most part be
invisible. Functions are patterns, but because they were invented back
when dinosaurs walked the earth, before the Gang Of Four, they're just
called functions instead of AbstractReusableResultGeneratingValueFactory
Pattern. *wink*

http://c2.com/cgi/wiki?DesignPatternsConsideredHarmful

I think one good sign of pattern over/mis-use is when people can't even
agree on whether something is a pattern, and if so, which pattern it is:

http://c2.com/cgi/wiki?FactoryMethod

 

[George Sakkis]

This is all very good, but don't drink the design pattern Kool-Aid and
start pushing design patterns everywhere. (Not everything needs to be a
singleton. No, really.)

Obligatory reading: http://www.mortendahl.dk/thoughts/blog/view.aspx?id=122

George

 

[Marco Mariani]

Obligatory reading: http://www.mortendahl.dk/thoughts/blog/view.aspx?id=122

By the way, it's a fact that many low-level patterns, as they are
described, are useful mainly/only in statically typed languages.

The ones in PEAA, for instance, are high-level enough to be useful in
any environment.

http://www.amazon.com/Enterprise-Application-Architecture-Addison-Wesley-Signature/dp/0321127420

 

[Ned Deily]

I was therefore wondering if you could recommend a book or a resource
concerning design patterns with special focus on the possibilities in
Python?

Check out any or all of Alex Martelli's talks on Python Design Patterns
(search YouTube for "google developer python alex"), and download the
notes at <http://www.aleax.it/goo_pydp.pdf>.

 

[Bruno Desthuilliers]

Slaunger a écrit :

Thank you all for sharing your views, links and suggestions on my
question. I see where this is getting, and I have extracted the
following points:

1. Many classic design patterns, especially the creational ones
(Factory, etc.) aren't really that useful in Python as the built-in
features in the language and the new style objects has ways of doing
these things far more natural than statically types languages.

Well... I'd formulate it another way: many classic design patterns are
either builtins or simply obvious in Python, so they are barely
identifiable as such - at least if you fail to decouple the *design*
pattern from it's canonical implementation(s). Remember that design !=
implementation !-)

2. Don't be religious about the design pattern and applying them too
frantically. They may look cool, but there is a great danger for over-
engineering and subsequent lower code readability, debuggability, and
maintainability.

Indeed. And when you use one, try to implement it the pythonic way...

(snip)

 

[Slaunger]

Thank you all for sharing your views, links and suggestions on my
question. I see where this is getting, and I have extracted the
following points:

1. Many classic design patterns, especially the creational ones
(Factory, etc.) aren't really that useful in Python as the built-in
features in the language and the new style objects has ways of doing
these things far more natural than statically types languages.
2. Don't be religious about the design pattern and applying them too
frantically. They may look cool, but there is a great danger for over-
engineering and subsequent lower code readability, debuggability, and
maintainability.
3. Seek inspiration from well-written sample code.
4. It is good to know them, but be bold sometimes and do something
simpler.

I think I will buy the Cookbook, not for its design patterns, but more
for seing good examples of pythonic code and commonly used Python
programming idioms. I already have the "Python in a Nutshell", which I
like very much as a no-nonsense presentation of the language and its
batteries, and that book would probably be a valuable addition to my
limited collected (there are a few condensed pages concerning new-
style objects, which I read over and over again). Later, if I still
have the appetite for it and feel the need I might dive into some of
the other resources mentioned. As a matter of fact I have visited all
the links now and gotten some valuable inspirations.

-- ~~~~

 

[r.grimm]

Hallo,

users in this forum has been kind enough to point out. Only my
implementations are often not that clean, and I may call things
something different than the normal convention, which is a source of
confusion for myself and others trying to communicate with me.

I think, you should start with the classical books of Design Patterns
to get a solid understanding and especially vocabulary to communicate
with your coworkers. Its easier and better to say, that you will use a
strategy pattern than to describe the architecture in many sentences
to your partner in a ambigious way. Thats in my opinion the first and
the key benefit of Design Patterns. Speaking in the same language. The
next step should be to apply your knowledge to your programming
language.
So I will recommend the classical GOF Books and the serie Pattern
Oriented Software Architecture.

Greetings
Rainer

 

[Bruno Desthuilliers]

(e-mail address removed) a écrit :

Hallo,
I think, you should start with the classical books of Design Patterns
to get a solid understanding and especially vocabulary to communicate
with your coworkers. Its easier and better to say, that you will use a
strategy pattern than to describe the architecture in many sentences
to your partner in a ambigious way.

Indeed. But now there's the risk that coworkers implement this as:

class AbstractFooStrategy(object):
def run(self, yadda):
raise NotImplementedError

class SimpleFooStrategy(AbstractFooStrategy):
def run(self, yadda):
# code here

class Bar(object):
def __init__(self, foo_strategy):
if not isinstance(foo_strategy, AbstractFooStrategy):
raise ValueError("yadda yadda")
self.foo_strategy = foo_strategy
def do_this(self, yadda):
return self.foo_strategy.run(yadda)


b = Bar(SimpleFooStrategy())


instead of:

class Bar(object):
def __init__(self, foo_strategy):
self.foo_strategy = foo_strategy
def do_this(self, yadda):
return self.foo_strategy(yadda)


def baaz(yadda):
# code here

b = Bar(baaz)

Thats in my opinion the first and
the key benefit of Design Patterns.

Totally agree - at least as long as coworkers clearly understand the
difference between design and implementation.

Speaking in the same language. The
next step should be to apply your knowledge to your programming
language.

Indeed !-)

So I will recommend the classical GOF Books

<aol />

While most implementation example are way over the top in the context of
a hi-level dynamic language like Python, the GOF is one of the best book
on OO design I've ever read - if not the only that was worth reading
(disclaimer : I didn't read much dead-tree stuff on OO).