do design patterns still apply with Python?

[John Salerno]

Since Python does so many things different, especially compared to
compiled and statically typed languages, do most of the basic design
patterns still apply when writing Python code? If I were to read a
design pattern book (such as Head First Design Patterns), could I apply
their Java examples to Python easily enough, or does Python require a
different perspective when applying patterns?

 

[shandy.b]

Hi John.

Design patterns aren't tied to any specific implementation so they
should apply to any language. You might find that they can even apply
to solution domains outside of computer science.

Implementation details will usually differ between languages. But the
implementation can also be different using the same language. For
example, you can use Java to implement the Model View Controller design
pattern when writing a web site or when writing a database engine --
the implementation will be very different, but both will be MVC.

In python, you might find it more natural to do design patterns in a
completely different way than they're implemented in Java. For
example, I've heard of using the Singleton pattern in python by just
implementing it as a module, no classes necessary.

sjbrown

 

[John Salerno]

In python, you might find it more natural to do design patterns in a
completely different way than they're implemented in Java. For
example, I've heard of using the Singleton pattern in python by just
implementing it as a module, no classes necessary.

Yeah, that's what I was wondering. I wonder if, after reading a DP book,
I might have to 'unlearn' some things when applying them to Python. But
I suppose I should just do it first and then try to implement them
myself. OOP is just so mind-bending for me that I've kind of put off
patterns right now until I get more comfortable with it.

 

[Grant Edwards]

Since Python does so many things different, especially compared to
compiled and statically typed languages, do most of the basic design
patterns still apply when writing Python code?

Definitely. Especially plaid, paisley, and a nice medium
houndstooth check. But please, not all at the same time.

 

[Roy Smith]

Since Python does so many things different, especially compared to
compiled and statically typed languages, do most of the basic design
patterns still apply when writing Python code? If I were to read a
design pattern book (such as Head First Design Patterns), could I apply
their Java examples to Python easily enough, or does Python require a
different perspective when applying patterns?

Many of the classic design patterns apply just fine to Python, at least in
the high-level view. On the other hand, much (most?) of what's in the
classic design pattern books is so tied up with ways around C++/Java type
bondage, it's difficult to see the forest for the trees.

For example, take the most classic of all patterns, Singleton. A typical
C++ Singleton treatment will be all about making constructors private and
shit like that. None of that carries over to Python. What I would do in
Python is have a module-level factory function which caches a single
instance of the class to return to the 2nd and subsequent caller and not
get my panties in a twist over the fact that some clever programmer could
find away around my code and force creation of a second instance.

The basic concepts in the pattern books are worth knowing. You just have
to be able to tease apart the concepts from the language-specific cruft
that so often obfuscates the descriptions.

 

[ajones]

Yeah, that's what I was wondering. I wonder if, after reading a DP book,
I might have to 'unlearn' some things when applying them to Python.

I would say adjust instead of unlearn. This is probably true to a
lesser or greater extent of any language for which your DP book was not
written.

But I suppose I should just do it first and then try to implement them
myself. OOP is just so mind-bending for me that I've kind of put off
patterns right now until I get more comfortable with it.

I would suggest getting a good grasp on OOP before you get into design
patterns. When most people start with any new concept they tend to try
and see everything in terms of their new toy, so sticking to one or two
new concepts at a time will make things a little easier.

Design patterns are kind of like sarcasm: hard to use well, not always
appropriate, and disgustingly bad when applied to problems they are not
meant to solve. You will do just fine without them until OOP is at
least familiar to you, and by that time you should be a little better
able to use them appropriately.

 

[Terry Hancock]

Since Python does so many things different, especially
compared to compiled and statically typed languages, do
most of the basic design patterns still apply when
writing Python code? If I were to read a design pattern
book (such as Head First Design Patterns), could I apply
their Java examples to Python easily enough, or does
Python require a different perspective when applying
patterns?

[...]
The basic concepts in the pattern books are worth knowing.
You just have
to be able to tease apart the concepts from the
language-specific cruft that so often obfuscates the
descriptions.

This sounds like an article crying out to be written,
"(Learning) Design Patterns with Python".

Has it been written already?

Cheers,
Terry

 

[Paul Rubin]

Since Python does so many things different, especially compared to
compiled and statically typed languages, do most of the basic design
patterns still apply when writing Python code? If I were to read a
design pattern book (such as Head First Design Patterns), could I
apply their Java examples to Python easily enough, or does Python
require a different perspective when applying patterns?

