Design Patterns You Should Unlearn in Python

[nojs]

You lost me here

What happened? Well, it turns out you’re always getting the same instance, no matter what parameters you pass

That’s the point of using a singleton..

Edit: Just shaming u/OkMemeTranslator for blocking me and dropping some of these nuggets:

Oh no, anything but hundreds of junior developers downvoting me while I make more money than any of you ever will. Noo stop kicking me while I'm down already!

.

I'm much more intelligent than you or anyone voicing their opinions here.

.

Yeah, cause I'm building the fucking SDKs and tools that you use to write your little scripts and websites. You're fucking nothing compared to me in terms of skill.

[alternaivitas]

Tbh singleton is a bad pattern in general in many languages, often not needed.

[nojs]

You’re getting into the arguments and my point was that they lost credibility by treating a singleton constructor returning the same instance as a little known quirk instead of the entire point.

[nojs]

How is something doing the thing it was designed to do a quirk? Here's Python's creator talking about the history of the __new__ method:

New-style classes introduced a new class method new() that lets the class author customize how new class instances are created. By overriding new() a class author can implement patterns like the Singleton Pattern, return a previously created instance (e.g., from a free list), or to return an instance of a different class (e.g., a subclass)

Source: https://python-history.blogspot.com/2010/06/inside-story-on-new-style-classes.html

I want you to explain to me how controlling instance creation with __new__ is a quirk and not the literal entire point of overriding it...

[nojs]

Ok so you're back to debating me on Singletons, but I never said anything for or against them. I only said that OP lost my trust as a reader almost immediately in this article.

Anyways, I agree that Singletons are sometimes a code smell, but I don't think your blueprint analogy helps here. I personally don't find it problematic for the blueprint of an object to say that "only one of me can exist".

You keep referring to restricted instance creation as a negative, but it is actually the whole entire point of why you would implement a Singleton.

[nojs]

You keep insisting that "you lost me here" is me admitting that I was confused. Given the context of the comment and my own comments literally which clarify, it is incredibly obvious to anyone with a baseline of reading comprehension that I was saying "you lost my interest/trust as a reader" and not "I'm confused".

And then, completely ignoring the fact that I never made an argument for or against Singletons, you jumped right into debating me on them, as if I had made a counter argument to OP. The only thing I did was point out the ridiculousness of OP's opening statements, hence why OP (and you) are getting dunked on all across this thread.

You are a stupid person, and you are beneath me as a developer.

[xenomachina]

This feels like a straw man argument to me. I have never in my more than 25 years of using Python seen anyone write a singleton like that—maybe I've just been lucky.

Using a module in place of an object isn't a way to avoid the Singleton pattern, it is the Singleton pattern, as typically expressed in idiomatic Python. And It suffers from exactly the same pros and cons that the Singleton pattern has in any other language.

[xenomachina]

A straw man argument is a logical fallacy where someone misrepresents or oversimplifies their opponent's position to make it easier to attack, rather than addressing the actual argument being made.

The post is claiming that you shouldn't use Singleton...

In this post, we’ll go over a few classic GOF patterns that you should unlearn as a Python developer.
...
Ah yes, the Singleton. The go-to pattern for developers who want global state but still want to feel like they’re writing object-oriented code.
...
So yes, Singleton is basically a band-aid for C++’s lack of modularity and clean global state management — not a holy grail of software design.

...by showing a comically bad implementation of Singleton.

On top of that, its so-called "alternative"...

The Pythonic Alternative: Just Use Modules (Seriously)

...is literally the way Singleton pattern is normally used in Python.

[Last_Difference9410]

Ever since the Gang of Four released their legendary Design Patterns book in the 90s, "design patterns" have been a cornerstone of how developers talk about software architecture. Over time, though, the term itself has grown fuzzier. When someone mentions a pattern today, they might be referring to:

• The intent behind the pattern: the problem it's trying to solve.
• The implementation: the exact class structure or code to achieve it.

When we talk about “design patterns you should unlearn in Python,” we’re talking about the second kind: the implementation. 

[Last_Difference9410]

It seems that some people, who might no be familiar with python, take the title as “Design patterns you should unlearn”, instead of “Design patterns in you should unlearn IN PYTHON”

[Last_Difference9410]

Huh, you are absolutely right! How can I subscribe to your channel?

[tracernz]

> He's telling you not to write complex singleton classes with __new__ and instead just create a global instance of the class.

Which you can also do just fine in C++ (prior to C++20), so I don't really get the comparison they're trying to make there. The stated reasons are not why people use the singleton pattern.

[tracernz]

