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

[Jim Jewett]

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...&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.

[Gerrit Holl]

Jim Jewett wrote:

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?

A subclass may be a specialized case, e.g.:

class Tree:
def __init__(self, evergreen=False):
...

class Spruce(Tree):
def __init__(self):
Tree.__init__(self, True)

or the other way around, e.g.

class Enemy:
def __init__(self, pos):
...

class ShootingEnemy(Enemy):
def __init__(self, pos, bullets):
Enemy.__init__(pos)
...

In both cases I don't want to BaseClass.__init(self, *args, **kwargs)...

yours,
Gerrit.

--
105. If the agent is careless, and does not take a receipt for the
money which he gave the merchant, he can not consider the unreceipted
money as his own.
-- 1780 BC, Hammurabi, Code of Law
--
PrePEP: Builtin path type
http://people.nl.linux.org/~gerrit/c.../pep-xxxx.html
Asperger's Syndrome - a personal approach:
http://people.nl.linux.org/~gerrit/english/

[Jim Jewett]

I'm still not sure I understand the objection, as I would
still have wanted the extension even in your examples.

So I've gone into a bit more detail, and generalized the
replacement.
Is there any reason not to replace replace:

class SubClass(BaseClass):
def __init__(self, [what you used to take]):
BaseClass.__init__(self, [what you used to send])

with:

class SubClass(BaseClass):
def __init__(self, [what you used to take], *args, **kwargs):
BaseClass.__init__(self, [what you used to send], *args, **kwargs)

on a near-global basis?

Gerrit Holl <ge****@nl.linux.org> wrote in message
news:<ma**************************************@pyt hon.org>...

A subclass may be a specialized case, e.g.: class Tree:
def __init__(self, evergreen=False):
... class Spruce(Tree):
def __init__(self):
Tree.__init__(self, True)
I do understand that you will sometimes need to
modify the argument (or keywords) based on your
subclass' needs. My question is about unexpected
input -- which you might get if the base class is
later enhanced. What is wrong with the following:

class Spruce(Tree):
"Spruce are evergreen."
def __init__(self, *args, **kwargs)
eg = kwargs.pop('evergreen', True)
Tree.__init__(self, eg, *args, **kwargs)

or

class Spruce(Tree):
"Spruce are always evergreen, you annoying user!"
def __init__(self, *args, **kwargs)
kwargs['evergreen'] = True
Tree.__init__(self, *args, **kwargs)
These will work even if tree is later enhanced to keep
track of which trees need extra attention.

class Tree:
def __init__(self, evergreen=False, healthy=True):
...
or the other way around, e.g. class Enemy:
def __init__(self, pos):
... class ShootingEnemy(Enemy):
def __init__(self, pos, bullets):
Enemy.__init__(pos)
... In both cases I don't want to BaseClass.__init(self, *args, **kwargs)...

class ShootingEnemy(Enemy):
def __init__(self, pos, bullets, *args, **kwargs):
Enemy.__init__(self, pos, *args, **kwargs)

indicates that the base class also needed to see position.
This wouldn't take any special thought that wasn't already
required by passing position in your original example.

And again, it would remove some fragility in case the Enemy
class is later extended to indicate which army it is from,
or what type of unit.

--

-jJ Take only memories. Leave not even footprints.