I've started reading the design pattern book by the GoF. Some patterns seem very similar with only minor conceptual differences.

Do you think out of the many patterns some are unnecessary in a dynamic language like Python (e.g. because they are substituted by a dynamic feature)?

  • 2
    Kind of an interesting question, since it implies that language choice can effectively substitute for code constructs. Commented Jul 24, 2012 at 21:11
  • 3
    Not an answer, but relevant - I thought the GoF design patterns were as relevant for some general principles that can be distilled out of them as for the specific patterns. I don't mean the idea of a pattern (though that's certainly significant), but more the permission to use classes in certain ways that violate naive OOP principles. For example, there's plenty of patterns where "the shape" quite clearly does not "draw itself", or at least delegates some aspect of the job to some other object. I think that lesson is important in any language that supports OOP.
    – user8709
    Commented Jul 29, 2012 at 19:19
  • Very interesting question. I wish I could +5 instead of +1.
    – MathAttack
    Commented Aug 2, 2012 at 11:27
  • 1
    Glance aslo at Are Design Patterns Missing Language Features and Design Patterns Are Missing Language Features over at c2. Its not even a 'dynamic language' issue. The simplest example is the iterator pattern which is trivial in python, perl (and even Java - not dynamic).
    – user40980
    Commented Oct 17, 2012 at 14:30

8 Answers 8


Peter Norvig demonstrates that 16 out of the 23 design patterns found in the GOF book are invisible or simpler in dynamic languages (he focuses on Lisp and Dylan).

Since you mentioned Python, there is a nice presentation by Alex Martelli about the topic. Also related with Python, there is a nice blog post demonstrating six design patterns in idiomatic Python.

I also keep a github repository with implementations (by other people) of the most common design patterns in Python.

  • Great! That would be a spot on answer :) I wished everyone had grasped the question that clearly.
    – Gere
    Commented Jul 25, 2012 at 8:55
  • 2
    According to Norvig, 2 of the 16 (Interpreter and Iterator) are "either invisible or simpler" due to macros (which Python doesn't have).
    – mjs
    Commented Jul 29, 2012 at 21:19
  • 1
    its not clear to me that all these patterns aren't need because lisp is dynamic but rather because of other features such as being a strong functional language
    – jk.
    Commented Oct 10, 2012 at 14:20
  • 1
    @faif Norvig's paper was written in 1996, before Python had iterators. (It seems they arrived in version 2.1 python.org/dev/peps/pep-0234/.)
    – mjs
    Commented Oct 15, 2013 at 11:02
  • 1
    This great answer can be even slightly improved by changing the somewhat meaningless link captions demonstrates, presentation and repository - they are far better then here, but, you know... :-)
    – Wolf
    Commented Jan 8, 2015 at 11:47

No design patterns are necessary. In any language.

I tend to come across a lot of code written by people who read up on design patterns and then think they should use them all over the place. The result is that the actual code gets buried under tons of interfaces, wrappers and layers and is pretty hard to read. That's a wrong approach to design patterns.

Design patterns exist so that you have a repertoire of useful idioms handy when you come across a problem. But you should never apply any pattern before you identify the problem. Keep It Simple Stupid should always be the superior governing principle.