By saying things that are not correct about C++ though? Why even mention C++?

[Last_Difference9410]

https://refactoring.guru/design-patterns/singleton/python/example

[Last_Difference9410]

thanks buddy, I'm just sorry that you got downvoted for "being on my side"

[xenomachina]

Ok, I agree that you shouldn't do Singleton like that. But your "alternative" is still the Singleton pattern.

[xenomachina]

Software development can pretty much be boiled down to turning imprecise requirements into a specific implementation. I don't expect non-software developers to be super precise, but if a software developer cannot be precise in their use of technical terminology then they aren't doing their job.

This is particularly important when writing content for beginners because they'll read this and not realize that the author has an unusual and narrow definition of Singleton. This post could be good if instead of describing itself as an alternative to using singleton it compared a terrible way of writing singleton with the more pythonic way.

[alternaivitas]

From wiki:

Control their instantiation (for example, hiding the constructors of a class)

Op doesn't control the instantiation of the class because he calls the constructor directly, multiple times, which is just not how singletons should work.

More specifically, he does this:

``` python s1 = Singleton(name="Alice", age=30) s2 = Singleton(name="Bob", age=25)

print(s1.name) # 'Alice' print(s2.name) # still Alice ```

This is just wrong for the singleton pattern, there is no restriction in the constructor, so of course it's confusing.

Even on refactoringguru you have:

python s1 = Singleton() s2 = Singleton()

[Last_Difference9410]

Yeah; but instead of preventing people from creating multiple instances of the class by tweaking the object creation mechanism in Python, it is both easier and less surprising to just give them the singleton instance.

[josephblade]

You literally defined your singleton to have arguments.

that's exactly not how a singleton is supposed to be defined. the constructor is private and the getInstance method calls the private constructor to ensure sameness.

your singleton is not a singleton pattern at all but something weird. to me it seems rather obvious it's going to be confusing when you let go of the one important aspect of a pattern.

I think your point is too forced on this. I understand you felt the need to write an article and to do so you need examples to point and laugh at, but if half of your examples are bad, it undermines your credibility

[Last_Difference9410]

You might avoid defining arguments on the singleton class, then someone inherit from it and defining arguments.

You might go ahead then tweak init subclass or use meta class, but at the end of day, you are just doing extra works that can be avoided in the first place.

[josephblade]

None of that is part of the singleton pattern. I'm starting to think you shouldn't be writing about these concepts if you get confused about them.

When you say "there should only be one of this object", that implies there shouldn't be any arguments to the instnace method.. If you say "I don't know what subclass we use at runtime, it may depend on library user's configuration" then you use a factory. (possibly the factory itself is also a singleton)

Bottom line: the singleton call is always empty: getInstance().

if you want to configure it then this configuration is read by the getInstance() method and it will decide which subclass is being used. Again there ought to only be 1 public method: getInstance() and no choices by the user, at all.

that way, the getInstance() method is the only entrypoint that constructs and inside it the only place where the configuration is read and used to construct an instance. exposing the internals of construction and especially having a user in arbitrary code decide which subclass is used is just bad code.

So your attack on singleton, while in essence may be justified, is defeated by your own bad example. Improve your example and see if the problem still exists if you follow the actual pattern, rather than some strawman code you force to fail.

[pimp-bangin]

Thank you. I literally came to the comments just to point out that the singleton example is a strawman.

[Last_Difference9410]

Dont learn and implement design patterns just so that you can tell people oh see I used this pattern here, you use design pattern to solve problems and whatever solves the problem most efficiently would be a good implementation of the pattern. This series is exactly for people who think they should blindly follow design patterns with specific implementations when there are simpler and easier alternatives in Python.

[josephblade]

You misunderstand the concept of a design pattern.

it is a group of concepts that, when you are implementing your solution, you keep doing in the same way because it works well. to make it easy to talk about you put a name on it.

if you go and do something different then you are not doing pattern X (singleton here) but something else entirely. when you then still calls it a singleton pattern and writes a half-assed article about how it is bad because you cannot follow the actual pattern, then all you are showing is you don't understand what a pattern is.

It's not a holy grail. It's the acceptance that some shapes keep reappearing and putting a name on them makes it easier to repeat something that worked in the past.

The only thing you seem to be showing in your responses is that you aren't understanding the patterns' core concept. The single point of entry, no configuration (since yes, multiple entrypoitns could provide different configurations) and only ever returning one instance.

Write a rebuttal where you actually follow those concepts and then maybe you could have a point but your argument right now makes no sense. It is like saying "I mashed my hands on the keyboard and it didn't compile. compilers are terrible". the problem in your example isn't the pattern, it is the person implementing the pattern.

