>Currently, super() is decoupled from the core language.  It is just a builtin that provides customized attribute lookup.  This PR makes super() more tightly integrated with the core language, treating it as if it were a keyword and part of the grammar.  Also note, users can currently create their own versions of super(), shadowing the builtin super().

This is true however:
- this patch does not block people from introducing custom version of `super` so this scenario still work. The idea was to streamline the common case
- based on digging into Instagram codebase and its transitive dependencies (which is reasonably large amount of code) all spots where `super()` appear in sources assume `super` to be builtin and for a pretty common use-case its cost is noticeable in profiler.
- zero-argument `super()` still a bit magical since it requires compiler support to create cell for `__class__` and assumes certain shape of the frame object so this patch is a step forward with a better compiler support and removing runtime dependency on the frame

> Do you have any evidence that the overhead of super() is significant in real programs

I do see the non-negligible cost of allocation/initialization of `super` object in IG profiling data.