Cette question n'est pas pour la discussion de savoir si le modèle de conception singleton est souhaitable ou non , ou pour toute guerre religieuse, mais pour discuter de la meilleure façon de mettre en œuvre ce modèle en Python de la manière la plus pythonique. Dans ce cas, je définis «le plus pythonique» pour signifier qu'il suit le «principe du moindre étonnement» .

J'ai plusieurs classes qui deviendraient singletons (mon cas d'utilisation est pour un enregistreur, mais ce n'est pas important). Je ne souhaite pas encombrer plusieurs classes avec une gomme ajoutée quand je peux simplement hériter ou décorer.

Meilleures méthodes:

Méthode 1: Un décorateur

def singleton(class_):
    instances = {}
    def getinstance(*args, **kwargs):
        if class_ not in instances:
            instances[class_] = class_(*args, **kwargs)
        return instances[class_]
    return getinstance

@singleton
class MyClass(BaseClass):
    pass

Avantages

• Les décorateurs sont additifs d'une manière qui est souvent plus intuitive que l'héritage multiple.

Les inconvénients

• Alors que les objets créés à l'aide de MyClass () seraient de vrais objets singleton, MyClass lui-même est une fonction, pas une classe, vous ne pouvez donc pas appeler de méthodes de classe à partir de celle-ci. Aussi pour m = MyClass(); n = MyClass(); o = type(n)();alorsm == n && m != o && n != o

Méthode 2: une classe de base

class Singleton(object):
    _instance = None
    def __new__(class_, *args, **kwargs):
        if not isinstance(class_._instance, class_):
            class_._instance = object.__new__(class_, *args, **kwargs)
        return class_._instance

class MyClass(Singleton, BaseClass):
    pass

Avantages

• C'est une vraie classe

Les inconvénients

• Héritage multiple - eugh! __new__pourrait être écrasé lors de l'héritage d'une deuxième classe de base? Il faut penser plus que nécessaire.

Méthode 3: une métaclasse

class Singleton(type):
    _instances = {}
    def __call__(cls, *args, **kwargs):
        if cls not in cls._instances:
            cls._instances[cls] = super(Singleton, cls).__call__(*args, **kwargs)
        return cls._instances[cls]

#Python2
class MyClass(BaseClass):
    __metaclass__ = Singleton

#Python3
class MyClass(BaseClass, metaclass=Singleton):
    pass

Avantages