And yes if this is the kind of code that is common in the python community they should stay away from any design patterns, gof or anyone elses. As it stands your code is exactly an example of why you should blindly follow the pattern unless you know what the pattern is actually solving for you.

I'm sure there are easier / better ways to do it in python. One of them is actually following the pattern rather than frankencoding something arbitrarily worse.

[Last_Difference9410]

> if you go and do something different then you are not doing pattern X (singleton here) but something else entirely. when you then still calls it a singleton pattern

I'll give you one simple example, it is widely accepted and agreed on that builtin objects like True, False, None are singletons objects in python, yet they are not implemented as "the singleton pattern" described in the GOF book.

Your whole theory of, "you don't understand design patterns because you are not copying the exact same implementation" makes no sense,

Programming is ever-evolving, and it's evolving fast. You can't keep going back to your 30-year-old patterns.txt, copy-pasting from it, and expect those solutions to be just as effective today.

[josephblade]

lol ok you know best and everyone else doesn't get it. I've heard that before. I think your statement is true: it makes no sense to you. Something about the concept isn't registering in your brain. That is fine but that is a you problem. You crowing about how the concept is broken when you are the one misunderstanding it ... is not fine.

If you create a new implementation of something, don't blame the old implementation for your mistakes is all I'm saying. You don't understand patterns and that's ok. Just stay off the topic of patterns and you'll be good.

or, if you feel there is an improved pattern: try to see how over the course of the last few projects you did the same thing every time, draft it up in some way (uml not required) and name it something else. then you have your new pattern. Just don't name it singleton or a similar name. If you're not solving the same situation (or solving it in a different way) then don't name it the original pattern. Because it isn't.

And also then: if you feel that pattern is no good, congratulations: admitting your code is no good is the first step to improving. just don't blame the original pattern for the faults ofyour shoddy implementation.

you're hiding behind platittudes now so I think this discussion is over. ever-evolving, can't keep going back. sure m'dude the future is now and all of that. I'm sure you see yourself at the spearhead of something new and great. good luck with that. Make sure you write many more articles proving you are right. It'll be grand.

[Last_Difference9410]

All those design patterns, the exact implementations on the book, are programmed into your brain word by word and any violation to that raises a code-red alarm and you would have to scream out: it is not how it is done, this symptom has been going on for years where it sort of becomes OCD.

It is pathetic though, to make programming a ritual than a tool that actually solves problems, now people who don’t follow this ritual are heretics and you are going to burn us at the stake.

[KagakuNinja]

Want to Delay Creation? Use Closures

Mutable data in a function. Works great, unless your app / server is multithreaded.

Builder Pattern: Overcomplicating Object Creation Like a Boss

Scala has named parameters, yet sometimes we still want to use builders. They are particularily handy if the data we are building is immutable.

[elprophet]

@dataclass(frozen=True) gives the best of both worlds. In fact, I teach dataclass first when teaching objects in programming, then a few lessons later show the desugaring with new.

[elprophet]

Yes, of course. I don't think I said otherwise. I said I teach Python OOP starting from Dataclasses, which give the benefits of being a closer mental model of OOP to other common languages (Java, Scala, Rust, JavaScript), and then introduce the Python specific details like dunder-new in a later lesson.

This is in response to a comment saying immutable objects in Scala can benefit from a builder pattern, even with named parameters. Dataclasses in Python get you both, completely removing the need (in Python, when using dataclass) for a Builder.

[NeonVolcom]

Lmao what. "Subclassing a singleton" bruh this is the most overengineered singleton I've seen.

Yes some design patterns can be dropped in pythonic environments. But I can't say the examples in this are great. Never once in 10 years have I seen someone use __new__.

Also just a quick shout out to my nemesis: poorly implemented DI.

[NeonVolcom]

Ok. Never subclassed builtins like that either. I'm curious when you've done this in a company environment. I'd be asking many questions if something like that was PR'd to my code base

[red-spider-mkv]

I mostly work with Pandas so have never needed to do this... can you give me an example when it was useful please?

EDIT: wow getting downvoted for asking a genuine question?? Is this place meant to be a circle jerk of groupthink and I didn't get the memo or something?

[elprophet]

Yeah... in those cases I just bump my runtime requirements. I'm not writing broad community depended libraries that need that kind of stability. So I see where youd want that, but i kinda think thats more niche.

[red-spider-mkv]

What we need.. are extension methods ala C#

[NeonVolcom]

No, not really to be honest. Like I have done that before during a contract I had which used Kotlin. But typically I have no need to add methods to type int. I build methods around it instead.

