PyTorch Dynamo patches next() to reject non-iterators, matching CPython
A bug let Dynamo's next() silently return values from non-iterators — now fixed with strict checks.
PyTorch's Dynamo compiler, which accelerates PyTorch models by tracing Python code into graphs, had a subtle bug in its iterator handling. When the built-in next() function was called on a non-iterator (e.g., a plain list), Dynamo's BuiltinVariable.call_next skipped CPython's type check and incorrectly returned the first element of the list. This silent deviation from standard Python semantics could lead to hard-to-debug errors in compiled models. The issue was reported as GitHub issue #190584.
The fix (pull request #190624) introduces a call to Dynamo's existing pyiter_check before advancing any iterator. If the object is not an iterator, a TypeError is raised exactly as CPython would. The unsafe fallback for BaseListVariable was removed. Regression tests in test/dynamo/test_iterators.py verify that non-iterators raise TypeError, exhausted iterators raise StopIteration, and default arguments work correctly. The change is backward compatible and has no performance impact, but corrects a semantic mismatch that could affect model correctness.
- Fix addresses issue #190584 where next() on a plain list silently returned the first element instead of raising TypeError.
- Uses Dynamo's existing pyiter_check to enforce CPython iterator validation before advancement.
- Adds 4 regression tests covering non-iterators with/without defaults and exhausted iterators.
Why It Matters
Aligns PyTorch Dynamo's iterator behavior with CPython, preventing silent bugs in optimized model compilation.