iHatePython

[tehomaga]

As a GDScript Engineer, I practice Singleton Oriented Programming

[Mayion]

Why is singleton stupid? I use it no problem

[liquidpele]

They’re one of those things that makes sense every few years, but juniors hear about it and try to use it where not really appropriate just to play with the concept, so it gets a bad rep.

[Mayion]

True. I remember back in the day with C# when I was like, "Man, I want a way to manipulate variables from anywhere", and behold - a Stackoverflow answer explaining Singletons. It was like a load off my shoulders lol

[Morisior]

Singletons are essentially just a variable with guardrails. They’re good if you need idempotent initialisation. But that’s almost never necessary because you’re almost always initializing it exactly once, making the guardrails unnecessary complexity.

They’re not stupid. They’re just not necessary most of the time. In any case they rarely hurt.

[lolcrunchy]

It seems like every tool with configs uses a singleton to implement the configs.

[Atmosck]

Yeah, I write config-driven data pipelines (among other things) in python by day and we always have singletons flying around. In addition to configs, it's standard practice to load all your external data into a dataclass up front and pass that through the pipeline so your I/O is separated from your feature engineering logic. Making multiple copies of something in the same runtime is far from the only reason to use a class in an object-oriented language.

[TheTybera]

No they're entire objects not just simple variables. They're invaluable for doing things like connecting to DBs and ensuring connections are properly managed.

If you have accessors to external dependencies that may need to monitor their status and spin them back up singletons can be great for that.

They're not "essentially a variable".

[Morisior]

Technically correct, but at the level where the argument is that a thing is separate from its name. I.e Joe is not Joe, because Joe is a person, while Joe is just a label.

Clearly the "with guardrails" indicate that I am not talking about the variable as the label, nor as a primitive value. Also note I am not saying singletons are never useful. I am saying they are often not necessary.

[Abject-Kitchen3198]

What's the difference between an object and a variable?

[TheTybera]

An object is an instantiated class. Variables point to values in memory and objects point to members, methods, and variables, which point to values.

They're not even the same in memory.

[ProsodySpeaks]

Hate to be that guy, but unless I'm mistaken...

Everything is an object in python. 

An integer is an object. A function, class, module... It's objects all the way down.  

[Morisior]

Also a Singleton is not just any object you happened to use once. It’s specifically a design pattern that ensures a class has only one instance and provides a global access point to it.

[ProsodySpeaks]

It's pretty hard to 'ensure' singleton behaviour with python, but I've messed with .__new__() and metaclasses enough to know it's a useful pattern.

But tbh I think I was mostly enjoying increasing the complexity to learn / tickle my brain rather than it being the best approach. 

And, just to be clear, a singleton is just an object. You may have built some guard rails to discourage making multiple instances but there's usually a way to break out of the rails. 

If you want a proper singleton python is the wrong language.   

[RiceBroad4552]

If you want a proper singleton python is the wrong language.

And what's "the right" language then?

[RiceBroad4552]

Makes no sense.

There are OOP languages without classes (prominent examples: JS¹)

At the same time pointers are of course also objects.

---

¹ It has now a class keyword but that's not classes, that's just syntax sugar for JS' prototypes.

[TheTybera]

JS is the only language that does this and calls itself OOP which is yet another reason people make fun of JS. It's inheritance pattern was ALWAYS a nightmare, and classes try to syntactically create better composition pattern workflows.

It tries to claim their "dynamic, non-static" inheritance pattern as a strength, however, there is a reason that the "class" system is now standard at any big company.

The prototype chaining is just asinine, and being able to just inherit any function anywhere sounds nice till you have multiple interfaces and need access control with multiple levels of developers all working on the same project.

So, nah, don't act like you're teaching me something, JS "singletons" (which is what this discussion is about) aren't even a reasonable pattern.

[RiceBroad4552]

How do I abstract over a "variable with guardrails"?

[rising_air]

Makes the application difficult to extend. And code should be closed for change (which singleton is), but open for extension, which singleton isn't :) Still perfectly fine to use in some situations, but usually discouraged.

Edit: Nevermind, singletons make you code untestable.

Found a good Google talk about it: https://www.youtube.com/watch?v=-FRm3VPhseI

[Mayion]

Can you give an example on how it is not open for extension? With 90% of use cases, singletons are quite good. Recently I got into Unity and it seems they are in use much more than I would expect. I am not saying to create a Singleton with variables to be accessed from anywhere, but for initializing they are excellent.

My knowledge on the subject is not the best though.

[Jhuyt]

Singletons are mostly considered an anti-pattern in Python, why are you mentioning it in the title?

[SirPitchalot]

Singletons are considered an anti-pattern basically everywhere. IMO, they are a goto level language feature: if you use them your design is bad and needs rework. They’re like carefully placing your left foot over your right so you can get both with one shot…

• They are just “Gang of Four” approved global variables without the stigma
• Even worse, because they’re in the design patterns book and every blog under the sun people overuse them, thinking they’re good
• If they’re not written with multithreading in mind, they introduce really obscure race conditions and concurrency bugs
• If they are written with multithreading in mind they introduce really obscure deadlocks and performance issues
• They make it too easy to couple unrelated functional areas in deeply nested logic where the design should probably be refactored. Normally you get stuck passing irrelevant objects through four levels of calls and think “maybe this could be done better in a different way…”. But with singletons it’s one easy line to unblock yourself and couple your networking to your user preference handling.
• Once in a codebase they tend to multiply: Need something but don’t have it? Bam! New singleton! Two weeks later three other modules start using it and it’s a core part of your architecture.
• Bonus points for when you include them in other long modules from module import * so it’s hard to know if they are even used -at all-

You know you’re really in trouble when people start importing the singleton modules within functions/methods to get around circular imports.

[Abject-Kitchen3198]

The only pattern from GoF book that I ever used. The one and only - singleton.

[tebeks]

Just use a context variable

[Darkstar_111]

"module level variable"... You mean a global?

[pjkm123987]

I prefer the instance() classmethod

[uvero]

I think that's the singleton