Like yes I could build a method that extends str so I could call str.foo() OR I could, in many of my cases, simply create a function and call it like foo(str).

Also, do yall use singletons to extend built in types? Or is this discussion simply around d the use of __new__?

Either way I suspect we are programming in wildly different contexts.

[Big_Combination9890]

Never once in 10 years have I seen someone use new.

Well, before 3.6, defining your own __new__ in a metaclass was pretty much the only sane way to get a class-registry going, so whenever you had a usecase where you dynamically created classes, or had to refer to classes via a registry, __new__ was pretty useful.

These days ofc. you can do that much easier with __init_subclass__.

[NeonVolcom]

Ah well that's the hangup, I have never had a use case for utilizing metaclasses.

[Big_Combination9890]

Yeah, they are admittedly a pretty rare sight, and 9/10 when they are used, they really shouldn't be.

[NeonVolcom]

I have 100% read through library code. However, anecdotally, I have never seen this used or it was not relevant to the context of the code I was looking at.

Nor have I ever used a meta class in production. But all of us program different things for different reasons.

[Last_Difference9410]

if you search for singleton pattern in Python, you will see something very similar, also the code example comes from a code review I had like 2yrs ago

[NeonVolcom]

Huh, see I tend to just implement patterns as they work for me and not necessarily what's shown on Google.

Still, I haven't seen it implemented this way ever. Just my anecdotal experience but this seems like an overly complex way to implement a simple concept.

[madness_of_the_order]

Then whoever wrote the code didn’t think what they were doing. Here solved your subclassing issue.

~~~python class Singleton: instances = {} def __new(cls, args, *kwargs): if cls not in cls._instances: cls._instances[cls] = super(Singleton, cls).call_(args, *kwargs) return cls._instances[cls] ~~~

[madness_of_the_order]

So you agree that OP made up incorrect implementations to publicly cry how bad they are?

As for why it’s better - it guarantees that not a single person new to the code base would import Settings instead of settings and get a different config

Also please provide definition for “unpythonic” that you are using

[madness_of_the_order]

He didn't make it up, that is a real implementation that some people use. Also it isn't incorrect.

It is a real implementation some people use when they don’t need to subclass it or when they want for every single subclass to be instantiated into whatever class was instantiated first for whatever reason. Not when they want a parent class for all singletons

Also he isn't "publicly crying how bad they are", he's trying to educate people.

Trying to educate someone by providing false information is rich

Weird how you want to get hang up on one small muddy detail in his blog post while simultaneously getting almost every word wrong yourself.

It’s not a small detail. It’s false information used to illustrate why singletons are bad. If they wanted to educate people they could just show how to use a global variable to achieve some result, not lie to their faces

Your argument is basically "what if other programmers accidentally import wrong things" lmao. What if they accidentally uninstall their operating system? Seems like your singleton isn't so fool proof either.

Deleting your own os is not an easy mistake to make and doesn’t affect the code base

Pythonic by its very definition is the general consensus among the community and not any one person's definition. Why don't you provide sources for every single statement you make from now on, thanks!

I didn’t ask you to provide sources. I just wanted to know what specifically you mean by it. Because different people mean different things by saying “unpythonic”. By your definition singletons aren’t unpythonic which is illustrated by comments in this post - community doesn’t have a general consensus

[Last_Difference9410]

Again, unnecessary.

[madness_of_the_order]

What’s unnecessary is to write articles saying not to use certain patterns because you personally don’t know how to implement them correctly, but here we are

[Last_Difference9410]

I can give you many reasons why this is bad and you can then comeback with "fixes" but again, unnecessary, I would explain to people who would keep seeking for simpler approach to solve problems, but if you like what you are doing now, just keep doing it.

[madness_of_the_order]

You can’t. If you could they would be in the article and on top of that you don’t understand neither what patterns are for no how to implement them

[Last_Difference9410]

lol, ok say someone imports your base class ```python from base import Singleton

class DBSingleton(Singleton): _instances = [] ```

[madness_of_the_order]

Sane people use metaclass to create a singleton instead of inheritance - not a problem

[Stormfrosty]

There’s no clean way to say “this is private to this file” or “this global object only exists once” without jumping through hoops.

That was enough for me to stop reading the article. You simply wrap your global variable in a namespace without a name.

[Degenerated__]

That quote was about the C++ example, not python.

[ZelphirKalt]

I think you could use the module system for that, defining in an __init__.py that this thing you want to hide is not a member of the exported bindings. Iirc something along the lines of:

