__init__(self, *args, **kwargs) - why not always?

Jim Jewett JimJJewett at yahoo.com
Mon Jan 19 22:58:05 CET 2004


Normally, I expect a subclass to act in a manner consistent 
with its Base classes.  In particular, I don't expect to 
*lose* any functionality, unless that was the whole point of 
the subclass.  (e.g., a security-restricted version, or an
interface implementation that doesn't require a filesystem.)

One (common?) exception seems to occur in initialization.  I 
understand stripping out arguments that your subclass explicitly 
handles or replaces.  A subclass intended to restrict access 
might even "handle" all unknown arguments.  But for the general 
case, is there any reason *not* to pass unhandled initializer 
arguments to the parent classes?

More specifically, is there any reason not to replace:

    class SubClass(BaseClass):
        def __init__(self):
            BaseClass.__init__(self)

with: 

    class SubClass(BaseClass):
        def __init__(self, *args, **kwargs):
            BaseClass.__init__(self, *args, **kwargs)

on a near-global basis?  

--------

Bug 876421 provides an example surprise in the standard library.  

http://sourceforge.net/tracker/?func=detail&atid=105470&aid=876421&group_id=5470

SubClass(level=ERROR) throws an exception, even though
BaseClass(level=ERROR) works, and level=ERROR was still
valid to the subclass, with the same meaning.  

I expect that variations on verbosity will be a common 
pass-through argument in many types of code.

--------

Yes, I realize that changing BaseClass.__init__(...) 
to super.__init__(...) may be better still, but that 
discussion is orthogonal to this question.

Yes, I would have preferred that the interpreter add
the (possibly modified) *args and **kwargs automatically, 
but I do realize that it is too late for that change.

-- 
 -jJ  Take only memories.  Leave not even footprints.



More information about the Python-list mailing list