So if I'm understanding this correctly, for each class only 16 methods/attributes can be specialised, with everything after just failing? If so 16 seems fairly small, especially for larger libraries/applications. Something likendarray orflask.Flask for instance has 50+ methods. I could imagine a larger application using different sets of methods in different areas, filling up the cache. That wouldn't be the sort of thing showing up on benchmarks.

So if I'm understanding this correctly, for each class only 16 methods/attributes can be specialised, with everything after just failing?

Correct (not including instance attributes). I definitely prefer a growable cache to this approach, except that the numbers we have are slower.

I'm also open to using a larger number of entries, like 32 or 64, if others feel similarly.

I'm also not sure if this causes problems for interpreter isolation. Maybe putting this sort of state on static built-in types is a bad idea, whether it's resizable or not.

CC@ericsnowcurrently

(Docs now passing now#103019 is merged, and updating this withmain. Thanks for flagging!)

From a correctness point of view, adding the cache to static classes should be fine. All the attributes of superclasses of static classes must also be static.
If they aren't that's a bug, and this isn't the place to fix it.
No harm in adding some asserts, though.

However, we would like static classes to beconst so that they can be properly shared, which would mean that the cache would need to be pre-populated with all attributes of the class and all its superclasses.
The caches would be a bit big, but not that bad:len(object.__dict__ | int.__dict__) == 74; much smaller if we exclude special methods.

Closing because of the various issues outlined above.