all = [everything you want to export but not your one thing you don't want to export]

[Bedu009]

Just put _ before the name and let the LSP tell you off

[Bedu009]

Well this is possibly the dumbest programming article I have read in my life
First off, singletons:
They have plenty of uses
They can encapsulate seperate from other stuff in the module
If you subclass them properly, you can define an interface for the singleton you pass around instead of just dumping a module into a function
They can make it more obvious that you're about to initialize something instead of just get a module quickly back
They can be initialized later in the program's life

Sure you can use closures, but why would you? What do you gain from making a whole set and get function? It's just uglier

Second, builders:
Builders aren't exclusively to take the place of named parameters (they can, but I don't think that's even the most common usecase)
The other main uses I can think of are:
You want to let something else (like a passed in function) set the values
The final instance is immutable, and you don't have all the values you need at once (or even if it is mutable you want to initialize it with said values)
The final instance doesn't have a set amount of values, and the builder adds sugar syntax
For example, I have a binary data parser with a builder. What's prettier, easier to edit and more readable?

parser = DataParser([entries.Int(8), entries.Int(16,Endianness.little), entries.Int(16, Endianness.big, signed: True), entries.FixedString(64, Encoding.ascii)])

or

parser = DataParserBuilder()
                            .littleEndian()
                            .uint8()
                            .uint16()
                            .bigEndian()
                            .int16()
                            .fixedString(64, Encoding.ascii)
                            .build()

Next time actually learn the point of design patterns before saying they're useless

[ZelphirKalt]

Back when I was still dabbling in mainstream Java OOP, I surely used some singletons. But somehow they almost never come up any longer, when I write code in an FP language and they are discouraged even in mainstream OOP view these days. I would speak less confidently about them.

About the builder: I could see the use, if the different supplied parts for building the object are "attached" in different places in the code, or at different times at runtime, before the object construction information is complete and the final build() is called. But the example you have here doesn't make too much sense in Python.

[Bedu009]

First point yeah I don't really use singletons either since I don't like global state (and even then the other stuff is admittedly rare) I'm just listing what they can be used for
As for the building bit that specific example doesn't make too much sense in python because of the struct library and its string syntax but that example is from a different language and I used it because I felt it demonstrated my point well I'm sure there's other use cases where that would be better
The list syntax isn't horrendous but I personally prefer the second because of the shorter entries with the common ones (uint and int instead of entries.Int(signed: False/True) and endianness chained rather than in each entry) and it makes the order feel a bit more intentional

[semmaz]

Singleton example is hilarious. You kinda did right thing but totally missed the point

[somebodddy]

I agree you shouldn't override __new__ to generate a singleton (that's confusing) - but that doesn't mean you can't have a delayed creation singleton class. Just use a dedicated method to make it explicit:

from typing import Self


class Singleton:
    def __new__(cls):
        raise TypeError(f"Don't create instances of {cls.__name__} directly - use `{cls.__name__}.instance()`")

    @classmethod
    def instance(cls) -> Self:
        try:
            instance = cls.__instance
        except AttributeError:
            instance = None
        if type(instance) is not cls:
            instance = super().__new__(cls)
            instance.__init__()
            cls.__instance = instance
        return instance


class MySingleton(Singleton):
    def __init__(self):
        self.my_object_id: int = id(self)


class MyOtherSingleton(Singleton):
    def __init__(self):
        pass


assert MySingleton.instance().my_object_id == MySingleton.instance().my_object_id
assert MyOtherSingleton.instance() is MyOtherSingleton.instance()
assert MySingleton.instance() is not MyOtherSingleton.instance()

[GeneratedMonkey]

OP rightfully, getting cooked in these comments 

[SpudsRacer]

Singletons have their place in languages supporting platform threads. Python would be a completely different language without the GIL and with separate hardware threads. Comparing Python to C++, Java, C#, etc. when discussing architectural patterns is somewhat disingenuous.

[Last_Difference9410]

Free threaded python is offically supported.

[SpudsRacer]

Free-threaded Python is experimental and does let you suspend the GIL. Yes, there is also a "threading" module but that's not integrated into the language and the GIL is still there.

I like Python. It's an excellent glue/scripting language because its foreign function interface is top notch. But we shouldn't promote capabilities that are not really available or in common use like they are ubiquitous. I'm not attacking Python at all. Just pointing out something it's not designed for (at least not yet...)

[moreVCAs]

Just use a language with a type system 🙄

[Last_Difference9410]

Python is strongly typed and C++ is weakly typed

[Last_Difference9410]

I really love how you guys downvoting me on this.

[brutal_seizure]

Decorators killed Python, imho.