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

71–80 of 110 posts

Re: Design patterns you should unlearn in Python

#71

Post by dragonwriter »

layer8 wrote: post #69
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.

The main motivation for the concept of design patterns is to give unique names to existing programming patterns, so that when someone says “Strategy pattern”, everyone knows what pattern that refers to, and vice versa that the same pattern isn’t called ten different things. It’s to make communication about program design efficient, by defining a vocabulary of patterns that tend to reoccur, and a common structure for…

> The main motivation for the concept of design patterns is to give unique names to existing programming patterns

No, naming them is not the main purpose, preserving and transmitting knowledge of what they are and what they are useful for, so that people aren't fofced to rediscover solutions to the same problems over and over again. [0] Naming is obviously important for that purpose, but isn't the main goal, but a means of supporting it.

[0] If this sounds like a subset of the purpose of a reusable code library, it is, which is why in languages with sufficient abstraction facilities to allow the generic implementation of a pattern to be reusable, well documented (for the “where and when to use this” piece) code libraries replace documents that have the explanation paired with implementation recipes that one can modify to one’s particular use.

Re: Design patterns you should unlearn in Python

#72

Post by zem »

acedTrex wrote: post #38

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

I've used the builder pattern in python when I wanted to have the mutable and immutable version of a class be different types. you do a bunch of construction on the mutable version then call "freeze" which uses the final data to construct the "immutable" class.

Re: Design patterns you should unlearn in Python

#73

Post by catlover76 »

? I read the first example and it's dumb.

> What happened? Well, it turns out you’re always getting the same instance, no matter what parameters you pass. Your second call to Singleton(name="Bob", age=25) didn’t create anything new — it just silently reused the original object, with its original attributes. No warning. No error. Just quietly wrong.

It's not wrong, it's right. No shit it "didn't create anything new"--it's not supposed to. It's a Singleton.

Re: Design patterns you should unlearn in Python

#74

Post by mekoka »

If I had but one design pattern I would just LOVE to see disappear from Python, it's the need for super(). Don't get me wrong, super() is a clever piece of engineering, but if your code actually needs what it's useful for (C3 linearization, MRO, etc), then you've made things too complicated. I deplore the proliferation of libraries that have embraced the seductive, but ultimately deceptive ways of the mixin, because they saw all the big boys reaching for it. The devil gave multiple inheritance a cooler name, some new outfits, and sunglasses to confuse the Pythonistas and they embraced it with open arms.

Refactor to favor composition over inheritance. But if you really must inherit, single over multiple, and shallow over deep. Eventually your code will less and less need super() and it'll become pointless to use it over the more explicit mechanism, which incidentally makes everything cognitively lighter.

Re: Design patterns you should unlearn in Python

#75

Post by eduardofcgo »

The programmers that insist in using type hints in python usually are the ones that makes these mistakes. I think the main reason that these patterns do not make sense is because python is a dynamic language. If you turn off the part of your brain that thinks in types you realize that you can solve most of these in plain functions and dicts. Using default args as replacement to the builder pattern is just ridiculous. If you want to encode rules for creating data, that screams schema validation, not builder pattern.

Re: Design patterns you should unlearn in Python

#76

Post by eduardofcgo »

acedTrex wrote: post #38

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

Could you not just use dicts and some schema validation logic for this?

Re: Design patterns you should unlearn in Python

#77

Post by crgwbr »

eduardofcgo wrote: post #75

The programmers that insist in using type hints in python usually are the ones that makes these mistakes. I think the main reason that these patterns do not make sense is because python is a dynamic language. If you turn off the part of your brain that thinks in types you realize that you can solve most of these in plain functions and dicts. Using default args as replacement to the builder pattern is just ridiculous.…

Python type hints are hugely valuable both as a means of correctness checking, but also just as a means of documentation. It strikes me as incredibly shortsighted to say you can forget about types just because it’s a dynamic language. The types are absolutely still there and need thought about. They just aren’t defined or used in terms of allocation and management of memory.

Re: Design patterns you should unlearn in Python

#78

Post by eduardofcgo »

ashvardanian wrote: post #26

Singletons are considered an antipattern in pretty much all PLs. C++, mentioned in the article, is not an exception.

Singleton is the worst example of design pattern, not sure why these kinds of posts always like to mention it. Singleton is just a hack for avoiding OOP with OOP languages. Obviously python allows non OOP code, so not surprised singleton is useless there.

Re: Design patterns you should unlearn in Python

#79

Post by david422 »

crgwbr wrote: post #77
eduardofcgo wrote: post #75

The programmers that insist in using type hints in python usually are the ones that makes these mistakes. I think the main reason that these patterns do not make sense is because python is a dynamic language. If you turn off the part of your brain that thinks in types you realize that you can solve most of these in plain functions and dicts. Using default args as replacement to the builder pattern is just ridiculous.…

Python type hints are hugely valuable both as a means of correctness checking, but also just as a means of documentation. It strikes me as incredibly shortsighted to say you can forget about types just because it’s a dynamic language. The types are absolutely still there and need thought about. They just aren’t defined or used in terms of allocation and management of memory.

> The types are absolutely still there and need thought about

Yes, if they aren't in the code, it just means the programmer has figure out and carry that around mentally when reading or writing code.

Re: Design patterns you should unlearn in Python

#80

Post by whilenot-dev »

e1gen-v wrote: post #59
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 do this in fast api and then pass get_whatever as a dependency to an endpoint

Alternatively you could make use of the lifespan[0] and its state[1][2].

[0]: https://fastapi.tiangolo.com/advanced/events/#lifespan-funct...

[1]: https://asgi.readthedocs.io/en/latest/specs/lifespan.html#li...

[2]: https://www.starlette.io/lifespan/#lifespan-state

Post reply on HN