Proposal: default __init__

Alex Martelli aleaxit at yahoo.com
Mon Nov 13 14:53:32 EST 2000


"Fredrik Lundh" <fredrik at effbot.org> wrote in message
news:1xVP5.5768$jv2.681460 at newsc.telia.net...
    [snip]
> also see "Calling Base Class Methods" at:
>
>     http://www.kuchling.com/python/writing/warts.html

Seen, and -- I don't get it.  The crucial claim, the one that
_would_ urgently require a redesign (were it true!), is:

"""
Worse, this embodies knowledge of the object hierarchy in the __init__
method.
If you have an inheritance chain A -> B -> C, where A and C both have
__init__
methods and B doesn't, then C.__init__ must call A.__init__; the programmer
must keep in mind that B lacks a constructor. If you later add a constructor
to B,
you have to remember to fix C.__init__
"""

...???  Come again?  "C.__init__ must call A.__init__"
rather than B.__init__...?  Why ever...?

>>> class A:
 def __init__(self):
  print 'A.init'


>>> class B(A):
 pass

>>> class C(B):
 def __init__(self):
  print 'C.init'
  B.__init__(self)


>>> x=C()
C.init
A.init
>>>

Why should class C, or the programmer thereof,
"keep in mind that B lacks a constructor"???  B
_doesn't_ "lack a constructor", as hasattr will
confirm...:

>>> hasattr(B, '__init__')
1

B does have an __init__ attribute -- it gets it
through inheritance from A, of course, but why
should anybody care about that detail?


Am I having hallucinations, are Michael Hudson
(and AMK) having them, or did this use to work
differently in some ancient Python (before 1.5.2,
which is where I came in...) and was fixed in
the last couple of years or so...?

(It's surely so for the other, minor sub-nit under
the same heading, since the ** syntax for calls
has been adopted in 1.6 -- hooray, and no doubt
thanks to these suggestions/observations too.
But the page only claims accuracy to 1999-12-31,
with a 'last modified' of 2000-05-31, so 1.6 and
2.0 enhancements' lack is unsurprising; the main
issue under discussion here surely wasn't
changed at least since Python 1.5.2....).


Alex






More information about the Python-list mailing list