On 02/10/2023 00.57, Karsten Hilbert via Python-list wrote:
> Sorry for having conflated the core of the matter with all
> the Borg shenanigans, that's where I found the problem in my
> real code, so there :-)

The first question when dealing with the Singleton Pattern is what to do
when more than one instantiation is attempted:

- silently return the first instance
- raise an exception

The 'problem' interpreting the original code was that the 'Borg
Pattern', is not limited in number, but is where some class-attribute
list (or dict) is used to enable all instances to be aware of each of
the others (IIRC).

Is choosing names as important as selecting/implementing smart algorithms?

> Consider this:
>
> #----------------------------------------------------
> class Surprise:
> def __init__(self, with_type_annotation=False):
> if with_type_annotation:
> try:
> self.does_not_exist:bool
> print('does_not_exist does exist')
> except AttributeError:
> print('does_not_exist does not exist')
> return
>
> try:
> self.does_not_exist
> print('does_not_exist does exist')
> except AttributeError:
> print('does_not_exist does not exist')
>
> Surprise(with_type_annotation = False)
> Surprise(with_type_annotation = True)
> #----------------------------------------------------
>
> Is this how it is supposed to be ?

Wasn't this answered earlier? (@Mats)

That self.does_not_exist:bool isn't interpreted by Python to mean the
same as self.does_not_exist.

>> ...and so we're addressing the important question: the try-test is for existence, cf for
>> some value.
>>
>> This can also be achieved by using the attribute in a legal expression, eg:
> ...
>> Might this remove the confusion (ref: @Mats):
>>
>> self.already_initialized:bool == True
>
> Not for me as that would _create_ already_initialized on the
> instance. It would not allow me to test for it.
>
>>> Which seems akin constructs for generating compatibility
>>> between versions.
>>
>> versions of ?
>
> Of the language. Sometimes one tests for existence of a given
> class in a module and defines said class oneself if it does
> not exist. But that's leading astray.
>
>> What is the intent: a class where each instance is aware of every other instance - yet
>> the word "Singleton" implies there's only one (cf a dict full of ...)?
>
> The latter.

and so, returning to the matter of 'readability':

- the name "Borg" de-railed comprehension

- _instances:dict = {} implied the tracking of more than one

- should the class have been called either;

class SomethingSingleton():

or a Singleton() class defined, which is then sub-classed, ie

class Something( Singleton ):

in order to better communicate the coder's intent to the reader?

- from there, plenty of 'templates' exist for Singletons, so why do
something quite different/alien to the reader?
(thus concurring with @Richard: "tricky" subverts 'readability')

- is it better to use a technique which 'we' will recognise, or to ask
'us' to comprehend something 'new'?
(unless the 'new' is taking-advantage of a recent extension to the
language, eg switch; to justify 'trail-blazing' a
new/improved/replacement 'best practice')

- part of the 'tricky' seems to be an attempt to assess using an
instance-attribute, rather than a class-attribute. If the :bool (or
whichever) typing-annotation is added to a class-attribute (eg
_instance), will the problem arise?

- does the sequence

_instance = False
...
if not cls._instance:
ie the explicit version
if cls._instance == False:

measure 'existence' or a value?

- does the sequence

_instance = None
...
if not cls._instance:
ie the explicit version:
if cls._instance is None:

measure 'existence' or identity?
(indeed, are they more-or-less the same concept?)

- do the *attr() functions test for 'existence'?

(that said, most of the code-examples I spotted, in reading-up on this,
use either None or False - et tu Brute!)

Speaking of reading-up:

- am wondering where PEP 661 - Sentinel Values is 'going'?

- this article (https://python-patterns.guide/gang-of-four/singleton/)
mentions that the original GoF Singleton Pattern preceded Python
(particularly Python 3 classes). Also, that Python doesn't have
complications present in C++. It further discusses "several drawbacks",
which also champion 'readability' over 'trick' or 'sophistication'. I
think you'll enjoy it!

--
Regards,
=dn

On 4/10/23 5:25 pm, dn wrote:
> The first question when dealing with the Singleton Pattern is what to do
> when more than one instantiation is attempted

My preferred way of handling singletons is not to expose the class
itself, but a function that creates an instance the first time it's
called, and returns that instance subsequently. The problem then
doesn't arise.

--
Greg

On Wed, 4 Oct 2023 at 17:47, Greg Ewing via Python-list
<python-list@python.org> wrote:
>
> On 4/10/23 5:25 pm, dn wrote:
> > The first question when dealing with the Singleton Pattern is what to do
> > when more than one instantiation is attempted
>
> My preferred way of handling singletons is not to expose the class
> itself, but a function that creates an instance the first time it's
> called, and returns that instance subsequently. The problem then
> doesn't arise.
>

That's one option. Personally, I don't use them very much, but if I
do, it's usually actually as a class that never gets instantiated:

class PileOfAttributes:
x = 1
y = 2
spam = "ham"

ChrisA

dn <PythonList@DancesWithMice.info> writes:
>- should the class have been called either;
> class SomethingSingleton():
>or a Singleton() class defined, which is then sub-classed, ie

A singleton is a single instance of a class that usually is
used "globally" in an application. Such as "root" in

import logging

root = logging.getLogger()

. So, when a singleton is needed in Python, I would follow
the model of "getLogger". You do not have to put in effort
to keep any client from creating more than one instance of
a class. Multiple instances of a class intended for singletons
might help when one is writing tests for this class.

(My above opinion was stolen from Brandon Rhodes.)