== An interesting way to shoot yourself in the foot and a limitation of _super()_

Presented in the traditional illustrated form, for Python 2:

 class Base(object):
   def foo(self):
     print "base foo"
 
 class A(Base):
   def foo(self):
     print "A foo"
     return super(A, self).foo()
 
 class B(object):
   def foo(self):
     print "B foo"
 
 old_A = A
 A = B
 
 old_A().foo()

(If you think that this is a completely silly and crazy example,
consider [[shimming modules for tests ShimmingModulesForTests]] where
you might need to transparently wrap another module's class.)

If you are an normal innocent Python programmer, this probably looks
like it ought to work; after all, you're using _super()_ exactly as
the instructions tell you to. If you run it, though, you will get an
interesting error:

> _TypeError: super(type, obj): obj must be an instance or subtype of type_

In many languages, the '_super(A, self)_' would have been what I'll call
'early binding'; in the context of _foo()_, the name 'A' would have
been immediately bound to the class itself. Renaming the class later
(if it's even possible) would make no difference to the line, because
the binding had already been established.  Python doesn't work that
way. The binding of 'A' to a class is only looked up as _foo()_'s code
is executing, and by that time 'A' points to the wrong thing; it points
to the completely unrelated class _B_, and so the call is actually doing
'_super(B, self)_' (hence the error message). You can see this directly
by using the [[dis module http://docs.python.org/library/dis.html]] to
inspect the bytecode for _foo_; it contains a ((LOAD_GLOBAL)) to look up
the value of A, instead of any direct reference to the class.

In fact Python *can't* work that way. Because of [[how class definition
works ClassesAndTypes]] combined with [[how functions are defined
FunctionDefinitionOrder]], the name _A_ does not exist when the (method)
function _foo()_ is being defined and its code is being compiled, so
even if Python wanted to do early binding there's nothing to bind
to. This late binding is the only choice Python has.

This has an unfortunate consequence; it makes using _super()_ one of the
few places in Python 2 where you absolutely have to know what your class
is called (well, have some name for it), where by 'your class' I mean
the class that the code is in (as opposed to the class of _self_, which
is easy to determine). Of course, normally this is not an issue.

(_super()_ needs to know this because it has to find where you are in
[[the method resolution order MethodResolutionOrder]], which requires
knowing what class the code is in.)

PS: this issue with _super()_ is fixed in Python 3 through methods
beyond the scope of this entry ([[see here
http://stackoverflow.com/questions/4885168/how-to-make-super-work-by-manually-filling-the-class-cell]]
if you really want to see the sausage being made).