5 ms·

Patterns in Python

63 points by limist 16y ago

torial 16y ago
At the very bottom: View document source. Generated on: 2003-02-28 11:59 UTC. I was thinking I'd seen this before -- a long time ago. How much still applies?
- limist 16y ago
  I was wondering the same thing, given python 2.6 and 3.1, and leafing through the GoF book lately. Exploring that line of inquiry would make for a good article (or two, or more).
- digitallogic 16y ago
  It's level of applicability (which I don't think is much to be honest) hasn't really change as Python (the language) has not changed all that much in that time. There's been a handful of syntactic changes (new keywords, exception handling, etc) and some additional protocols (such as with statement), but the fundamentals of the language have not change (dynamically, strongly typed language with first class functions/types). Design pattern are conceptual implementation strategies and not components, therefore only fundamental language paradigm changes could (should?) make them no longer applicable for the most part.
SlyShy 16y ago
Interesting. I sort of assumed Python had singletons natively, because I'm so used to using them in Ruby. This guy doesn't do it here, but you can make singletons relatively painless in Python by using decorators.
- torial 16y ago
  Looks like decorators were after the article was written: http://www.python.org/dev/peps/pep-0318/ http://www.python.org/dev/peps/pep-0318/ E.g. 2/28/2003 vs 6/5/2003
  - SlyShy 16y ago
    Yeah, it wasn't meant as a criticism of the article. More of a "Python can do nice things too" shout out to other Rubyists. I don't know about them, but I find myself translating code between Ruby and Python for various reasons and it is nice to learn the parallels in idioms and such. So, upvoted.
- sophacles 16y ago
  Or just use modules. Seriously, it is a true singleton.
  - SlyShy 16y ago
    I just use classes, so I'm not sure what you took my meaning to be. I'm certainly not requiring the singleton library.
    - sophacles 16y ago
      A module is a singleton. No matter how many times you import foo, the namespace foo is always the same. If you reassign foo.bar in in code in module x, then later access foo.bar from module y, it will be the value assigned in X. This is not amenable to inheritance tho, however there is a strong argument against inheritance in singletons anyway. Further, the borg pattern is considered "more pythonic" in the case of inheritable singletons, as frequently what is desired in such cases is shared state vs instead of shared identity.
      - SlyShy 16y ago
        Thank you for explaining. :)
      - njharman 16y ago
        > No matter how many times you import foo Just don't reload it.
        sophacles 16y ago
        Well, as far as I am concerned, if import foo is the same as instantiating foo, then reload is calling destructor then instantiation again. How is this worth comment? In a discussion of c++ singletons would you comment "Just dont call delete fooptr; fooptr = new foo();"?
        mdg 16y ago
        from foo import bar
tptacek 16y ago
If you're a Python (or Ruby) dev, and this stuff is interesting to you, that's a symptom of a problem. The problem is that you haven't read this: http://norvig.com/design-patterns/ http://norvig.com/design-patterns/
- mace 16y ago
  Agreed, this feels vaguely like writing Java or C# in Python. If you're coming from one of those languages it's more useful to learn how Python (or Ruby or JavaScript for that matter) solves these problems rather applying those patterns to Python.
- regularfry 16y ago
  If your point is that design patterns only exist because of insufficiently powerful languages, I disagree. Iterator and Strategy, for instance, are useful concepts to be able to talk about in any language, no matter whether they're first-class or not, or how simple the implementation is. If you've got a bunch of lambdas that define alternative ways to accomplish the same end, then why the hell not call them Strategies? I'd also take issue with the implication that Python is powerful enough for the common patterns to disappear completely. it doesn't have macros, for a start, so implementing coupled Strategies of any complexity means you're back in class FooStrategy() land. Recognising when you are or should be implementing a recognised pattern means that you can rely on a lot of analysis of that pattern, largely without paying attention to the environment in which that analysis was performed. That's potentially a big win. I guess what I'm getting at is that throwing away patterns means throwing away a decent lingua franca for talking about the anatomy of your code. Given that, as someone far smarter than me once said, code is primarily for humans to read and only incidentally for computers to execute, that seems like a poor decision.
  - tptacek 16y ago
    While recognizing the validity of your argument I am having a hard time resisting the urge to point out that we are commenting on code that uses the "Observer pattern" to construct a class hierarchy with accessors for "second", "minute", and "hour" to implement a "digital clock". The code in this article confirms the suspicion of pattern skeptics that GoF-style patterns lead to code constructed out of pick-and-mix patterns instead of actual sensible code.
