GeezerVison

Doesn't this change the ABI guarantees of PyTypeObject? Or are there none of those? In any case, feels strange that we are adding a public field that is opaque for our own use.

tp_watchers is already documented as internal.
The header is public, so the fields have to go in a public header even if they aren't to be used.

Do you have benchmark numbers for this?

I'm wondering of 3 extra opcodes is worth it. I think I might have a solution for the opcode problem.

Do you have benchmark numbers for this?

In the noise. But this enables more optimizations, so neutral is good.

I'm wondering of 3 extra opcodes is worth it.

The FOR_ITER_VIRTUAL is worth it, as it allows more common iterables to be treated as virtual iterators.

By themselves, the two new GET_ITER specializations probably wouldn't be.
They're worth it because they complement the FOR_ITER and, very soon, the SEND specializations.
For those specializations to work we need GET_ITER to handle the three distinct cases:

• Already an iterator: do nothing
• An iterable, supporting virtual iteration: push tagged zero
• Other iterables, call __iter__ to get the iterator

So the specializations follow naturally.

I think I might have a solution for the opcode problem.

That's good, but not directly relevant to this PR I think.
We aren't in imminent danger of running out of opcodes, provided we followed a reasonably principled approach to specializations.

🤖 New build scheduled with the buildbot fleet by @Fidget-Spinner for commit a55ac63 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F147967%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.