It also helps to think of design patterns as a concept to think about the problem rather than specific boilerplate code to write. And about much of the boilerplate as workaround to Java lacking free functions and standard function objects that you use in most other languages that have them (like Python, C#, C++ etc).

I might say that I have a visitor pattern, but in any language with first class functions it will be just a function taking a function. Instead of factory class I usually have just a factory function. I might say I have an interface, but then it's just a couple of methods marked with comments, because there wouldn't be any other implementation (of course in python an interface is always just comments, because it's duck-typed). I still speak of the code as using the pattern, because it's a useful way to think about it, but don't actually type in all the stuff until I really need it.

So learn all the patterns as concepts. And forget the specific implementations. The implementation varies, and should vary, in the real world, even just in Java.

  • 29
    Your opening statement is oversimplifying to the extreme. It is true that patterns have their cost, so shouldn't be used blindly, just for the sake of it. But in the right place, they can be a great help. And yes, they are language specific - some patterns are unnecessary in some languages because the language itself supports a better approach. But that is still pretty far from your opening claim. Commented Jul 24, 2012 at 8:39
  • 2
    Btw Visitor is not entirely replaced by higher order functions - it is a solution to implement double dispatch in a language which doesn't natively support it (such as C# and C++). (And it should indeed be used very sparingly - I consider it one of the most arcane and costly patterns whose usage is IMHO so hard to justify that I myself have never used it up to now.) Commented Jul 24, 2012 at 8:44
  • 14
    Well, you never need a pattern. What you need is to solve a problem. If you don't know any pattern for it, you can still solve it, it will take more thinking and you may come up with a solution that matches some pattern or one that does not. Knowing the patterns just makes it easier.
    – Jan Hudec
    Commented Jul 24, 2012 at 9:18
  • 4
    @Gerenuk: Yes, but the point is, that the patterns are not language-specific, they are for your head. You often find that some pattern is realized much more easily and using different tools in python, but the same concept usually exists.
    – Jan Hudec
    Commented Jul 24, 2012 at 9:23
  • 4
    @PéterTörök: Visitor is not replaced by anything. The point is the same concept might be implemented using different tools in different cases, but I still consider it the same pattern.
    – Jan Hudec
    Commented Jul 24, 2012 at 9:25

Abstract factory pattern is unnecessary in duck-typed language such as Python, as it's practically built into the language.

  • 10
    well, you still need different factories. You just don't need the interface definition. Commented Jul 24, 2012 at 14:26
  • 1
    If you have a class, you have a factory already. Classes are first class objects and can be passed around everywhere and simply called to create an object (unlike Java). You don't need to create anything else. If you want something that is not the default constructor, just create a lambda/callable of some kind that wraps the constructor in some way. Commented Dec 29, 2017 at 10:41

The only one that comes to mind is the Singleton pattern.

Since Python doesn't force you to use classes for everything, you can just use a global data structure instead. That global data structure could be managed by an instance, but you do not have to control the instantiation of that class, you just create the instance on import and leave it at that.

Mostly, Singletons in python are replaced with a module. Modules in python are by their very nature Singletons; the python interpreter creates these once and once only.

All other patterns in Design Patters I've used in Python at one time or another, and you'll find examples of them throughout the Python standard library and in Python itself.

  • 2
    Isn't that actually an anti-pattern these days?
    – Den
    Commented Jul 24, 2012 at 8:00
  • 16
    The Singleton is an antipattern. In all languages. It was created to solve several unrelated problem and is not a good match for either (note, that even Java has static members, that exist once per class, so you don't need an instance for that).
    – Jan Hudec
    Commented Jul 24, 2012 at 8:00
  • 1
    And in Python we never bothered with it as there never was a problem to solve. Commented Jul 24, 2012 at 8:12
  • 2
    "Python doesn't force you to use objects for everything" Not true. It's just not obnoxious as in Java, but still, in Python everything is an object. Even module is an object.
    – vartec
    Commented Jul 24, 2012 at 10:37
  • 3
    @Darthfett: I am well aware of how len works; Guido made an explicit choice here. My point is to show that Python is not a pure OOP language; it is a pragmatic language. I like it that way. Commented Jul 24, 2012 at 14:58

Design patterns are for the programmer, not for the language. Programmers tend to use patterns that help them make sense of the problem at hand. No design pattern is strictly necessary, but it may be of use to help simplify what you're trying to do.

Python, and duck typing specifically, does provide an end around a lot of common patterns and practices, and a lot of the restrictions imposted by some patterns (privacy, immutability, etc) only hold to the extent that the programmer agrees not to break them. But still, they do work as long as the programmer plays along. A door is still a door, even if it's framed by imaginary walls.

Python is considered a "multi-paradigm" language; you can use whatever patterns you want. This is intentional. It provides for complex class hierarchies, for example, even though they're completely unnecessary and a bit artificial. But for some people that particular abstraction is helpful. Not because the problem demands it, but because the programmer does. So there you go.

  • That's certainly interesting. So which patterns in particular do you mean that one might forget about, because there are better ways in Python?
    – Gere
    Commented Jul 24, 2012 at 8:49

The original "Design Patterns" book documented and named some common idioms useful in imperative, object-oriented languages such as C++ and Smalltalk. But Smalltalk is a dynamically typed language, so it can't be strictly a matter of being dynamic.

However, the answer to your question is still "yes": some of these design patterns will be irrelevant to modern dynamically typed languages. More generally, there will be different design patterns in different languages, especially in different kinds of languages.

To reiterate: a "design pattern" is simply a name for a programming idiom: a common solution to a frequently encountered problem. Different languages require different idioms, because what is a problem for one language may be trivial for another. In this sense, design patterns tend to point out weaknesses in the languages they apply to.

So, you might look for other features which make modern dynamic languages (or ancient ones like Lisp) more powerful, rendering some of these classic design patterns irrelevant.


Design patterns are ways of solving particular problems. If a problem is not met, pattern of resolving it has no use.

People are trying to adapt design patterns everywhere as if it was a best practice to have design patterns in your project. That's other way around. You encounter a problem that can be solved with a factory pattern? Cool. Adapt it. Don't look up your code and try to find the right place to implement a singleton (or factory, or facade, or whatever ...).

Perhaps Python has its own design patterns not available for Java and .NET people (due to nature of these languages)?


I would say that patterns are always language dependent. That most python patterns look like those defined in GoF it's because of the OOP of Python, that being said OOP is not like OOP (no two languages define objects and their manipulation 100% alike).

So there's no doubt some patterns will not be applicable "as is", some might make no sense and there are some patterns that might be only be meaningful to Python.

To get back exactly at your question: Patterns are only necessary if you need them. You don't have to use them if there's no need for them (as Jan Hudec already said).

Furthermore, there are much more patterns than those mentioned in GoF. See in wikipedia other patterns

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.