cubes 16y ago
I'm really glad the article includes a warning against trying not to overuse design patterns. I sometimes wonder if teaching design patterns causes people to rely on pattern matching as a crutch, and hampers the development of creative thinking skills required to solve new engineering problems.
- digitallogic 16y ago
  I used to be of a similar mindset, that tools/ideas/practices should possibly be avoided as they can sometimes have a negative affect on people who don't fully comprehend them (such as using design patterns when they're not applicable or where an alternative design would prove to be a better fit). However, I've since come to believe that it's not the ideas that are harmful, it's the people that use them without comprehending them. If this is the case, avoiding a concept that would provide benefit is limiting yourself without any benefit as the people that would misuse them will probably find something else to screw up anyway. Or, to put it more succinctly: "You can write Fortran in any language"
dkarl 16y ago
These are patterns from the GoF book. Learning to use these patterns in Python is like learning Esperanto so you can pray. Python doesn't need these patterns any more than God needs you to speak Esperanto.
- limist 16y ago
  Well yes, arguably learning Esperanto and speaking it for any purpose is already a sincere form of prayer. :) Python may not "need" these patterns, but python programmers might. At the minimum, I find it useful to know how design patterns from Java, Smalltalk, etc. are done in Python, especially if it gives me bragging rights that a pattern can be implemented in a fraction of the LoC needed for those other languages.

63 points by limist 16y ago

At the very bottom: View document source. Generated on: 2003-02-28 11:59 UTC. I was thinking I'd seen this before -- a long time ago. How much still applies?

limist 16y ago
I was wondering the same thing, given python 2.6 and 3.1, and leafing through the GoF book lately. Exploring that line of inquiry would make for a good article (or two, or more).
digitallogic 16y ago
It's level of applicability (which I don't think is much to be honest) hasn't really change as Python (the language) has not changed all that much in that time. There's been a handful of syntactic changes (new keywords, exception handling, etc) and some additional protocols (such as with statement), but the fundamentals of the language have not change (dynamically, strongly typed language with first class functions/types). Design pattern are conceptual implementation strategies and not components, therefore only fundamental language paradigm changes could (should?) make them no longer applicable for the most part.

SlyShy 16y ago

Interesting. I sort of assumed Python had singletons natively, because I'm so used to using them in Ruby. This guy doesn't do it here, but you can make singletons relatively painless in Python by using decorators.

torial 16y ago
Looks like decorators were after the article was written: http://www.python.org/dev/peps/pep-0318/ http://www.python.org/dev/peps/pep-0318/ E.g. 2/28/2003 vs 6/5/2003
- SlyShy 16y ago
  Yeah, it wasn't meant as a criticism of the article. More of a "Python can do nice things too" shout out to other Rubyists. I don't know about them, but I find myself translating code between Ruby and Python for various reasons and it is nice to learn the parallels in idioms and such. So, upvoted.
