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
Design patterns you should unlearn in Python
21–30 of 110 posts
Re: Design patterns you should unlearn in Python
#22I 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.
Probably also a problem that exists because of how programmers are taught. Using Java and being presented with the patterns as solutions to what Java does.
Re: Design patterns you should unlearn in Python
#23The 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.
I don't think any of the examples in the article contradict the Zen of Python. Even if there's one simplest and clearest way to do it in Python, there's nothing stopping people from using a more complicated solution that they got used to while working in a different language. They might not know to look for a simpler way, because they're used to working in a language where their way is the simplest.
Re: Design patterns you should unlearn in Python
#24I 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 s…
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...
Re: Design patterns you should unlearn in Python
#25I 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 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
Re: Design patterns you should unlearn in Python
#26Singletons are considered an antipattern in pretty much all PLs. C++, mentioned in the article, is not an exception.
Re: Design patterns you should unlearn in Python
#27Great post. I dont write much python these days, but I distinctly remember things being suspiciously easy .. to the point where I started to wonder why arent things so complicated.
Re: Design patterns you should unlearn in Python
#28I 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 s…
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
Re: Design patterns you should unlearn in Python
#29I 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.
I like method chaining (not the same as builder patterns) for code that needs to run chained operations on objects. It is not exacrly the same because each chained operation usually does more than just setting a variable.
E.g.
signal = Sine(freq=440.0, amp=1.0)
.rectify()
.gain(2.0)
.center()
.clip(0.5)
That way, you get the clean chaining style and efficient, streaming computation.
Re: Design patterns you should unlearn in Python
#30The 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
Who's it for, then?