See question on bpo -- why is this important? Do you have performance data to back up that this is an important optimization?

This PR is stale because it has been open for 30 days with no activity.

Unless you come up with some benchmark numbers, unfortunately we will have to close this PR. I'll give you a week to let us know what you'd like to do. If you need more time to benchmark, just let us know -- but if we don't hear from you after a week we'll close it. If you change your mind later or you're on vacation or something like that, I will still be notified of comments added to the issue after it's closed, so don't hesitate to say something!

I'm interested to see how this compares with adaptive specialization of PEP 659.

The expressionsuper().attr compiles with this PR as:

          LOAD_DEREF               0 (__class__)          LOAD_FAST                  0 (self)          LOAD_ATTR_SUPER   1 ((1, True))

on main this compiles as:

         CALL_FUNCTION            0         LOAD_ATTR                1 (attr)

So main has a (small) advantage in dispatching.
The question is, can a specialized form ofCALL_FUNCTION 0; LOAD_ATTR match the custom opcodes.

Assuming we specialize bothCALL_FUNCTION andLOAD_ATTR I think it can.
There will be the overhead of creating thesuper() object, but the specializer has more context than the static compiler and should be able to do a much better job on the attribute lookup.

This is superseded by#103497.