• C'est une vraie classe
• Couvre automatiquement l'héritage
• Utilise __metaclass__pour son bon usage (et m'a fait prendre conscience de cela)

Les inconvénients

• Y a-t-il?

Méthode 4: le décorateur renvoie une classe du même nom

def singleton(class_):
    class class_w(class_):
        _instance = None
        def __new__(class_, *args, **kwargs):
            if class_w._instance is None:
                class_w._instance = super(class_w,
                                    class_).__new__(class_,
                                                    *args,
                                                    **kwargs)
                class_w._instance._sealed = False
            return class_w._instance
        def __init__(self, *args, **kwargs):
            if self._sealed:
                return
            super(class_w, self).__init__(*args, **kwargs)
            self._sealed = True
    class_w.__name__ = class_.__name__
    return class_w

@singleton
class MyClass(BaseClass):
    pass

Avantages

• C'est une vraie classe
• Couvre automatiquement l'héritage

Les inconvénients

• N'y a-t-il pas une surcharge pour créer chaque nouvelle classe? Ici, nous créons deux classes pour chaque classe que nous souhaitons faire un singleton. Bien que cela soit bien dans mon cas, je crains que cela ne soit pas à l'échelle. Bien sûr, il y a un débat pour savoir s'il serait trop facile de mettre à l'échelle ce modèle ...
• Quel est l'intérêt de l' _sealedattribut
• Impossible d'appeler des méthodes du même nom sur les classes de base à l'aide super()car elles vont récurrentes. Cela signifie que vous ne pouvez pas personnaliser __new__et ne pouvez pas sous-classer une classe qui a besoin de vous pour appeler __init__.

Méthode 5: un module

un fichier module singleton.py

Avantages

• Simple, c'est mieux que complexe

Les inconvénients

Utiliser une métaclasse

Je recommanderais la méthode n ° 2 , mais il vaut mieux utiliser une métaclasse qu'une classe de base. Voici un exemple d'implémentation:

class Singleton(type):
    _instances = {}
    def __call__(cls, *args, **kwargs):
        if cls not in cls._instances:
            cls._instances[cls] = super(Singleton, cls).__call__(*args, **kwargs)
        return cls._instances[cls]

class Logger(object):
    __metaclass__ = Singleton

Ou en Python3

class Logger(metaclass=Singleton):
    pass

Si vous souhaitez exécuter __init__chaque fois que la classe est appelée, ajoutez

        else:
            cls._instances[cls].__init__(*args, **kwargs)

à la ifdéclaration en Singleton.__call__.

Quelques mots sur les métaclasses. Une métaclasse est la classe d'une classe ; c'est-à-dire qu'une classe est une instance de sa métaclasse . Vous trouvez la métaclasse d'un objet en Python avec type(obj). Les classes normales de nouveau style sont de type type. Loggerdans le code ci-dessus sera de type class 'your_module.Singleton', tout comme la (seule) instance de Loggersera de type class 'your_module.Logger'. Lorsque vous appelez avec enregistreur Logger(), Python demande d' abord la métaclasse Logger, Singleton, ce qu'il faut faire, ce qui permet la création d'instance à préempté. Ce processus est le même que Python demandant à une classe quoi faire en appelant __getattr__lorsque vous faites référence à l'un de ses attributs en faisant myclass.attribute.

Une métaclasse décide essentiellement ce que signifie la définition d'une classe et comment mettre en œuvre cette définition. Voir par exemple http://code.activestate.com/recipes/498149/ , qui recrée essentiellement des styles C structen Python à l'aide de métaclasses. Le fil Quels sont les cas d'utilisation (concrets) des métaclasses? fournit également quelques exemples, ils semblent généralement liés à la programmation déclarative, en particulier telle qu'elle est utilisée dans les ORM.

Dans cette situation, si vous utilisez votre méthode n ° 2 et qu'une sous-classe définit une __new__méthode, elle sera exécutée à chaque appel SubClassOfSingleton(), car elle est responsable de l'appel de la méthode qui renvoie l'instance stockée. Avec une métaclasse, elle ne sera appelée qu'une seule fois , lorsque la seule instance sera créée. Vous voulez personnaliser ce que cela signifie d'appeler la classe , qui est déterminée par son type.

En général, il est logique d'utiliser une métaclasse pour implémenter un singleton. Un singleton est spécial car il n'est créé qu'une seule fois , et une métaclasse est la façon dont vous personnalisez la création d'une classe . L'utilisation d'une métaclasse vous donne plus de contrôle au cas où vous auriez besoin de personnaliser les définitions de classe singleton d'une autre manière.

Vos singletons n'auront pas besoin d'héritage multiple (car la métaclasse n'est pas une classe de base), mais pour les sous-classes de la classe créée qui utilisent l'héritage multiple, vous devez vous assurer que la classe singleton est la première / la plus à gauche avec une métaclasse qui redéfinit __call__Il est très peu probable que ce soit un problème. Le dict d'instance n'est pas dans l'espace de noms de l'instance, il ne le remplacera donc pas accidentellement.

Vous entendrez également que le modèle singleton viole le «principe de responsabilité unique» - chaque classe ne doit faire qu'une seule chose . De cette façon, vous n'avez pas à vous soucier de gâcher une chose que le code fait si vous devez en changer une autre, car ils sont séparés et encapsulés. L'implémentation de la métaclasse réussit ce test . La métaclasse est responsable de l' application du modèle et la classe et les sous-classes créées n'ont pas besoin de savoir qu'elles sont des singletons . La méthode n ° 1 échoue à ce test, comme vous l'avez noté avec "MyClass lui-même est une fonction, pas une classe, vous ne pouvez donc pas appeler de méthodes de classe à partir de celle-ci."

Version compatible Python 2 et 3

Écrire quelque chose qui fonctionne à la fois en Python2 et 3 nécessite l'utilisation d'un schéma légèrement plus compliqué. Étant donné que les métaclasses sont généralement sous - classes de type type, il est possible d'utiliser un pour créer dynamiquement une classe de base intermédiaire au moment de l' exécution avec elle comme métaclasse et utiliser alors que les baseclass du public Singletonclasse de base. Il est plus difficile à expliquer qu'à faire, comme illustré ci-dessous:

# works in Python 2 & 3
class _Singleton(type):
    """ A metaclass that creates a Singleton base class when called. """
    _instances = {}
    def __call__(cls, *args, **kwargs):
        if cls not in cls._instances:
            cls._instances[cls] = super(_Singleton, cls).__call__(*args, **kwargs)
        return cls._instances[cls]

class Singleton(_Singleton('SingletonMeta', (object,), {})): pass

class Logger(Singleton):
    pass

Un aspect ironique de cette approche est qu'elle utilise le sous-classement pour implémenter une métaclasse. Un avantage possible est que, contrairement à une métaclasse pure, isinstance(inst, Singleton)il reviendra True.

Corrections

Sur un autre sujet, vous l'avez probablement déjà remarqué, mais l'implémentation de la classe de base dans votre message d'origine est incorrecte. _instancesdoit être référencé sur la classe , vous devez utiliser super()ou vous êtes récursif , et __new__est en fait une méthode statique à laquelle vous devez passer la classe , pas une méthode de classe, car la classe réelle n'a pas encore été créée quand elle est appelé. Toutes ces choses seront également vraies pour une implémentation de métaclasse.

class Singleton(object):
  _instances = {}
  def __new__(class_, *args, **kwargs):
    if class_ not in class_._instances:
        class_._instances[class_] = super(Singleton, class_).__new__(class_, *args, **kwargs)
    return class_._instances[class_]

class MyClass(Singleton):
  pass

c = MyClass()

Décorateur retournant une classe

Au départ, j'écrivais un commentaire mais c'était trop long, je vais donc l'ajouter ici. La méthode # 4 est meilleure que l'autre version de décorateur, mais c'est plus de code que nécessaire pour un singleton, et ce n'est pas aussi clair.

Les principaux problèmes proviennent de la classe étant sa propre classe de base. Tout d'abord, n'est-il pas étrange qu'une classe soit une sous-classe d'une classe presque identique avec le même nom qui n'existe que dans son __class__attribut? Cela signifie également que vous ne pouvez pas définir de méthodes qui appellent la méthode du même nom sur leur classe de base avec, super()car elles recurseront. Cela signifie que votre classe ne peut pas être personnalisée __new__et ne peut dériver d'aucune classe qui doit y faire __init__appel.

Quand utiliser le motif singleton

Votre cas d'utilisation est l' un des meilleurs exemples de vouloir utiliser un singleton. Vous dites dans l'un des commentaires "Pour moi, l'exploitation forestière a toujours semblé un candidat naturel pour les Singletons." Tu as absolument raison .

Lorsque les gens disent que les singletons sont mauvais, la raison la plus courante est qu'ils sont un état partagé implicite . Alors qu'avec les variables globales et les importations de module de niveau supérieur , l'état partagé est explicite , les autres objets qui sont transmis sont généralement instanciés. C'est un bon point, à deux exceptions près .

Le premier, et celui qui est mentionné à divers endroits, est lorsque les singletons sont constants . L'utilisation de constantes globales, en particulier les énumérations, est largement acceptée et considérée comme raisonnable car, quoi qu'il arrive , aucun des utilisateurs ne peut les gâcher pour un autre utilisateur . Cela est également vrai pour un singleton constant.

La deuxième exception, qui est moins mentionnée, est l'inverse - lorsque le singleton n'est qu'un récepteur de données , pas une source de données (directement ou indirectement). C'est pourquoi les bûcherons se sentent comme une utilisation "naturelle" des singletons. Comme les différents utilisateurs ne modifient pas les enregistreurs de la manière dont les autres utilisateurs se soucieront, il n'y a pas vraiment d'état partagé . Cela annule l'argument principal contre le modèle singleton et en fait un choix raisonnable en raison de leur facilité d'utilisation pour la tâche.

Voici une citation de http://googletesting.blogspot.com/2008/08/root-cause-of-singletons.html :

Maintenant, il y a un type de Singleton qui est OK. C'est un singleton où tous les objets accessibles sont immuables. Si tous les objets sont immuables, Singleton n'a pas d'état global, car tout est constant. Mais il est si facile de transformer ce type de singleton en mutable, c'est une pente très glissante. Par conséquent, je suis contre ces Singletons aussi, non pas parce qu'ils sont mauvais, mais parce qu'il est très facile pour eux de se dégrader. (En guise de remarque, l'énumération Java n'est que ce genre de singletons. Tant que vous ne mettez pas d'état dans votre énumération, vous êtes OK, alors ne le faites pas.)

Les autres types de singletons, qui sont semi-acceptables sont ceux qui n'affectent pas l'exécution de votre code, ils n'ont aucun "effet secondaire". La journalisation en est un parfait exemple. Il est chargé de singletons et d'état global. C'est acceptable (car cela ne vous fera pas de mal) car votre application ne se comporte pas différemment, qu'un enregistreur donné soit activé ou non. Les informations ici circulent dans un sens: de votre application vers l'enregistreur. Même si les enregistreurs sont un état global car aucune information ne circule des enregistreurs vers votre application, les enregistreurs sont acceptables. Vous devez toujours injecter votre enregistreur si vous voulez que votre test confirme que quelque chose est en cours d'enregistrement, mais en général, les enregistreurs ne sont pas nocifs malgré leur état.

class Foo(object):
     pass

some_global_variable = Foo()

Les modules ne sont importés qu'une seule fois, tout le reste est sur-pensé. N'utilisez pas de singletons et essayez de ne pas utiliser de globaux.

Utilisez un module. Il n'est importé qu'une seule fois. Définissez-y des variables globales - ce seront les «attributs» de singleton. Ajoutez quelques fonctions - les «méthodes» du singleton.

Vous n'avez probablement jamais besoin d'un singleton en Python. Définissez simplement toutes vos données et fonctions dans un module et vous avez un singleton de facto.

Si vous devez vraiment absolument avoir une classe singleton, alors j'irais avec:

class My_Singleton(object):
    def foo(self):
        pass

my_singleton = My_Singleton()

Utiliser:

from mysingleton import my_singleton
my_singleton.foo()

où mysingleton.py est votre nom de fichier dans lequel My_Singleton est défini. Cela fonctionne car après la première importation d'un fichier, Python ne réexécute pas le code.

Voici une doublure pour vous:

singleton = lambda c: c()

Voici comment vous l'utilisez:

@singleton
class wat(object):
    def __init__(self): self.x = 1
    def get_x(self): return self.x

assert wat.get_x() == 1

Votre objet est instancié avec impatience. Cela peut ou non être ce que vous voulez.

Consultez la question Stack Overflow Existe-t-il un moyen simple et élégant de définir des singletons en Python? avec plusieurs solutions.

Je recommande fortement de regarder les exposés d'Alex Martelli sur les modèles de conception en python: partie 1 et partie 2 . En particulier, dans la partie 1, il parle de singletons / objets d'état partagés.

Voici ma propre implémentation de singletons. Tout ce que vous avez à faire est de décorer la classe; pour obtenir le singleton, vous devez ensuite utiliser la Instanceméthode. Voici un exemple:

   @Singleton
   class Foo:
       def __init__(self):
           print 'Foo created'

   f = Foo() # Error, this isn't how you get the instance of a singleton

   f = Foo.Instance() # Good. Being explicit is in line with the Python Zen
   g = Foo.Instance() # Returns already created instance

   print f is g # True

Et voici le code:

class Singleton:
    """
    A non-thread-safe helper class to ease implementing singletons.
    This should be used as a decorator -- not a metaclass -- to the
    class that should be a singleton.

    The decorated class can define one `__init__` function that
    takes only the `self` argument. Other than that, there are
    no restrictions that apply to the decorated class.

    To get the singleton instance, use the `Instance` method. Trying
    to use `__call__` will result in a `TypeError` being raised.

    Limitations: The decorated class cannot be inherited from.

    """

    def __init__(self, decorated):
        self._decorated = decorated

    def Instance(self):
        """
        Returns the singleton instance. Upon its first call, it creates a
        new instance of the decorated class and calls its `__init__` method.
        On all subsequent calls, the already created instance is returned.

        """
        try:
            return self._instance
        except AttributeError:
            self._instance = self._decorated()
            return self._instance

    def __call__(self):
        raise TypeError('Singletons must be accessed through `Instance()`.')

    def __instancecheck__(self, inst):
        return isinstance(inst, self._decorated)

La méthode 3 semble être très soignée, mais si vous voulez que votre programme s'exécute à la fois en Python 2 et Python 3 , cela ne fonctionne pas. Même la protection des variantes séparées avec des tests pour la version Python échoue, car la version Python 3 donne une erreur de syntaxe dans Python 2.

Merci à Mike Watkins: http://mikewatkins.ca/2008/11/29/python-2-and-3-metaclasses/ . Si vous voulez que le programme fonctionne à la fois en Python 2 et Python 3, vous devez faire quelque chose comme:

class Singleton(type):
    _instances = {}
    def __call__(cls, *args, **kwargs):
        if cls not in cls._instances:
            cls._instances[cls] = super(Singleton, cls).__call__(*args, **kwargs)
        return cls._instances[cls]

MC = Singleton('MC', (object), {})

class MyClass(MC):
    pass    # Code for the class implementation

Je suppose que «objet» dans l'affectation doit être remplacé par «BaseClass», mais je n'ai pas essayé cela (j'ai essayé le code comme illustré).

Eh bien, à part être d'accord avec la suggestion générale de Pythonic sur le fait d'avoir un niveau global au niveau du module, qu'en est-il:

def singleton(class_):
    class class_w(class_):
        _instance = None
        def __new__(class2, *args, **kwargs):
            if class_w._instance is None:
                class_w._instance = super(class_w, class2).__new__(class2, *args, **kwargs)
                class_w._instance._sealed = False
            return class_w._instance
        def __init__(self, *args, **kwargs):
            if self._sealed:
                return
            super(class_w, self).__init__(*args, **kwargs)
            self._sealed = True
    class_w.__name__ = class_.__name__
    return class_w

@singleton
class MyClass(object):
    def __init__(self, text):
        print text
    @classmethod
    def name(class_):
        print class_.__name__

x = MyClass(111)
x.name()
y = MyClass(222)
print id(x) == id(y)

La sortie est:

111     # the __init__ is called only on the 1st time
MyClass # the __name__ is preserved
True    # this is actually the same instance

Que dis-tu de ça:

def singleton(cls):
    instance=cls()
    cls.__new__ = cls.__call__= lambda cls: instance
    cls.__init__ = lambda self: None
    return instance

Utilisez-le comme décorateur dans une classe qui devrait être un singleton. Comme ça:

@singleton
class MySingleton:
    #....

Ceci est similaire au singleton = lambda c: c()décorateur dans une autre réponse. Comme l'autre solution, la seule instance a le nom de la classe ( MySingleton). Cependant, avec cette solution, vous pouvez toujours "créer" des instances (en fait obtenir la seule instance) à partir de la classe, en faisant MySingleton(). Il vous empêche également de créer des instances supplémentaires en faisant type(MySingleton)()(cela renvoie également la même instance).

Je vais jeter le mien dans le ring. C'est un simple décorateur.

from abc import ABC

def singleton(real_cls):

    class SingletonFactory(ABC):

        instance = None

        def __new__(cls, *args, **kwargs):
            if not cls.instance:
                cls.instance = real_cls(*args, **kwargs)
            return cls.instance

    SingletonFactory.register(real_cls)
    return SingletonFactory

# Usage
@singleton
class YourClass:
    ...  # Your normal implementation, no special requirements.

Avantages, je pense que cela a sur certaines des autres solutions:

• C'est clair et concis (à mes yeux; D).
• Son action est complètement encapsulée. Vous n'avez pas besoin de changer une seule chose au sujet de l'implémentation de YourClass. Cela inclut le fait de ne pas avoir besoin d'utiliser une métaclasse pour votre classe (notez que la métaclasse ci-dessus est en usine, pas la "vraie" classe).
• Il ne repose sur rien de patch de singe.
• C'est transparent pour les appelants:
  • Les appelants importent toujours simplement YourClass, cela ressemble à une classe (car c'est le cas), et ils l'utilisent normalement. Pas besoin d'adapter les appelants à une fonction d'usine.
  • Ce qui YourClass()instancie est toujours un véritable exemple de ce que YourClassvous avez implémenté, pas un proxy d'aucune sorte, donc aucune chance d'effets secondaires en résultant.
  • isinstance(instance, YourClass) et des opérations similaires fonctionnent toujours comme prévu (bien que ce bit nécessite abc, il empêche donc Python <2.6).

Un inconvénient me vient à l'esprit: les méthodes de classe et les méthodes statiques de la classe réelle ne peuvent pas être appelées de manière transparente via la classe d'usine qui la cache. Je l'ai utilisé assez rarement pour ne jamais rencontrer ce besoin, mais il serait facilement rectifié en utilisant une métaclasse personnalisée en usine qui implémente __getattr__()pour déléguer l'accès aux attributs tout-en-un à la classe réelle.

Un modèle connexe que j'ai trouvé plus utile (pas que je dis que ce genre de choses sont nécessaires très souvent) est un modèle "Unique" où l'instanciation de la classe avec les mêmes arguments aboutit à récupérer la même instance. C'est-à-dire un "singleton par arguments". Ce qui précède s'adapte bien à cela et devient encore plus concis:

def unique(real_cls):

    class UniqueFactory(ABC):

        @functools.lru_cache(None)  # Handy for 3.2+, but use any memoization decorator you like
        def __new__(cls, *args, **kwargs):
            return real_cls(*args, **kwargs)

    UniqueFactory.register(real_cls)
    return UniqueFactory

Cela dit, je suis d'accord avec l'avis général que si vous pensez avoir besoin de l'une de ces choses, vous devriez probablement vous arrêter un instant et vous demander si vous en avez vraiment besoin. 99% du temps, YAGNI.

• Si l'on veut avoir plusieurs instances de la même classe, mais seulement si les args ou kwargs sont différents, on peut utiliser ceci
• Ex.
  1. Si vous avez une classe gérant la serialcommunication, et pour créer une instance que vous souhaitez envoyer le port série comme argument, alors avec l'approche traditionnelle ne fonctionnera pas
  2. En utilisant les décorateurs mentionnés ci-dessus, on peut créer plusieurs instances de la classe si les arguments sont différents.
  3. Pour les mêmes arguments, le décorateur retournera la même instance qui a déjà été créée.

>>> from decorators import singleton
>>>
>>> @singleton
... class A:
...     def __init__(self, *args, **kwargs):
...         pass
...
>>>
>>> a = A(name='Siddhesh')
>>> b = A(name='Siddhesh', lname='Sathe')
>>> c = A(name='Siddhesh', lname='Sathe')
>>> a is b  # has to be different
False
>>> b is c  # has to be same
True
>>>

Code basé sur la réponse de Tolli .

#decorator, modyfies new_cls
def _singleton(new_cls):
    instance = new_cls()                                              #2
    def new(cls):
        if isinstance(instance, cls):                                 #4
            return instance
        else:
            raise TypeError("I can only return instance of {}, caller wanted {}".format(new_cls, cls))
    new_cls.__new__  = new                                            #3
    new_cls.__init__ = lambda self: None                              #5
    return new_cls


#decorator, creates new class
def singleton(cls):
    new_cls = type('singleton({})'.format(cls.__name__), (cls,), {} ) #1
    return _singleton(new_cls)


#metaclass
def meta_singleton(name, bases, attrs):
    new_cls = type(name, bases, attrs)                                #1
    return _singleton(new_cls)

Explication:

1. Créer une nouvelle classe, héritant de given cls
   (elle ne change pas clsau cas où quelqu'un le voudrait par exemple singleton(list))

2. Créez une instance. Avant de __new__passer outre, c'est si facile.

3. Maintenant, lorsque nous avons facilement créé une instance, remplace la __new__méthode définie il y a un instant.

4. La fonction instancene retourne que lorsque c'est ce que l'appelant attend, sinon il lève TypeError.
   La condition n'est pas remplie lorsque quelqu'un tente d'hériter d'une classe décorée.

5. Si __new__()renvoie une instance de cls, alors la __init__()méthode de la nouvelle instance sera invoquée comme __init__(self[, ...]), où self est la nouvelle instance et les arguments restants sont les mêmes que ceux passés à __new__().

   instanceest déjà initialisé, donc la fonction remplace __init__par la fonction qui ne fait rien.

Voyez-le travailler en ligne

Elle est légèrement similaire à la réponse de fab mais pas exactement la même.

Le contrat singleton n'exige pas que nous puissions appeler le constructeur plusieurs fois. Comme un singleton doit être créé une seule fois, ne devrait-il pas être vu comme créé une seule fois? «Usurper» le constructeur altère sans doute la lisibilité.

Donc, ma suggestion est juste ceci:

class Elvis():
    def __init__(self):
        if hasattr(self.__class__, 'instance'):
            raise Exception()
        self.__class__.instance = self
        # initialisation code...

    @staticmethod
    def the():
        if hasattr(Elvis, 'instance'):
            return Elvis.instance
        return Elvis()

Cela n'exclut pas l'utilisation du constructeur ou du champ instancepar code utilisateur:

if Elvis() is King.instance:

... si vous savez avec certitude que cela Elvisn'a pas encore été créé, et c'est le cas King.

Mais il encourage les utilisateurs à utiliser la theméthode de manière universelle:

Elvis.the().leave(Building.the())

Pour faire cela, vous pouvez également remplacer __delattr__()pour lever une exception si une tentative de suppression est effectuée instance, et remplacer __del__()pour qu'il déclenche une exception (sauf si nous savons que le programme se termine ...)

Améliorations supplémentaires

Mes remerciements à ceux qui ont contribué aux commentaires et aux modifications, dont d'autres sont les bienvenus. Bien que j'utilise Jython, cela devrait fonctionner plus généralement et être thread-safe.

try:
    # This is jython-specific
    from synchronize import make_synchronized
except ImportError:
    # This should work across different python implementations
    def make_synchronized(func):
        import threading
        func.__lock__ = threading.Lock()

        def synced_func(*args, **kws):
            with func.__lock__:
                return func(*args, **kws)

        return synced_func

class Elvis(object): # NB must be subclass of object to use __new__
    instance = None

    @classmethod
    @make_synchronized
    def __new__(cls, *args, **kwargs):
        if cls.instance is not None:
            raise Exception()
        cls.instance = object.__new__(cls, *args, **kwargs)
        return cls.instance

    def __init__(self):
        pass
        # initialisation code...

    @classmethod
    @make_synchronized
    def the(cls):
        if cls.instance is not None:
            return cls.instance
        return cls()

Points à noter:

1. Si vous ne sous-classez pas d'objet dans python2.x, vous obtiendrez une classe à l'ancienne, qui n'utilisera pas __new__
2. Lors de la décoration, __new__vous devez décorer avec @classmethod ou __new__sera une méthode d'instance non liée
3. Cela pourrait éventuellement être amélioré en utilisant une métaclasse, car cela vous permettrait de créer theune propriété de niveau classe, éventuellement en la renommantinstance

Un paquebot (je ne suis pas fier, mais ça fait l'affaire):

class Myclass:
  def __init__(self):
      # do your stuff
      globals()[type(self).__name__] = lambda: self # singletonify

Si vous n'avez pas besoin d'une initialisation paresseuse de l'instance de Singleton, alors ce qui suit devrait être facile et thread-safe:

class A:
    instance = None
    # Methods and variables of the class/object A follow
A.instance = A()

De cette façon, Aun singleton est initialisé lors de l'importation du module.

Peut-être que j'ai mal compris le motif singleton mais ma solution est aussi simple et pragmatique (pythonique?). Ce code remplit deux objectifs

1. Faire l'instance de Foo accessible partout (global).
2. Une seule instance de Foopeut exister.

Voici le code.

#!/usr/bin/env python3

class Foo:
    me = None

    def __init__(self):
        if Foo.me != None:
            raise Exception('Instance of Foo still exists!')

        Foo.me = self


if __name__ == '__main__':
    Foo()
    Foo()

Production

Traceback (most recent call last):
  File "./x.py", line 15, in <module>
    Foo()
  File "./x.py", line 8, in __init__
    raise Exception('Instance of Foo still exists!')
Exception: Instance of Foo still exists!

Après avoir lutté avec cela pendant un certain temps, j'ai finalement trouvé ce qui suit, de sorte que l'objet config ne soit chargé qu'une seule fois, lorsqu'il est appelé à partir de modules distincts. La métaclasse permet de stocker une instance de classe globale dans le dict intégré, qui semble actuellement être le moyen le plus pratique de stocker un programme global approprié.

import builtins

# -----------------------------------------------------------------------------
# So..... you would expect that a class would be "global" in scope, however
#   when different modules use this,
#   EACH ONE effectively has its own class namespace.  
#   In order to get around this, we use a metaclass to intercept
#   "new" and provide the "truly global metaclass instance" if it already exists

class MetaConfig(type):
    def __new__(cls, name, bases, dct):
        try:
            class_inst = builtins.CONFIG_singleton

        except AttributeError:
            class_inst = super().__new__(cls, name, bases, dct)
            builtins.CONFIG_singleton = class_inst
            class_inst.do_load()

        return class_inst

# -----------------------------------------------------------------------------

class Config(metaclass=MetaConfig):

    config_attr = None

    @classmethod
    def do_load(cls):
        ...<load-cfg-from-file>...

Je ne me souviens pas où j'ai trouvé cette solution, mais je la trouve la plus «élégante» de mon point de vue non expert en Python:

class SomeSingleton(dict):
    __instance__ = None
    def __new__(cls, *args,**kwargs):
        if SomeSingleton.__instance__ is None:
            SomeSingleton.__instance__ = dict.__new__(cls)
        return SomeSingleton.__instance__

    def __init__(self):
        pass

    def some_func(self,arg):
        pass

Pourquoi j'aime ça? Pas de décorateurs, pas de méta-classes, pas d'héritage multiple ... et si vous décidez que vous ne voulez plus que ce soit un Singleton, supprimez simplement la __new__méthode. Comme je suis nouveau sur Python (et OOP en général), je m'attends à ce que quelqu'un me dise pourquoi cette approche est terrible?

C'est ma façon préférée d'implémenter des singletons:

class Test(object):
    obj = None

    def __init__(self):
        if Test.obj is not None:
            raise Exception('A Test Singleton instance already exists')
        # Initialization code here

    @classmethod
    def get_instance(cls):
        if cls.obj is None:
            cls.obj = Test()
        return cls.obj

    @classmethod
    def custom_method(cls):
        obj = cls.get_instance()
        # Custom Code here

Cette réponse n'est probablement pas celle que vous recherchez. Je voulais un singleton dans le sens où seul cet objet avait son identité, par rapport à. Dans mon cas, il était utilisé comme valeur sentinelle . Pour lequel la réponse est très simple, faites n'importe quel objet mything = object()et par nature de python, seule cette chose aura son identité.

#!python
MyNone = object()  # The singleton

for item in my_list:
    if item is MyNone:  # An Example identity comparison
        raise StopIteration

Cette solution provoque une certaine pollution de l'espace de noms au niveau du module (trois définitions plutôt qu'une seule), mais je la trouve facile à suivre.

J'aimerais pouvoir écrire quelque chose comme ça (initialisation paresseuse), mais malheureusement les classes ne sont pas disponibles dans le corps de leurs propres définitions.

# wouldn't it be nice if we could do this?
class Foo(object):
    instance = None

    def __new__(cls):
        if cls.instance is None:
            cls.instance = object()
            cls.instance.__class__ = Foo
        return cls.instance

Comme cela n'est pas possible, nous pouvons décomposer l'initialisation et l'instance statique dans

Initialisation désirée:

import random


class FooMaker(object):
    def __init__(self, *args):
        self._count = random.random()
        self._args = args


class Foo(object):
    def __new__(self):
        return foo_instance


foo_instance = FooMaker()
foo_instance.__class__ = Foo

Initialisation paresseuse:

Initialisation désirée:

import random


class FooMaker(object):
    def __init__(self, *args):
        self._count = random.random()
        self._args = args


class Foo(object):
    def __new__(self):
        global foo_instance
        if foo_instance is None:
            foo_instance = FooMaker()
        return foo_instance


foo_instance = None