sophacles 16y ago
Or just use modules. Seriously, it is a true singleton.
- SlyShy 16y ago
  I just use classes, so I'm not sure what you took my meaning to be. I'm certainly not requiring the singleton library.
  - sophacles 16y ago
    A module is a singleton. No matter how many times you import foo, the namespace foo is always the same. If you reassign foo.bar in in code in module x, then later access foo.bar from module y, it will be the value assigned in X. This is not amenable to inheritance tho, however there is a strong argument against inheritance in singletons anyway. Further, the borg pattern is considered "more pythonic" in the case of inheritable singletons, as frequently what is desired in such cases is shared state vs instead of shared identity.
    - SlyShy 16y ago
      Thank you for explaining. :)
    - njharman 16y ago
      > No matter how many times you import foo Just don't reload it.
      - sophacles 16y ago
        Well, as far as I am concerned, if import foo is the same as instantiating foo, then reload is calling destructor then instantiation again. How is this worth comment? In a discussion of c++ singletons would you comment "Just dont call delete fooptr; fooptr = new foo();"?
      - mdg 16y ago
        from foo import bar

tptacek 16y ago

If you're a Python (or Ruby) dev, and this stuff is interesting to you, that's a symptom of a problem. The problem is that you haven't read this: http://norvig.com/design-patterns/ http://norvig.com/design-patterns/

mace 16y ago
Agreed, this feels vaguely like writing Java or C# in Python. If you're coming from one of those languages it's more useful to learn how Python (or Ruby or JavaScript for that matter) solves these problems rather applying those patterns to Python.
regularfry 16y ago
If your point is that design patterns only exist because of insufficiently powerful languages, I disagree. Iterator and Strategy, for instance, are useful concepts to be able to talk about in any language, no matter whether they're first-class or not, or how simple the implementation is. If you've got a bunch of lambdas that define alternative ways to accomplish the same end, then why the hell not call them Strategies? I'd also take issue with the implication that Python is powerful enough for the common patterns to disappear completely. it doesn't have macros, for a start, so implementing coupled Strategies of any complexity means you're back in class FooStrategy() land. Recognising when you are or should be implementing a recognised pattern means that you can rely on a lot of analysis of that pattern, largely without paying attention to the environment in which that analysis was performed. That's potentially a big win. I guess what I'm getting at is that throwing away patterns means throwing away a decent lingua franca for talking about the anatomy of your code. Given that, as someone far smarter than me once said, code is primarily for humans to read and only incidentally for computers to execute, that seems like a poor decision.
- tptacek 16y ago
  While recognizing the validity of your argument I am having a hard time resisting the urge to point out that we are commenting on code that uses the "Observer pattern" to construct a class hierarchy with accessors for "second", "minute", and "hour" to implement a "digital clock". The code in this article confirms the suspicion of pattern skeptics that GoF-style patterns lead to code constructed out of pick-and-mix patterns instead of actual sensible code.

cubes 16y ago

I'm really glad the article includes a warning against trying not to overuse design patterns. I sometimes wonder if teaching design patterns causes people to rely on pattern matching as a crutch, and hampers the development of creative thinking skills required to solve new engineering problems.

digitallogic 16y ago
I used to be of a similar mindset, that tools/ideas/practices should possibly be avoided as they can sometimes have a negative affect on people who don't fully comprehend them (such as using design patterns when they're not applicable or where an alternative design would prove to be a better fit). However, I've since come to believe that it's not the ideas that are harmful, it's the people that use them without comprehending them. If this is the case, avoiding a concept that would provide benefit is limiting yourself without any benefit as the people that would misuse them will probably find something else to screw up anyway. Or, to put it more succinctly: "You can write Fortran in any language"

dkarl 16y ago

These are patterns from the GoF book. Learning to use these patterns in Python is like learning Esperanto so you can pray. Python doesn't need these patterns any more than God needs you to speak Esperanto.

limist 16y ago
Well yes, arguably learning Esperanto and speaking it for any purpose is already a sincere form of prayer. :) Python may not "need" these patterns, but python programmers might. At the minimum, I find it useful to know how design patterns from Java, Smalltalk, etc. are done in Python, especially if it gives me bragging rights that a pattern can be implemented in a fraction of the LoC needed for those other languages.