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.
TL;DR: if you want a general looping construct that works no matter the container type, you need an iterator protocol that types can opt into. This is a standard technique adopted by most programming languages that are not explicitly low-level, and has existed for the past 60[1] years. The OP (re)discovered it and thought it was worth blogging about.
Well, it is kind of interesting to see how the very basic programming building block (iteration) gets generalized without incurring syntactic costs. Whether it's worth a place on the HN front page is debatable, though.
[1] Too lazy to track the actual first implementation, but I'd be astonished if the concept wasn't well-known by the 70's.
'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.
AI slop. Flagged.
> 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.