inherit without calling parent class constructor?

Christian Dieterich cdieterich at geosci.uchicago.edu
Thu Jan 27 18:50:47 EST 2005


On Déardaoin, Ean 27, 2005, at 14:05 America/Chicago, Jeff Shannon 
wrote:

> True, in the sense that B is instantiated as soon as a message is sent 
> to D that requires B's assistance to answer.  If the "decision" is a 
> case of "only calculate this if we actually want to use it", then this 
> lazy-container approach works well.  If the decision requires

Yes, I see this advantage of a lazy container. Seems perfect to do 
something on request. See also below.

> the descriptor approach does.  In either case, the calculation happens 
> as soon as someone requests D.size ...

Agreed. The calculation happens as soon as someone requests D.size. So 
far so good. Well, maybe I'm just not into it deep enough. As far as I 
can tell, In your class D the calculation happens for every 
instantiation of D, right? For my specific case, I'd like a construct 
that calculates D.size exactly once and uses the result for all 
subsequent instantiations.

> If it will work for numerous D instances to share a single B instance 
> (as one of your workarounds suggests), then you can give D's 
> __init__() a B parameter that defaults to None.

This sounds as if B needs to instantiated only once. In your example 
self._B is None for every new instantiation of D and then __getattr__() 
makes a new instances of self.B.

> (However, from your other descriptions of your problem, it does sound 
> like a property / descriptor is a better conceptual fit than a 
> contained class is.  I mostly wanted to point out that there are other 
> ways to use OO than inheritance...)

I appreciate your input anyway. Thinking of how I could use containers 
it became clear, that I'm going to use them for something else, where I 
want something to be calculated upon request only.

Christian




More information about the Python-list mailing list