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 50.7ms across 5,215 title embeddings via pgvector HNSW
- Quadrupling code performance with a "useless" if birdculture · 107 pts · July 13, 2026 · 39% similar
- Show HN: XY – A Fast, composable, GPU-accelerated interactive plotting library apetuskey · 120 pts · July 28, 2026 · 39% similar
- Show HN: Weedout – Safari extension that hides YouTube AI-labeled videos masteranza · 95 pts · September 01, 2026 · 36% similar
- Good Tools Are Invisible theanonymousone · 392 pts · July 10, 2026 · 36% similar
- Recursion is lying to you theanonymousone · 29 pts · July 28, 2026 · 35% 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.