consequences of not calling object.__init__?

Jorge Luiz Godoy Filho godoy at ieee.org
Tue Dec 28 22:20:13 EST 2004


Peter Hansen, Quarta 29 Dezembro 2004 01:04, wrote:

> Maybe there's no such pronouncement, but unless there is a
> clear statement somewhere (and I believe I've missed it, if
> there is) that reads "one should *always* call __init__ on the
> superclass even if one is just subclassing object and not
> dealing with multiple inheritance situations", then I would
> submit that the majority of Python code written using new-style
> classes would be broken should what you suggest above ever
> actually happen...  starting with much of the code in the
> standard library (based on a quick glance at those modules
> whose contents match the re pattern "class .*(object):" .

Things are kind weird at this point, since there are too many things to
think about and to make a decision on what should be done and what is
recommended to be done...

Quoting from http://www.python.org/peps/pep-0008.html:

"""
(...)
Designing for inheritance
(...)
      Also decide whether your attributes should be private or not.
      The difference between private and non-public is that the former
      will never be useful for a derived class, while the latter might
      be.  Yes, you should design your classes with inheritence in
      mind!
(...)
"""

So, I don't really know which is correct: to always call the constructor of
the parent class or just do that when it is needed by design... 

I think that based on the above quotation from PEP-0008 code in the standard
library should be calling the parent class constructor.  But then, I'm one
of the people who never do that :-)

-- 
Godoy.     <godoy at ieee.org>




More information about the Python-list mailing list