python constructor overloading

[Gordon McMillan]

Greg Copeland wrote:

> Darrell wrote:
> > 
> > Keeping a reference to the caller can setup a circular
> > reference. Which means memory leak. You might pass id(caller)
> > and have a place to map from id ==> caller.
> 
> In this particular case, I wouldn't expect this to happen.  Since
> the container should technically live longer than the contained. 
> In short, if the container is gone, everything within it should
> also be gone.  No memory leaked.

Bzzt. The container is unavailable, but unless you specifically 
clear it, it will still exist, because it's ref count hasn't gone to 
zero because there are objects (which happen to be inside it) 
which still reference it.

[subclassing]
 
> Obviously, I want to keep all of the existing engine's
> functionality, but simply extend it with the turbo's boost
> methods.  As I understand it, you can't do this?!?!?  If I
> understand you correctly, I have to re-implement engine's
> constructor and extend it in the turboEngine's constructor.

You have to call the base class's __init__ explicitly. __init__ 
isn't actually a "constructor", it is an "initializer". In other 
words, "self" is the real, final thing when __init__ runs; you 
just get to set up it's state, not influence it's construction.

There's nothing automatic about __init__, which is why mixins 
are easy and useful in Python (but rarely so elsewhere).

>  If
> that's the case, I greatly condom the OO-implementation of
> python.  

Now that's a Freudian slip if I've ever seen one.

> So it isn't so.  If this is that case, I'd say the
> python authors have been using MFC way too much!  :P~

I can assure you that Python's principle author wouldn't 
recognize MFC if it stole all his condoms.
 


- Gordon