What Python's for x in y Loop Actually Hides from You
What `for x in y` hides from you – From Scratch Code
Building my Python interpreter in Rust, Memphis, revealed that the familiar for x in y loop isn't just iterating over a list. Instead, it strictly follows a protocol by calling iter() and next() until StopIteration is raised. This simple mechanism explains why Python handles lists, strings, ranges, and generators so uniformly, turning a magical syntax into a clear, predictable interaction between the loop and any iterable object.
for x in y does not mean loop over y. It means ask y how to be iterated.
- tantalor
> Compared to i++ from C/C++ or forEach from JavaScript, Python's version just works.
Comparing to forEach in JS is incorrect because forEach is an method of Array.
You should compare it to `for...of` in JS. Both operate on iterators.
Article is missing an important distinction between iterators and other "array like" types (including strings):
Iterators don't have to stop, e.g., they can take from a generator that never ceases.
Both Python and JS are happy to loop forever if the iterator never stops.
- anthonj
I don't really get the point of the article. Even if I knew little about python, would be it surpsing that a language with no real basic types is probably abstracting a lot?
Even a simple i=0, i=i+1 is "hiding" a lot in python then.
- WhyNotHugo
'for' loops in Rust do the same: they create an iterator and then iterate over that.
You can write the exact same loop with `let mut iter = v.iter(); while Some(x) = iter.next()`.
'for' loops in Rust are purely syntax sugar, and I somewhat wish they didn't exist. They provide you two ways of doing the same thing, but one of them hides the details from you. Having 'for' as a keyword is nice for folks coming from other languages, but then it hides the possibility of other interesting usages, like cloning an iterator inside a loop.