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?
--
http://mail.python.org/mailman/listinfo/python-list

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

--
http://mail.python.org/mailman/listinfo/python-list

[John Salerno]

shandy.b@... wrote:

> 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.  :)
--
http://mail.python.org/mailman/listinfo/python-list

[Grant Edwards]

On 2006-03-02, John Salerno <johnjsal@...> wrote:

> 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.

--
Grant Edwards                   grante             Yow!  Maybe we could paint
                                  at               GOLDIE HAWN a rich PRUSSIAN
                               visi.com            BLUE --
--
http://mail.python.org/mailman/listinfo/python-list

[Roy Smith]

In article <8SINf.1718$No6.40137@...>,
 John Salerno <johnjsal@...> wrote:

> 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.
--
http://mail.python.org/mailman/listinfo/python-list

[Adam Jones]

John Salerno wrote:
> 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.

--
http://mail.python.org/mailman/listinfo/python-list

[Terry Hancock]

On Thu, 02 Mar 2006 16:38:44 -0500
Roy Smith <roy@...> wrote:

> In article <8SINf.1718$No6.40137@...>,
>  John Salerno <johnjsal@...> wrote:
> > 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

--
Terry Hancock (hancock@...)
Anansi Spaceworks http://www.AnansiSpaceworks.com

--
http://mail.python.org/mailman/listinfo/python-list

[Paul Rubin-3]

John Salerno <johnjsal@...> writes:
> 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.
--
http://mail.python.org/mailman/listinfo/python-list

[Thomas G. Willis]

On 3/2/06, Terry Hancock <hancock@...> wrote:

On Thu, 02 Mar 2006 16:38:44 -0500
Roy Smith <roy@...> wrote:

> In article <8SINf.1718$No6.40137@...>,
>  John Salerno <johnjsal@...> wrote:
> > 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

Bruce Eckel began writing "Thinking In Python" it was last updated in 2001.

He's a busy dude with a lot on his plate, so finishing it or updating it isn't known.

I emailed him once about it and actually got a cordial reply which amounted to,..."I have no time but I'd love to finish it"

But, the draft does have some interesting tidbits in it and it's worth a look I think. You def. get the message that patterns apply a lot differently in python as compared to the {...;} languages.

Details here.

http://mindview.net/Books/Python/ThinkingInPython.html



--
Thomas G. Willis
-----------------------------------------------
http://i-see-sound.com
http://tomwillis.sonicdiscord.com
America, still more rights than North Korea



--
http://mail.python.org/mailman/listinfo/python-list

[Roy Smith]

In article <7x8xrs9xqb.fsf@...>,
 Paul Rubin <http://phr.cx@...> wrote:

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

Example?
--
http://mail.python.org/mailman/listinfo/python-list

[Paul Rubin-3]

Roy Smith <roy@...> writes:
> > Somewhat less often, something is easy in Java and difficult in
> > Python.
> Example?

Sandboxed code is a real obvious one.
--
http://mail.python.org/mailman/listinfo/python-list

[Roy Smith]

In article <7xirqwz5ye.fsf@...>,
 Paul Rubin <http://phr.cx@...> wrote:

> Roy Smith <roy@...> writes:
> > > Somewhat less often, something is easy in Java and difficult in
> > > Python.
> > Example?
>
> Sandboxed code is a real obvious one.

What is "sandboxed code"?
--
http://mail.python.org/mailman/listinfo/python-list

[Paul Rubin-3]

Roy Smith <roy@...> writes:
> > Sandboxed code is a real obvious one.
> 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.
--
http://mail.python.org/mailman/listinfo/python-list

[Paul Rubin-3]

"ajones" <ajones1@...> writes:
> 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
--
http://mail.python.org/mailman/listinfo/python-list

[Gene Tani]

Terry Hancock wrote:

>
> This sounds like an article crying out to be written,
> "(Learning) Design Patterns with Python".
>
> Has it been written already?
>
> Cheers,
> Terry
>
> --
> Terry Hancock (hancock@...)
> Anansi Spaceworks http://www.AnansiSpaceworks.com

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/conferences/pycon2005/20050323/Design%20Patterns%20and%20Python%20OOP%20-%20Objects%20By%20Design.html

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

--
http://mail.python.org/mailman/listinfo/python-list

[Bruno Desthuilliers-3]

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...
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@...'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list

[Paul Boddie]

Paul Rubin wrote:
> Roy Smith <roy@...> writes:
> > > Somewhat less often, something is easy in Java and difficult in
> > > Python.
> > Example?
>
> 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"

--
http://mail.python.org/mailman/listinfo/python-list

[Nick Craig-Wood]

ajones <ajones1@...> wrote:
>  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.

;-)

--
Nick Craig-Wood <nick@...> -- http://www.craig-wood.com/nick
--
http://mail.python.org/mailman/listinfo/python-list

[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.

--
http://mail.python.org/mailman/listinfo/python-list

[Roy Smith]

In article <1141394593.588174.321660@...>,
 "msoulier" <msoulier@...> wrote:

> 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.
--
http://mail.python.org/mailman/listinfo/python-list