super bug?

[Terry Reedy]

"Michal Wallace" <sabren at manifestation.com> wrote in message
news:mailman.1012233824.26238.python-list at python.org...
> >>> print super.__doc__
> super(type) -> unbound super object
> super(type, obj) -> bound super object; requires isinstance(obj,
type)
> super(type, type2) -> bound super object; requires issubclass(type2,
type)
> Typical use to call a cooperative superclass method:
> class C(B):
>     def meth(self, arg):
>         super(C, self).meth(arg)
>
> ## BUT....
> >>> class B:
> ...     def meth(self, arg):
> ...         print arg
> ...
> >>> class C(B):
> ...     def meth(self, arg):
> ...         super(C, self).meth(arg)
> ...
> >>> C().meth("huh?")
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "<stdin>", line 3, in meth
> TypeError: super() argument 1 must be type, not class

This is exactly what docstring says in the first three lines, where,
by implication of the third line, 'type' includes type-classes
ultimately derived from a builtin type.  As a non-expert on the new
stuff, I suspect but do not guarantee that deriving B from 'object',
which seems to be the new generic type made for this purpose, may give
a better result:

>>>class B(object): # Does this work better?

It seems that the effort to heal the type/class split has, for the
present, moved the split to one between class-classes and type-classes
(the latter still being somewhat experimental and in flux).  I presume
and speculate that the eventual solution will be to make 'object' the
default base of all classes and that doing so without 'from future
import ...' will be one of the marks of Python 3.

Terry J. Reedy