Borg - is that a singleton?

[Alex Martelli]

Giovanni Bajo wrote:

> 
> "Alex Martelli" <aleax at aleax.it> ha scritto nel messaggio
> news:f3_7a.342065$AA2.12778796 at news2.tin.it...
> 
>> I find your suggested approach a bit fragile, because it conflates
>> issues of class initialization with ones of instance initialization.
>> Consider, with your implementation of Borg:
>>
>> class Super(Borg): pass
>> class Sub(Super): pass
>>
> 
> I had some feeling my code was weak wrt inheritance, thanks for clarifying
> this.
> You say that my code is conflating "class initialization" and "instance
> initialization". Would you please elaborate on this issue? Can you show me
> in my code what is part of "class inizialization" and what of "instance
> initialization", and why is it bad to keep them together?

Class initialization happens when the class statement executes.

Instance initialization happens when you call the class.

In your __init__ (a method which executes at instance initialization
time) you conditionally set a class attribute -- a task that logically
forms a part of class initialization, not one of instance initialization.

It's bad to confuse the two things exactly because of the example
I brought above (and which you partly snipped).  One would NOT
normally expect (nor desire) the contents of class objects Super
and Sub to depend on which one happens to be instantiated (called)
before the other.  Yet, if you do class initialization as a side
effect of instance initialization, it's hard to avoid such obscure
misbehaving cases.


> As a Python beginner (with C++ background), I was not able to find

I sympathize -- in C++ classes are not first-class objects (you cannot
create nor manipulate them at runtime), so, if that's where you come
from in terms of OO, it can indeed take quite a bit to shift over to
a mental world where class ARE first-class objects like any other.

> satisfactory documents explaining how to code OO in a stricly pythonic
> way, which is a bit frustrating, because I am just looking at others' code
> snippets to learn. This helps of course, but I would be more comfortable
> if I could read some essay on it. Any suggestion?

I've done my best on the subject in my introduction to the Object-Oriented
chapter of the Python Cookbook (O'Reilly) -- that is, of course, my best
within the constraints of spending just a few pages on the subject.  There
are also quite a few recipes there that will, IMHO, help you about this.

I've gotten back to the same subject in the Object-Oriented chapter of
Python in a Nutshell -- again, I did my best within the constraints of
spending just a few dozen pages on the subject.

Maybe one day I'll realize my long-held dream of writing a book by some
such title as "Mastering Object-Oriented Programming and Design Patterns
with Python", or the like, and then I won't have any excuses if I don't do
the subject full justice.  Notice that, most likely, most of the contents 
of that book (a book which will remain hypothetical for quite a while,
since, having just ended putting the final touches on the Nutshell, I _do_
want a break from book-writing for a while!-) will be reworking and
rewording of stuff I _have_ already written -- in the Nutshell, in the
Cookbook (counting both recipes and chapter-introduction), in articles
or papers for various conferences (for example, see my paper on Borg, as
presented at IPC11, at http://www.aleax.it/Python/5ep.html), and last
but not least in many, MANY posts to this newsgroup (and a more modest
number of posts, in Italian, to newsgroups such as it.comp.lang and to
the Italian Python mailing list, see www.python.it for archives).

For example, Google's advanced group search finds a bit more than 1000
posts I have written to comp.lang.python containing the word "class".
Most of the work for the future hypothetical book will be one of
finding, regrouping, reorganizing and restructuring such material into
a systematic framework, I think -- much of the substance IS already
there, though of course not yet with any systematic organization to it.


>> in class scope, you're probably better off generating the magic
>> _shared_state in a custom metaclass, e.g.:
> 
> I still need to look at metaclasses, so your code is black magic for me,
> right now :) I will review your code later, thanks anyway.

You're welcome.  A metaclass is just the class to which another class
belongs -- since classes are normal objects, they too belong to a class
(aka, a type), of course.  So, there's no black magic involved (and
that is part of the beauty of Python!).  BTW, if in the above-mentioned
google search you use "metaclass" as the keyword rather than "class",
you end up with just 90 posts -- so, browsing through them may not be
all that much of a chore;-).


Alex