Sorry to resurrect this topic. By google search the last discussion was in 2003.

I would like to find out what is the current prevailing view or consensus (if any) on the use of Design Pattern in python?

I am doing some 'fact-finding' in this area on request of my colleagues. Some of them want to buy a book or two in this subject area. Hopefully the newsgroup can give me some book recommendation and insight in this topic.

I myself pretty much subscribe to the view that the nature of python language actually do away much of the need of the use of DP, but it is just a personal view. It comes form my experience of migrating from webware4py (webframework based on J2EE/servlet idea) to cherrypy

In article
<6097694.446.1320366784098.JavaMail.geo-discussion-forums@prap37>,

What?  We're bring it up again, SO SOON!?

To a certain extent, I agree.  I don't have a huge amount of experience
in Design Patterns, but have read (years ago) the obligatory Gang Of
Four book.  My impression was that much of that book was about how to
build sane data structures to do useful things given the uber-bondage
constraints of the C++ and Java typing systems.

For example, let's look at Singleton.  It's a useful pattern.  Here's
how I would implement Singleton in Python (hand-waving a bit about the
syntax details):

class Printer:
   thePrinter = None

   @staticmethod
   def get():
      if Printer.thePrinter is None:
         Printer.thePrinter = Printer()
      return thePrinter

   def print(self):
      "print some stuff"
      whatever

That seems to cover everything Singleton needs to do.  In your
application code, you do:

myPrinter = Printer.get()
myPrinter.print(....)

and you can sleep easy knowing you've got the same Printer instance
every time.  The GoF version for C++ is filled with minutia about
private constructors and assignment operators.  All that stuff is
important to get right in C++, but it has nothing to do with Singleton,
per se.  It's just all the gunk you have to worry about to correctly
implement Singleton in C++.

I can only speak for myself, but the whole idea of design patterns is
broken. The existence of nontrivial design patterns indicates language
deficiencies. For more extensive corroborating discussions, see: http://www.codinghorror.com/blog/2005/06/are-design-patterns[..] http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures

Python thankfully has relatively few/minor deficiencies (so long as
one judges it within its dynamic language niche), so design patterns
per se aren't too relevant to it.

The canonical Python-specific design pattern is Borg
( http://code.activestate.com/recipes/66531-singleton-we-dont-[..]
) [a variation on Singleton], and nowadays it (like its parent,
Singleton) is considered to be of dubious utility/advisability.

The closest alternative would be some publication that gave examples
of using some of Python's fancier, higher-level features, such as
metaclasses and context managers. I haven't been in the market for
such a book, so I have no good recommendations to give. Closest I
could suggest would be the Language Reference
( http://docs.python.org/reference/  ) and relevant PEPs
( http://www.python.org/dev/peps/  ; they tend to include examples by
way of motivating use-cases).

I am glad you agree.

Cheers,
Chris
-- http://rebertia.com

My consensus with myself is that design patterns are language-agnostic.
If I write "class Foo serves as view and controller for class Bar in a
model-view-controller (MVC) design", everybody that knows MVC has
immediately a very high-level understanding of how those two classes
interact.

The Gang of Four book on design patterns is one you will probably come
across, and there are many that refer to it.

"webframework based on J2EE/servlet" - apart from J2EE being a specific
implementation, this also describes a design pattern, i.e. one where
(forgive me if I'm slightly off, this is not actually my field of
programming) the UI is browser-based and the program logic runs on a server.

Instead of explaining it in many words, you reused the known design
pattern to describe it, and that is also IMHO what design patterns are
about. They serve as a tool to make software that follows known
patterns, so that people that know the pattern will recognize them and
then get easier understanding. It also serves as tool when talking about
things, you don't have to explain the design when you can refer to a
pattern.

In that sense, I fully disagree that design patterns are obsolete in
Python. However, there are other patterns that are more
language-specific, like e.g. RAII in C++, so if you rather meant those,
I would agree with you.

Cheers!

Uli

I don't know of a book on design patterns in Python. I've got a couple
of observations.

The first is that if you use TDD (Test Driven Development) and
refactor relentlessly to remove duplication, most of the basic design
patterns will emerge naturally from the code as you work.

The second is that, as far as I'm concerned, the utility of a design
patterns book is in the discussion of what the pattern is good for,
and what it isn't good for. That is, as another poster says, language
agnostic.

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

I agree, and there is a pretty good series of articles on
developerWorks that covers this: http://www.ibm.com/developerworks/java/library/j-eaed2/index[..]

The author used Java in this series, but as Ulrich mentioned, I feel
that design patterns (and emergent design) are "language-agnostic.".

Well this book is work in progress https://bitbucket.org/BruceEckel/python-3-patterns-idioms/src

but it actually looks very interesting

Though not touched since May 2009

The slightly older .pdf version is a bit bizarre as parts of both text
and code are only half-translated from Java. The testing chapter
contains obviously untested code like TestDemo.py [sic] with Java lines like
    id = ++objCounter  # this is supposed to increment objCounter
    TestDemo test1 = TestDemo('test1')
    # I presume this declares test1 as a TestDemo object
and text with Javaisms like *static*, *public*, *private*, *protected*,
and *friendly* and "a little review of Java packages".

Perhaps the later sections are more useful.

--
Terry Jan Reedy

Search for presentations and videos by Alex Martelli.  He's the goto (so
to speak) person on Python design patterns.  Here, for instance:

http://code.google.com/edu/languages/#_python_patterns

--
Ned Deily,
nad*******