I'd say the relative importance of particular patterns depends on
whether the problems it solves are easier or harder in the language
you're using. Many things that are difficult in Java are easy in
Python, so the patterns in the book aren't terribly relevant.
Somewhat less often, something is easy in Java and difficult in
Python. When that happens, you may need approaches that aren't in the
book. Finally, you have to think of all of these books as different
approaches of explaining elephants to blind men. There's a lot of
murkiness in programming and design patterns are yet another way to
help guide people through it. But the more programming you do, the
better your own internal maps and instincts become, and the less you
need a guidebook that doesn't always correspond to the actual
landscape you're operating in. So consider the books to contain
helpful guidelines but don't feel afraid to trust your own instincts
over them, especially after those instincts become better developed.

 

[Roy Smith]

Somewhat less often, something is easy in Java and difficult in
Python.

Example?

 

[Paul Rubin]

Example?

Sandboxed code is a real obvious one.

 

[Roy Smith]

Sandboxed code is a real obvious one.

What is "sandboxed code"?

 

[Paul Rubin]

What is "sandboxed code"?

It's what the old rexec/bastion module tried unsuccessfully to
implement: a way of running potentially hostile code while limiting
the kinds of harmful stuff it can do. This is needed for things like
browser applets. Javascript (not related to Java except by name) also
depends on it. A web browser that let arbitrary web pages run python
scripts would be totally insecure and would let the site implementers
take over your browser. Obviously not every application needs this,
but it's hard to do unless there's fairly deep support for it in the
language.

 

[Paul Rubin]

Design patterns are kind of like sarcasm: hard to use well, not always
appropriate, and disgustingly bad when applied to problems they are not
meant to solve.

+1 QOTW

 

[gene tani]

This sounds like an article crying out to be written,
"(Learning) Design Patterns with Python".

Has it been written already?

Cheers,
Terry

There's a couple Alex M slideshows and a couple discussions of
Creational/Structural / Behavioral patterns

http://www.strakt.com/docs/ep04_pydp.pdf

http://www.suttoncourtenay.org.uk/duncan/accu/pythonpatterns.html
http://www.pasteur.fr/formation/infobio/python/ch18s06.html
http://www.sauria.com/~twl/conferen...terns and Python OOP - Objects By Design.html

i think mostly i flip thru the Oreilly cookbook whenever i need
something.

 

[bruno at modulix]

ajones wrote:

(snip)

I would suggest getting a good grasp on OOP before you get into design
patterns. When most people start with any new concept they tend to try
and see everything in terms of their new toy, so sticking to one or two
new concepts at a time will make things a little easier.

Design patterns are kind of like sarcasm: hard to use well, not always
appropriate, and disgustingly bad when applied to problems they are not
meant to solve. You will do just fine without them until OOP is at
least familiar to you, and by that time you should be a little better
able to use them appropriately.

<aol>Well, I mostly agree here</aol> but OTOH, studying the GoF has been
a real 'OO mind-opener' for me.

I'd say the key here is to study existing patterns to try and understand
how to best design and structure OO code instead of insisting on
copy/pasting canonical patterns everywhere (IOW : trying to get the
'spirit' of patterns instead of sticking to the 'letter').

My 2 cents...

 

[Paul Boddie]

Sandboxed code is a real obvious one.

I don't disagree that this is true in general, but is that actually
covered in the design patterns book [1] or in other related literature?

Paul

[1] "Design Patterns: Elements of Reusable Object-Oriented Software"

 

[Nick Craig-Wood]

I would suggest getting a good grasp on OOP before you get into design
patterns. When most people start with any new concept they tend to try
and see everything in terms of their new toy, so sticking to one or two
new concepts at a time will make things a little easier.

Having read the design patterns book a long time after learning OOP, I
came at it with a different perspective. I found it was useful for
naming techniques which I'd been using all along. A good programmer
will find it easy to re-invent nearly all the patterns, but having a
name for them is important.

As programmers we name everything and as a corollary if it hasn't got
a name it is difficult to talk about, so from that angle the book is
good and very applicable to python. That said I found wading though
pages of language-specific waffle extremely dull!

Design patterns are kind of like sarcasm: hard to use well, not always
appropriate, and disgustingly bad when applied to problems they are not
meant to solve. You will do just fine without them until OOP is at
least familiar to you, and by that time you should be a little better
able to use them appropriately.

;-)

 

[msoulier]

Personally, I find many of the design patterns apply but require
modification.

For example, the Factory pattern is mostly to work around the fact that
it's difficult in Java and C++ to dynamically load classes. Not so in
Python, especially with exec. A simple configuration file and an exec
call can replace an entire Factory pattern, with the same result.

The ideas are fine, but sometimes it's best to keep things simple. I
find that DP junkies don't tend to keep things simple.

 

[Roy Smith]

For example, the Factory pattern is mostly to work around the fact that
it's difficult in Java and C++ to dynamically load classes.

You're over-specifying. Most of most design patterns is to work around the
fact that it's difficult in Java and C++ to do many things.

 

[Irmen de Jong]

You're over-specifying. Most of most design patterns is to work around the
fact that it's difficult in Java and C++ to do many things.

+1 QOTW!

--Irmen