Python 3.x's Super Magic: Unraveling the Mysteries

Python 3.x introduced a surprising twist in its super() method, allowing calls without arguments. This seemingly innocuous change carries significant consequences and inherent magic under the hood.

Uncovering the Magic

To maintain the DRY principle, the new super() behavior bypasses explicit class naming. It has a special class cell that retrieves the original class object, avoiding the pitfalls of rebinding that plagued the previous super approach.

Consequences of the Magic

Unfortunately, this magic comes with a drawback. Rebinding the super() name to a different variable, such as super_, can disrupt its functionality. This occurs because the cell is only created when super or class is referenced within a method.

Practical Pitfalls

This behavior can pose risks to unsuspecting programmers:

• Rebinding super() could lead to unexpected exceptions.
• Relying on super(type(self), self) or super(self.__class__, self) can result in infinite recursion when invoked from a derived class.
• Class decorators that return new class objects can invalidate the class name binding to super().

Beyond Super()

Intriguingly, super() is not the only Pythonic entity affected by rebinding issues. Other examples include:

• this in PyPy's RPython (similar to super()'s __class__)
• Instance methods accessed via unbound method objects (potentially breaking @property and @classmethod)
• Built-ins like print, object, and list when called without a dot notation

Implications for Developers

While super()'s magic can be useful, it warrants caution. Understanding its intricacies helps prevent runtime errors. When using rebindings, programmers should consider referencing class explicitly or utilizing alternative super() invocation methods.