__init__

Chris Hoffmann (choffman@vicorp.com)
Tue, 18 May 93 09:56:07 EDT

I prefer option (1), have the derived class explicitly call the
initializers for the base classes.

I don't like the main(argc,argv) suggestion of Rob Hegt as the
arguments for the base class initializers may not even be in the
arguments for the derived class--the derived class may want to
synthesize them from the arguments it receives.

Personally, I think the idea that the derived class must explicitly
initialize the base class(es) and there are no implicit
initializations is perfectly acceptable. It's simple to explain and
the code is easier to understand (at least for me) as there are no
"hidden" function calls.

In other words, if you're going to have to allow explicit base class
initializations anyway, and I think you do, make them always required.
I'd like python to stay as lean as possible, so I'd rather not clutter
the language by having to support implicit initializations. (There
are plenty of more useful things we can choose from when it comes time
to clutter!)

By the way, will there be a __del__(self) method that is called at
destruction time? My thought on this was that when python sees that an
object should be garbage collected, it calls the object's __del__
method (if any) before actually destroying it. Of course the
interpreter would have to check the object's refcount after calling
the function, as the method may have caused the object to be
referenced by some other object.

I don't really have a good example of why you'd want this, other than
for creating classes that keep track of how many instances of the
class exist. Perhaps someone else can think of a good reason for
having it. It just seems that if you have a function that is called at
object creation that you should have one that is called at object
destruction as well.

Chris

-----------------------------------------------------------------------------
Chris Hoffmann VI Corporation
choffman@vicorp.com 47 Pleasant St. Northampton MA 01060