Virtual iterators

[markshannon]

Much like we have "virtual bound-methods" for calls to methods, we could have "virtual iterators" for iteration over sequences.

The LOAD_METHOD instruction pushes NULL func or func self to the stack, the latter being a representation of the bound-method types.MethodType(func, self).
We could do something similar for GET_ITER.
For non-sequence iterators, like range, generators etc, it would push NULL iter. For sequences, it would push seq 0.
The behavior of FOR_ITER would depend on whether SECOND is NULL.

• NULL: Push next(iter)
• Not NULL: Pop index; push index+1; push seq[index]

If we allow unboxed integers on the stack, then this could be reasonably efficient with specialization.
For this to be useful, we would need have tagged integers on the stack.
I doubt it would be worth implementing tagged ints just for this, but if we had tagged values for another reason, e.g. deferred reference counts, then it could be a worthwhile enhancement.

[gvanrossum]

I suppose this would only be useful if the sequence is a list or tuple? (Or perhaps some other builtin sequence like str.) Not for a user-defined Sequence subclass, we wouldn't be able to prove that __iter__ really does the same thing as __getitem__(i) for i in ...

[markshannon]

Yes, the main benefit would be for builtin sequences.
As listiterator is the most common iterator according to our stats, it might be worth it for lists alone.

[sweeneyde]

How would this work for situations like this?

it = iter(list(range(20)))
next(it)
next(it)

for i in it:
    if i > 5:
        next(it)
    if i > 10:
        break

next(it)
next(it)

[sweeneyde]

I see, it would have to only be for lists given to GET_ITER, not list iterators.

[markshannon]

Now that we support PyStackRef for both defautl and FT build, we can safely use tagged integers on the stack with only a very small modification to the GC to make it aware of them.