We can remove the C stack use and general overhead of calling special methods implemented in Python for attribute access and indexing.

Each operation has a special method that implements it. When that special method is implemented in Python, we should avoid the `tp_xxx` slot machinery and use the same mechanism we use for normal calls to Python functions. 

* BINARY_SUBSCR: `__getitem__`
* STORE_SUBSCR: `__setitem__`
* LOAD_ATTR: `__getattribute__` (and maybe `__getattr__`)
* STORE_ATTR: `__setattr__`

It probably isn't worth bothering with the deletion forms.

The getters (`__getitem__` and `__getattribute__`) are relatively simple, as the call returns the result.

The setters are a bit more complicated as the return value needs to be discarded, so an additional frame which discards the result of the call needs to be inserted.

Of these, presumably LOAD_GETATTR is by far the most used, so should we try that first?

I don't think it matter much which we do first.
I happened to do BINARY_SUBSCR first.

That's a good one too, and perhaps simpler.

New changeset 21fa7a3e8f99a1a32467f85c877e40cbdafa9da7 by Mark Shannon in branch 'main':
bpo-45829: Specialize BINARY_SUBSCR for __getitem__ implemented in Python. (GH-29592)
https://github.com/python/cpython/commit/21fa7a3e8f99a1a32467f85c877e40cbdafa9da7

This snippet occurs a couple of times in ceval.c (BINARY_SUBSCR_GETITEM and CALL_FUNCTION_PY_SIMPLE):

            new_frame->previous = frame;
            frame = cframe.current_frame = new_frame;
            new_frame->depth = frame->depth + 1;

Maybe I'm reading it wrong, but I think the last line is just setting new_frame->depth++, leaving new_frame->depth = 1 instead of frame->previous->depth + 1.

I think the second and third lines should be swapped?

New changeset 62a8a0c5223f750e22ee381d3cfbdb718cf1cc93 by Brandt Bucher in branch 'main':
bpo-45829: Check `__getitem__`'s version for overflow before specializing (GH-30129)
https://github.com/python/cpython/commit/62a8a0c5223f750e22ee381d3cfbdb718cf1cc93