Patterns in Python | Hacker News Reader

Patterns in Python

suttoncourtenay.org.uk

63 pointslimist24 comments

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/

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.

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.

You're right, of course. It's all about operating at a suitable level of abstraction; any technique can be misapplied.

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.

The problem is a lack of thoroughly comprehending the ideas. This results in people over using design approaches in situations where they aren't necessarily applicable, or where alternatives would simply be better suited.

I don't think pointing someone who does not realize that the strategy pattern can be accomplished by passing around functions since they are first class objects at a dynamic language DP tutorial is going to do anything more than give them different ideas to misuse.

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.

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"

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?

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

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.

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.

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.

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.

Looks like decorators were after the article was written:

http://www.python.org/dev/peps/pep-0318/

E.g. 2/28/2003 vs 6/5/2003

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.

Or just use modules. Seriously, it is a true singleton.

I just use classes, so I'm not sure what you took my meaning to be. I'm certainly not requiring the singleton library.

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.

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.

In the general case, yes. Unfortunately, due to some quirks in the module loader, assigning bar right inside foo might not yield the expected result, though.

This is actually one of the python warts that annoys me the most.

Thank you for explaining. :)

> No matter how many times you import foo

Just don't reload it.

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();"?

    from foo import bar

Reply on news.ycombinator.com