Second argument to super().

[Tobiah]

What is the purpose of the second argument to super()?

What is meant by the returning of an 'unbound' object
when the argument is omitted.

Also, when would I pass an object as the second argument,
and when would I pass a type?

Thanks,

Tobiah

 

[Steven Bethard]

What is the purpose of the second argument to super()?

You probably want to check the docs[1] again. They give an example:

class C(B):
def meth(self, arg):
super(C, self).meth(arg)

What is meant by the returning of an 'unbound' object
when the argument is omitted.

If you supply a second argument (an instance of the type) to super, the
returned object will be bound to that instance. For example:

py> class C(object):
.... def g(self):
.... print 'g'
....
py> class D(C):
.... def h(self):
.... print 'h'
....
py> d = D()
py> s = super(D, d)
py> d2 = D()
py> s2 = super(D, d2)
py> s == s2
False

Note that the object returned depends on the instance passed in. An
'unbound' object would not be bound in this way to the instance.

Note also that the super object returned has access only to the methods
of the superclass:

py> s.g
<bound method D.g of <__main__.D object at 0x01186130>>
py> d.g
<bound method D.g of <__main__.D object at 0x01186130>>
py> s.h
Traceback (most recent call last):
File "<interactive input>", line 1, in ?
AttributeError: 'super' object has no attribute 'h'
py> d.h

Also, when would I pass an object as the second argument,
and when would I pass a type?

For most use cases, you'll probably only want an object (an instance).
You might run into the type case if you define the staticmethod __new__
in a class:

py> class S(str):
.... def __new__(cls, s):
.... return super(S, cls).__new__(cls, 'S(%s)' %s)
....
py> S('abc')
'S(abc)'

In this case __new__ takes as a first argument the class (type) of the
object, so if you want to invoke the superclass __new__, you need to
pass the type to super. (You don't have an instance to pass.)


STeVe

[1] http://docs.python.org/lib/built-in-funcs.html#l2h-70

 

[John Roth]

What is the purpose of the second argument to super()?

I've always found the docs to be fairly confusing.
They didn't give me enough context to tell what
was going on. I also find the terminology confusing:
"type" seems to mean "new style class object", and
"object" seems to mean "instance."

What happens with the second operand is a bit of
sleight of hand. The object returned from super()
gives you access to the methods on the next level up the
mro, however when you use it to invoke a method,
then the 'self' passed to that method is the second
object, not the instance returned from super().

In most cases, this is exactly what you want, since if
the superclass method makes any changes to the
instance, you want to be able to see them after the
call completes.

What is meant by the returning of an 'unbound' object
when the argument is omitted.

This is basically for calling static methods. Since a static
method is not passed an instance, you need a version of
the object returned from super() that doesn't bind the
method to an instance.

There is also the possibility that you might really want
to call an instance or class method as an unbound method,
explicitly passing it the instance. This is the reason that
the object returned from super() can't make the distinction
automatically by simply checking for a static method.

Also, when would I pass an object as the second argument,
and when would I pass a type?

You need to pass the class object when you're calling
a class method. While __new__ is technically a static
method, for most practical purposes you can regard
it as a class method.

John Roth

 

[Steve Holden]

I've always found the docs to be fairly confusing.
They didn't give me enough context to tell what
was going on. I also find the terminology confusing:
"type" seems to mean "new style class object", and
"object" seems to mean "instance."

I agree that the docs could probably do with some improvement here, but
this is mostly because (I suspect) the type-based material has been
shoehorned in to the existing documentation structure. My own suspicion
was that a more radical revision would yield a better manual, but it
doesn't look as though anybody has had time to attempt it.

Certainly super() is some of the deepest magic related to the new-style
object hierarchy.

What happens with the second operand is a bit of
sleight of hand. The object returned from super()
gives you access to the methods on the next level up the
mro, however when you use it to invoke a method,
then the 'self' passed to that method is the second
object, not the instance returned from super().

This is a key point. I wonder whether we might use this thread to draft
a patch to the docs for submission on SourceForge?

In most cases, this is exactly what you want, since if
the superclass method makes any changes to the
instance, you want to be able to see them after the
call completes.

Quite. It's important that super() doesn't create a completely new
object, because it's really about identifying an appropriate point in
the inheritance hierarchy (method resolution order) and offering
namespace access from that point up, rather than from the base instance
given as the second argument to super(). This means that the same code
can be included in many different namespace hierarchies and still work
correctly in them all.

This is basically for calling static methods. Since a static
method is not passed an instance, you need a version of
the object returned from super() that doesn't bind the
method to an instance.

There is also the possibility that you might really want
to call an instance or class method as an unbound method,
explicitly passing it the instance. This is the reason that
the object returned from super() can't make the distinction
automatically by simply checking for a static method.



You need to pass the class object when you're calling
a class method. While __new__ is technically a static
method, for most practical purposes you can regard
it as a class method.

This is all good stuff. We should try to make sure the documentation
gets enhanced.

regards
Steve

 

[Colin J. Williams]

These are certainly basic terms. It could help to a glossary setting
out just what these terms mean.

In some cases type and class are used synonomously. Clarification would
help us all.

I agree that the docs could probably do with some improvement here, but
this is mostly because (I suspect) the type-based material has been
shoehorned in to the existing documentation structure. My own suspicion
was that a more radical revision would yield a better manual, but it
doesn't look as though anybody has had time to attempt it.

A radical revision here would certainly help.

Colin W.

 

[Steven Bethard]

This is a key point. I wonder whether we might use this thread to draft
a patch to the docs for submission on SourceForge?

Done:

www.python.org/sf/1163367

It's nowhere near perfect, but I think it at least somewhat more
accurately reflects the actual workings of super. If you have any good
clarifications or rewordings, please feel free to add them to the tracker.


While I also agree that the documentation needs a major revamp to
properly show the interworkings of all the new-style class components, a
patch for super is about the best I can offer at the moment. =)

STeVe