This is a fun little optimization. According to some local microbenchmarks (basically entering and exiting context managers a million times), turning thesenext calls intofor loops saves about 25% of the overhead this class introduces (~5% due to__enter__ and ~20% due to__exit__). This is because:

• The wrapped iterator is usually a generator. We specializefor loops for generators, so instead of calling through the C code fornext and re-entering the interpreter, we can "inline" the frame push instead. (This is also more JIT-friendly.)
• We don't care about the actualStopIteration exceptions here, just whether or not they were raised. Raising exceptions is expensive, and the interpreter has an optimization to avoid actually raisingStopIteration in normalfor loops. (This is especially helpful in__exit__, where we advance the generator, expect aStopIteration to be raised, and then just throw it away!)

This change isn't worth it for theasync variant of this function, since neither of the above optimizations apply toasync for loops.