GH-145668: Add FOR_ITER specialization for virtual iterators. Specialize GET_ITER.

[markshannon]

Add FOR_ITER specialization for virtual iterators. Specialize GET_ITER.

• Add FOR_ITER_VIRTUAL to specialize FOR_ITER for virtual iterators
• Add GET_ITER_SELF to specialize GET_ITER for iterators (including generators)
• Add GET_ITER_VIRTUAL to specialize GET_ITER for iterables as virtual iterators
• Add tp_iteritem internal slot to PyTypeObject to support a wider range of classes as virtual iterators.

This PR adds strs as virtual iterators, with the potential to add bytes, bytearray, frozenset, frozendict and others in the future.

• Issue: Extend FOR_ITER specializations to cover other indexable sequences #145668

---

📚 Documentation preview 📚: https://cpython-previews--147967.org.readthedocs.build/

[Fidget-Spinner]

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.

[markshannon]

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.

[Fidget-Spinner]

A few comments

[Fidget-Spinner]

what does trad mean?

[markshannon]

Traditional

[Fidget-Spinner]

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.

[markshannon]

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.

[bedevere-bot]

🤖 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.