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

31–40 of 110 posts

Re: Design patterns you should unlearn in Python

#31

Post by seadan83 »

taylorallred wrote: post #10

I really appreciate how this article explains why certain design patterns became a thing. Usually, it was to address some very practical problem or limitation. And yet, a lot of younger programmers treat these patterns like a religious dogma that they must follow and don't question if they really make sense for the specific situation they are in.

> a lot of younger programmers treat these patterns like a religious dogma

First you learn what the pattern is. Then you learn when to use it. Then you learn when not to use it.

The gap between the first and third step can be many years.

Re: Design patterns you should unlearn in Python

#32

Post by mrweasel »

tayo42 wrote: post #14

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.

Rarely have I seen a class that truly needs 20 parameters, that's most often a design flaw. There might be cases where this isn't true, but those are edge cases, so it's probably also fine to apply a special patterns, such as the builder pattern.

Re: Design patterns you should unlearn in Python

#33

Post by arcanemachiner »

seadan83 wrote: post #31
taylorallred wrote: post #10

I really appreciate how this article explains why certain design patterns became a thing. Usually, it was to address some very practical problem or limitation. And yet, a lot of younger programmers treat these patterns like a religious dogma that they must follow and don't question if they really make sense for the specific situation they are in.

> a lot of younger programmers treat these patterns like a religious dogma First you learn what the pattern is. Then you learn when to use it. Then you learn when not to use it. The gap between the first and third step can be many years.

> The gap between the first and third step can be many years.

I admire your optimism!

Re: Design patterns you should unlearn in Python

#34

Post by mrweasel »

AtlasBarfed wrote: post #25
mrweasel wrote: post #17

Earlier quoted context omitted.

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 pa…

How does Python do mocking if it doesn't use singletons? Or do people just not do unit testing in Python using spock-like technology? And I do use the word technology because Spock is that much better than just a bunch of test scripts

You can overwrite pretty much anything in Python at runtime, and the mock tooling in the standard library can help you with that, if you can't straight up just override a method or object.

Re: Design patterns you should unlearn in Python

#35

Post by ddejohn »

the__alchemist wrote: post #15

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.

Everything in the codebase I maintain at my job is an arbitrary dict and there is no type information anywhere. It wasn't even written that long ago (dataclasses were a thing long before this codebase was written).

There's actually a place where the original authors subclassed dict, and dynamically generate attributes of a "data class" such that it can be used with dotted attribute access syntax or dict access syntax but the `__slots__` attribute of these classes is also generated dynamically so you don't have any auto-complete when trying the dotted attribute access. It's genuinely insane lol.

Re: Design patterns you should unlearn in Python

#36

Post by motorest »

Kuraj wrote: post #21

Great post. Now let's do C# because if I see a repository pattern doing nothing but calling Entity Framework under the hood again I'm going to rip the planet in half

> Great post. Now let's do C# because if I see a repository pattern doing nothing but calling Entity Framework under the hood again I'm going to rip the planet in half

Your comment shows a hefty amount of ignorance. Repositories wrap Entity Framework because Entity Framework's DbContext & Co are notoriously complicated to mock and stub.

Once you wrap EF stuff with a repository that implements an interface, that problem vanishes and all your code suddenly is unit testable.

Re: Design patterns you should unlearn in Python

#37

Post by motorest »

NeutralForest wrote: post #11

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.

> I've never seen anybody do that...

I feel the blog post is a bunch of poorly thought through strawmen. I was browsing through the singleton example and I was wondering why would anyone use buggy code to implement something it clearly was not designed to implement.

The whole article is quite subpar. I was expecting idiomatic stuff that eliminated the need to implement something, like for example implementing singletons with modules and even getter functions, but there was none of that: just strawmen.

Really disappointing.

Re: Design patterns you should unlearn in Python

#38

Post by acedTrex »

I don't agree with the builder pattern. For basic objects yes its a bit silly.

But the ACTUAL value of the builder pattern is when you want to variadically construct an object. Create the base object, then loop or otherwise control flow over other state to optionally add stuff to the base object.

Then, additionally, the final "build" call can run validations over the set of the complete object. This is useful in cases where an intermediate state could be invalid but a subsequent update will update it to a valid state. So you dont want to validate on every update.

Re: Design patterns you should unlearn in Python

#39

Post by kccqzy »

taylorallred wrote: post #10

I really appreciate how this article explains why certain design patterns became a thing. Usually, it was to address some very practical problem or limitation. And yet, a lot of younger programmers treat these patterns like a religious dogma that they must follow and don't question if they really make sense for the specific situation they are in.

I don't however appreciate that the author doesn't actually know about Java or C++ well enough such that they are spewing falsehoods about Java or C++. Saying things like "There’s no clean way to say 'this is private to this file' (in C++)" is just bonkers. The author is well intentioned, but coming up with the wrong reason is worse than not offering any reason.

Re: Design patterns you should unlearn in Python

#40

Post by pbh101 »

ddejohn wrote: post #28
necovek wrote: post #24

Earlier quoted context omitted.

Module-level initialization has one huge problem in Python, though. That means that as soon as you import a module, initialization happens. Ad infinitum, and you get 0.5s or more import times for libraries like sqlalchemy, requests...

yep, the legacy codebase I maintain does a lot of this kind of stuff and has made it difficult to write unit tests in some cases due to all the code that runs at import and all the state we end up with

The article addresses this.
Post reply on HN