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