> python -mtimeit -s "l = list(range(100000))" "l[-1] in l"
1000 loops, best of 3: 1.34 msec per loop
> python -mtimeit -s "l = list(range(100000))" "l[-1] in iter(l)"                                
1000 loops, best of 3: 1.59 msec per loop

The patch adds almost 40 line of the code and increases the performance of not well famous feature at best by 10-20%. Adding an optimization for every new iterator type will add a comparable quantity of the code. I think this is too high cost.

Using a common template implementation for iterators (issue27438) would decrease the relative cost of this feature.

Terry, this proposition doesn't change the behavior. It moves the iterator forward during searching. The only effect is inlining __next__ in a loop and getting rid of the overhead of few indirections and calls.

Sorry, I mistakenly assumed, without carefully checking the C code, that the speedup was from checking the underlying collection, without advancing the iterator.  I presume that " ++it->it_index;" is the statement to the contrary. I should have either asked or found this sooner.  I unlinked the noisy comment.

I don't think I've ever used `in` on an iterator.  I didn't even expect it to work, and would not consider its use a good practice.

I recommend rejecting this proposal