__init__ keyword param for sub-class?

Fred L. Drake, Jr. fdrake at acm.org
Thu Dec 23 15:00:00 EST 1999


Grant Edwards writes:
 > In Python is it considered good practice for methods/functions
 > to complain about unrecognized keyword options, or are they
 > generally just ignored?

  I'd say that in the "normal" case, where the keywords are named in
the function signature rather than accepted as **kw, the names are
checked.  It is an error to pass a keyword arg that isn't used:

	>>> def func(abc=0): pass
	... 
	>>> func(bar=2)
	Traceback (innermost last):
	  File "<stdin>", line 1, in ?
	TypeError: unexpected keyword argument: bar

 > One thing I miss from having used Smalltalk is some general way
 > to refer to the superclass.  Having a method specify the
 > superclass explicitly hampers reuse (at least in theory), and
 > seems a bit more fragile.  I've read that picky a superclass
 > method would get sticky in a multiple inheritence system, but

  That's right; for:

	class A:
            def aMethod(self): pass
        class B:
            def aMethod(self): pass
        class C(A, B):
            def aMethod(self):
                super.aMethod()

the only way to resolve it is to use the same search pattern as normal 
method lookup in C.__bases__.  But it's not clear that its a good
idea.
  There's also an issue of introducing new keywords or some way to
name the thing called "super" in my example.  I don't know of any
languages that let you name it within; they all seem to use a
keyword.  And introducing new keywords is *hard*; something like
"super" isn't even an unreasonable variable name (it's either a
boolean or a SuperHero instance, right? ;).

 > the same issue comes up with overlapping superclass methods
 > that the subclass doesn't override.  Right? So, I don't know
 > why we couldn't use the same mechanism to pick
 > Super.methodName() that would be used to do self.methodName()
 > when methodName isn't overridden.

  Ah, I should have read farther.
  I think the biggest problem is the introduction of additional
keywords; I don't see a good way to get around that in 1.x.  Perhaps
this should be discussed as a 2.0 feature?  It's certainly requested a 
lot, and with good reason.


  -Fred

--
Fred L. Drake, Jr.	  <fdrake at acm.org>
Corporation for National Research Initiatives




More information about the Python-list mailing list