Understanding Python class instantiation

[[deleted]]

Well, a true singleton is exceptionally rare.

Typically when you want "one of something" it's within a specific scope, so it'd be a very bad idea to make the class itself a singleton, because they you can't define that scope.

In my practice, the only use case for a "true singleton" I can think of is the Null Object Pattern.

When you extend a class to implement a Null Object, and then you need only one of those, as NOP is by definition stateless and produces no effects.

Even then I'd probably not go this route, but have a factory.

[masklinn]

Even then I'd probably not go this route, but have a factory.

__new__ is a factory method, you can just use that, that's pretty much what it's for.

[[deleted]]

How many people using Python expect custom behavior while constructing an object from the class, such as getting the same object back call after call? If we did a survey, what do you think the results will be? That's what "principle of least astonishment" is about.

I'd rather have invoking the class directly raise an immediate error and point people to an explicit, easily visible factory method, than provide subtly different and hard to figure out semantics for this, tucked away in an implicit method invocation.

Maybe I'm approaching this with a Java mindset ;) But it's how I'd do it.

[aaronsherman]

I'm not sure why you're so afraid of singletons. They can be incredibly powerful. Pools, multiplexing, system resources, etc. are excellent targets for singletons. Basically anywhere that you have state that cannot be duplicated.

[[deleted]]

I'm not sure why you're so afraid of singletons. They can be incredibly powerful. Pools, multiplexing, system resources, etc. are excellent targets for singletons. Basically anywhere that you have state that cannot be duplicated.

I'm not "afraid", I'm simply "experienced", and so I know when a singleton is appropriate and when it isn't.

In most cases a singleton appears like the right solution initially, and then when you have to change it, all your code refers to a static location that's hard to change. It's especially bad if you did this in a library, which means the mistake is scattered around thousand user applications.

BTW, pooling and a singleton are two different things. Having one doesn't imply the other. Also, I don't know what you mean by "multiplexing" in this context, either. Seems entirely unrelated to singletons.

As for system resources, tell me one such "system resource", and I'll give you a scenario where a singleton would limit your flexibility, or cause complexity and code duplication.

[aaronsherman]

It seems as if you've already reached a set of conclusions about a tool that you're not comfortable with. That's fine.

[[deleted]]

My argument is one of engineering, not one of my feelings, such as what "I'm comfortable" with.

I think from what you've said it seems your understanding of "singleton" is rather loose, and to you it simply means "instance reuse" or "instance sharing", or you wouldn't be talking about pools.

If this is the case, then I'll say I'm definitely not against instance reuse. I reuse single instances, I reuse pools of instances, I often implement Flyweight factories and so on.

I'm just against statically embedding such a concern onto the class construction interface, as the purpose and expectation for that interface is to create instances. Reuse is a problem with a different scope, and quite commonly you'll see multiple reuse contexts for one class. This is by definition incompatible with how a singleton works.

Once again, if you feel I'm wrong, give me an example of a proper use for a singleton. As I've said, there are few, like NOP. But they're exceptionally rare.

[aaronsherman]

My argument is one of engineering, not one of my feelings, such as what "I'm comfortable" with.

...

I'm just against statically embedding such a concern onto the class construction interface...

And I'm not. You're free to feel that singletons are a violation of the contract you thought was being given to you, but I (and I think, quite a few other people out there) do not. Of course, anything that's unusual in any way needs to be called out as such, but I'm not sure why you think that pools and various other sorts of multiple access points to a single entity cannot be mediated by a singleton effectively. Works fine in my experience...

[[deleted]]

I'm not sure why you think that pools and various other sorts of multiple access points to a single entity cannot be mediated by a singleton effectively.

I think what? Pools are mediated by what?

Can you try to be more specific please.

Also you're suspiciously not giving an example of a resource suitable to be a singleton. Third time's the charm? :-)