Live data from Hacker News

Design patterns you should unlearn in Python

lihil.cc

1–10 of 110 posts

Re: Design patterns you should unlearn in Python

#7

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

An example of the Builder pattern in the wild: https://github.com/bikram990/PyScep/blob/8d80bc03368ea8dc6ea...

...especially annoying if it's only used in one continuous chain: https://github.com/bikram990/PyScep/blob/8d80bc03368ea8dc6ea...

Re: Design patterns you should unlearn in Python

#8
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.

> than in any other programming language After reading the article, I couldn't believe anyone designs their systems like that. His "solutions" seemed to be the obvious way to do things.

Re: Design patterns you should unlearn in Python

#9

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

It's more like "if switching from Java to Python". I've also never seen anyone writing Python do this.

I've seen a person using in Perl Singleton classes, Factory classes and other Java patterns. The app worked well but the code was probably 2x large than it could be.

Re: Design patterns you should unlearn in Python

#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.
Post reply on HN