What `for x in y` hides from you – From Scratch Code
rbanffy
16 points
25 comments
July 15, 2026
Related Discussions
Found 5 related stories in 687.5ms across 14,015 title embeddings via pgvector HNSW
- It's Not Just X. It's Y mooreds · 146 pts · May 31, 2026 · 44% similar
- In defense of YAML icarusz · 13 pts · May 26, 2026 · 39% similar
- Quadrupling code performance with a "useless" if birdculture · 107 pts · July 13, 2026 · 39% similar
- Show HN: Yt-x v0.8.0 – Browse, play, and download YouTube from the terminal Benex254 · 18 pts · May 19, 2026 · 38% similar
- --dangerously-skip-reading-code fagnerbrack · 133 pts · May 23, 2026 · 38% similar
Discussion Highlights (5 comments)
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.
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.
mdemare
AI slop. Flagged.
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.
klibertp
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.