Nick Coghlan added the comment:
Right, this isn't actually a bug, it just requires a bit more creativity to
bind and resolve `__class__` correctly when defining the replacement method.
Here's what happens normally with zero-argument super():
>>> class A:
... def f(self):
... print(__class__)
...
>>> A().f()
<class '__main__.A'>
>>> A.f.__closure__
(<cell at 0x7f0ea25f1f48: type object at 0x55ea30974318>,)
>>> inspect.getclosurevars(A.f)
ClosureVars(nonlocals={'__class__': <class '__main__.A'>}, globals={},
builtins={'print': <built-in function print>}, unbound=set())
And here's one way of emulating the __class__ resolution part:
>>> def make_method():
... __class__ = A
... def fn(self):
... print(__class__)
... return fn
...
>>> A.fn = make_method()
>>> A().fn()
<class '__main__.A'>
And applying that to get zero-argument super() working in a substitute method
gives:
>>> class B(A):
... def f(self):
... super().f()
...
>>> B().f() # Normal super()
<class '__main__.A'>
>>> def make_B_method():
... __class__ = B
... def fn(self):
... return super().fn()
... return fn
...
>>> B.fn = make_B_method()
>>> B().fn() # Emulated super()
<class '__main__.A'>
----------
resolution: -> not a bug
stage: -> resolved
status: open -> closed
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29114>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
