instance creatiion as an "event"

Arthur ajsiegel at
Tue Apr 22 15:40:13 CEST 2003


>I don't understand this. When you call:

>p = TestPoint(args)

>it's EXACTLY AS IF TestPoint.__init__'s very last statement was


Standalone, yes.  But, unless I'm missing something, the effects in an
inheritance chain is different. If I inherit from TestPoint, and need to
call TestPoint.__init__ in the Point_Child.__init__ to pick up initilization
routines common to the chain, I will now unavoidably be calling TestPoint's
redraw method before I call Point_Child's.  When the main reason I am
inheriting from TestPoint is to override its redraw method, and in fact to
avoid calling it.  If TestPoint has attributes that Point_Child does not
that are referenced in its redraw method, I will have an attribute error on
the calling of TestPoint's redraw form Point_Child.

This is the crux of the problem as I see it, and I am prepared to be
embarrassed if I am misinterpreting the behavior under these circumsntances

Perhaps a "try:.... except AttributeError: pass" for all redraw methods
would be a straightforward solution to this issue. But does not seem fully
elegant.  There are cases where the attributes are in fact the same, but the
routines very different - a Point determined as the circumcenter of a
circle, versus a Point determined as an incenter of a circle.  True, these
classes would more likely be siblings, than parent/child.  So perhaps I am
suffereing from trying to be overly theorectical and pure.  On the other
hand, I am hoping for a design that is "naively" extensible.  Someone coming
in to extend and doing so by inheriting from an existing class would,
ideally, not need to be in touch with concerns at this level.

Next step is to try to digest the implications for my "real world" in your
suggestion as to working with the condition

if hasattr(sys, 'ps1')

Thanks .


More information about the Python-list mailing list