Home Original page

Borg - is that a singleton?

Alex Martelli aleax at aleax.it
Sat Mar 1 02:14:59 EST 2003 
Graham Fawcett wrote:
   ...
> Remember that Borg is a *design pattern*. I don't think it was ever
> intended for use as a base class of your class hierarchy.

No problem using it as a base class -- as long as you use it
_advisedly_.  http://www.aleax.it/Python/5ep.html has more
info about that, and shows the following snippet:

class Borg:
    _shared_state = {}
    def __init__(self):
        self.__dict__ = self._shared_state

note only ONE leading underscore to the shared state dict --
that's key.  Immediately afterwards, the text explains:

"""
Your class may in turn override Borg's _shared_state class attribute. 
It is exactly in order to allow this "data override" that 
Borg.__init__ accesses the attribute through self, not directly by
qualifying Borg, and the attribute's name has one leading underscore, 
not two. This data-member overriding, or lack thereof, determines 
whether your class also shares state with other subclasses of Borg: 
you can easily arrange this in different ways, but, of course, 
resistance is futile, so don't even bother trying to arrange that.
"""

In other words:


> You would "borgify" your classes *individually* :

Sure, if that's what you wish.

> class Foo:
>     __shared_state = {}
>     def __init__(self):
>         self.__dict__ = self.__shared_state

Too much work!  Just:

class Foo(Borg): _shared_state = {}

> class Bar:
>     __shared_state = {}
>     def __init__(self):
>         self.__dict__ = self.__shared_state

Ditto: just

class Bar(Borg): _shared_state = {}


> In other words, imitate the Borg class, don't subclass it. There are,
> after all, only two relevant lines of code to add -- an easy task.

But with subclassing AND data override, it's even easier.  The
power of Python often avoids the need for much "copy and paste
coding", in favour of reuse -- and this can be such a case.


Alex
More information about the Python-list mailing list