Vladimir Matveev <desco...@gmail.com> added the comment:
>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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue43563> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
