Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Design patterns you should unlearn in Python

lihil.cc

Post reply on HN
Print view View original

11–20 of 110 posts

Re: Design patterns you should unlearn in Python

#11

Post by NeutralForest »

I've never seen anybody do that... In Python you can use a module as a singleton (mentioned in the article). Or provide some data like:

  from functools import lru_cache

  class Whatever:
      pass

  @lru_cache(maxsize=1)
  def get_whatever():
      return Whatever()
And use `get_whatever` as your interface to get the resource.

Re: Design patterns you should unlearn in Python

#13

Post by nhumrich »

aswerty wrote: post #6

The Zen of Python: there should be one obvious way to do things. Python in practice: there is more ways of doing it than in any other programming language. Oh Python, how I love and hate you.

People misunderstand the target audience and code base for the zen of python

Re: Design patterns you should unlearn in Python

#14

Post by tayo42 »

I was writing a python thing where the class was going to have like at least 20 paramaters to configure it. Builder pattern was kind of feeling like a good idea to keep it cleaner for the user. But it is surprising to see in the python world. It felt like a mess of default values though for the user to handle.

Re: Design patterns you should unlearn in Python

#15

Post by the__alchemist »

All good ones. I'll add this because A: It's common in Python, and B: There are suitable alternatives in the standard library:

Conflating key/value lookups (dicts) with structured data (classes). They are both useful tools, but are for different purposes. Many python programmers (Myself many years ago included!) misused dicts when they should have been using dataclasses.

Re: Design patterns you should unlearn in Python

#17

Post by mrweasel »

wodenokoto wrote: post #2

I like the concept of the article but I’m not sure I’ve seen these in the wild.

The singleton one is one I've attempted, and no, it doesn't work well in Python. Early in my career I worked on a number of projects where the architects had used a singleton pattern for a number of things. The pattern sort of stuck in my head, but this was in C# and I've mostly worked in Python ever since. As the article points out it's designed for language like Java and C++ (and C#).

In my opinion the singleton pattern does however not make Python code harder to test. In Python it's actually extremely handy, because its incredibly easy to mock out a singleton in your test cases.

Re: Design patterns you should unlearn in Python

#18

Post by shawn_w »

tptacek wrote: post #5

Peter Norvig has a well-known piece that goes into more depth on why the GoF-style patterns don't make much sense in high-level languages: https://www.norvig.com/design-patterns/

Those slides would be a lot more useful with a transcript of the talk that went along with them. Or a video of it. Wonder if anything like that still exists.

Re: Design patterns you should unlearn in Python

#19

Post by zelphirkalt »

I have observed these "design pattern shoehorned into Python" so many times ... Great post. When you see these things done in a code base, you know that you got people, who would rather want to write Java working on it. Or maybe people who don't have the feel for Python as a language or something.

First thing I looked up in the article was "singleton", as a sanity check, whether the article is any good. And yes, it shows module level binding as alternative, exactly what I expected, because I looked into this in the past, when someone implemented API client singleton, in a case of irrelevant early optimization of something that was never a bottleneck.

Articles like this are helpful in spreading the awareness, that one should not hold a Python like one holds a Java.

Re: Design patterns you should unlearn in Python

#20

Post by AtlasBarfed »

Builder patterns are seriously useful for high complexity state construction with the ability to encore rules to prevent degenerate state.

A good example from my experience might be connecting to a Cassandra cluster it other type of database that can have extremely complex distributed settings and behaviors: timeouts, consistency levels, failure modes, retry behavior, seed connector sets.

Javaland definitely had a problem with overuse of patterns, but the patterns are legitimate tools even outside of Oop.

I haven't done much research into testing frameworks in other languages, but the spock testing framework in groovy/javaland is a serious piece of good software engineering that needs singletons and other "non hard coded/not global" approaches to work well.

Spring gets a ton of hate outside of jabs, and I get it, they tried to subsume every aspect of programming and apis especially web into their framework, but the core spring framework solved complex object graph construction in a very effective way

Oh you hate "objects" but have thousand line struct graph construction code?

It's kind of sad that groovy never took off. It offered all the good parts of java with a ton of good python, ruby, and other langs with the solid foundation of the jvm for high speed execution.

But it's effectively dead. Kind of like Cassandra is effectively dead. The tech treadmill will eventually leave you behind.

Post reply on HN