python constructor overloading

[Greg Copeland]

Gordon McMillan wrote:
> 
> 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.

Thanks for spelling this out.  I had, however, already read about this
issue.  My objects will be explicitly collected (at least, my intent is
to).  Err, rather, I assume that 'sys.exc_traceback = None' will do this
after the contained have lived their life?  I poorly expressed my self
here as I didn't believe it to be central to my point of contention. 
Thanks.  I'll pay more attention next time!  :) 

> 
> [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.

Hmmm.  I'll try again.  I guess it was something I was doing wrong.  I
was getting an unbound method error.  As for the constructor/initializer
reference.  To me, it looks like python's equivalent to a C++
constructor, so that's what I called it.  Is "initializer" the correct
terminology for python?

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

Can you expand on this a bit?  Everything I've seen suggests that
__init__ is automatic.  If you can point me to some read'n here, that
would be great.  I'm also not sure how a mixin would help here, other
than to provide a method that accepts the reference to the container. 
Obviously, you've pushed me to something that "feels" better, but isn't
exactly what I was hoping for.  Still, I say thanks!

> 
> >  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.
> 

Spell checkers are just dandy.  I originally misspelled it.  The spell
checker gave me that and OBVIOUSLY didn't catch it...in time.  I saw it
right after I hit the send button.  Grrr...


> > 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.

:)  Cute!

> 
> 
> - Gordon

Greg


P.S.  I'm expecting my Python books to be here this week...  :)