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.
To be fair, when I started learning CS, the `for x in y` syntax was cryptic to me because I was unfamiliar with concepts such as iterators & generators. `for(int i=0; i<len(y); i++)` made way more sense since there is no hidden logic (besides additions as you highlighted in your comment, but which I think is easier to have a grasp of). So I really wish I had read this article when I started my CS journey a couple of years ago.
In the author's mind, it's unexpected/amazing that 'for' can iterate over many types. But it's NOT unexpected/amazing that 'iter' can iterate over many types. I have no idea why.
It's not like 'for' is limited to counting in other languages. The grand-daddy in c does something until some condition is false, and that thing can equally be incrementing/decrementing a number or invoking some function. That's what a loop does in any case, it compiles down to a conditional jump (JNE/JE..)
Maybe his reason for astonishment is obscured by over-use of an LLM to 'enhance' the text.
> It's not like 'for' is limited to counting in other languages. The grand-daddy in c does something until some condition is false
C 'for' is a while loop. It's strictly syntactic sugar for an already existing feature. And it's really, really transparent. `for(A; B; C) { do_stuff(); }` isn't just a while loop, it's this while loop:
A;
while(B) {
do_stuff();
C;
}
Other languages have treated for as a separate concept from while. C isn't really informative in that case.
But it's not a Python thing. Rust is noted below, and there's also C++.
std::container<T> container;
for (std::container<T>::iterator i = container.begin(); i != container.end(); ++i) { ...}
auto iter = container.begin(); while (iter != container.end()) { ...; ++iter; }
for (auto const & t : container) { ... }
Very few people who use Python realize the loop is not just looking into the values but asking the values to produce an iterator. It's only when they outgrow this early stage that they are ready to understand how to make a finite iterator themselves.
'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.
It's true that they're just sugar but Rust does explain how the for-in loop de-sugars and you've over-simplified considerably. Your syntax also doesn't quite work.
The value is in idiom, turning everything into loop expressions (The "while" keyword is also just sugar, Rust's only fundamental loop is named loop) makes it harder to discern what's actually going on.
If you want to clone the iterator in some cases rather than consuming it, that should look different so that reviewers will see what you're up to.
In addition to the points that sibling comments have made about how you're not quite right with the exact semantics of for loops (which also take ownership via `into_iter` and therefore are a bit different from `while let`), it's worth pointing out that if you peek a bit further in to MIR, all loops in Rust just desugar into the `loop` keyword with manual breaking, including `while`. It's not really clear to me why for loops in particular bother you.
Is "hiding" in the sense that you just need to have read the docs or know how the language works at a pretty basic level really a problem, or even a negative? I would certainly say that the readability and clarity on the form of loop being used is a bigger win, either way.
It should be `v.into_iter()`, and that distinction matters because of ownership / move semantics.
It just so happens that for most collections, `IntoIter` is also defined for references to them, which typically gives you the same behavior that `.iter()` would give.
... shows that today ranges like 0..5 aren't Copy even if that would be possible, which means if they're consumed they're gone, whereas an array of integers is Copy and so consuming it doesn't mean it's gone, you can just consume it again.
The desire is that Rust 2027 edition will change the nice syntax for ranges to produce new ranges like core::ranges::Range which are Copy if possible and only IntoIterator, the original ranges are never Copy but are Iterator, we now regret this choice.
Which is funny, because whenever I encounter a language for which `for` *doesn't* work this way it feels antiquated. I do however wish another keyword was used in many cases, becuase `for` in C and Go is so much different then `for` in Rust or Python. I think the higher-level case (Rust and Python) should really use a word like `foreach` or maybe something compeletely different like `itr`, although I get that they want to "look" more like C
> 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.
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.
To be fair, when I started learning CS, the `for x in y` syntax was cryptic to me because I was unfamiliar with concepts such as iterators & generators. `for(int i=0; i<len(y); i++)` made way more sense since there is no hidden logic (besides additions as you highlighted in your comment, but which I think is easier to have a grasp of). So I really wish I had read this article when I started my CS journey a couple of years ago.
In the author's mind, it's unexpected/amazing that 'for' can iterate over many types. But it's NOT unexpected/amazing that 'iter' can iterate over many types. I have no idea why.
It's not like 'for' is limited to counting in other languages. The grand-daddy in c does something until some condition is false, and that thing can equally be incrementing/decrementing a number or invoking some function. That's what a loop does in any case, it compiles down to a conditional jump (JNE/JE..)
Maybe his reason for astonishment is obscured by over-use of an LLM to 'enhance' the text.
Why would it ever be surprising that I can y= [x,x,y,y] for x in y; x=y; return y;
and get [y,y,y,y]?
> It's not like 'for' is limited to counting in other languages. The grand-daddy in c does something until some condition is false
C 'for' is a while loop. It's strictly syntactic sugar for an already existing feature. And it's really, really transparent. `for(A; B; C) { do_stuff(); }` isn't just a while loop, it's this while loop:
Other languages have treated for as a separate concept from while. C isn't really informative in that case.But it's not a Python thing. Rust is noted below, and there's also C++.
Very few people who use Python realize the loop is not just looking into the values but asking the values to produce an iterator. It's only when they outgrow this early stage that they are ready to understand how to make a finite iterator themselves.
'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.
It's true that they're just sugar but Rust does explain how the for-in loop de-sugars and you've over-simplified considerably. Your syntax also doesn't quite work.
The value is in idiom, turning everything into loop expressions (The "while" keyword is also just sugar, Rust's only fundamental loop is named loop) makes it harder to discern what's actually going on.
If you want to clone the iterator in some cases rather than consuming it, that should look different so that reviewers will see what you're up to.
In addition to the points that sibling comments have made about how you're not quite right with the exact semantics of for loops (which also take ownership via `into_iter` and therefore are a bit different from `while let`), it's worth pointing out that if you peek a bit further in to MIR, all loops in Rust just desugar into the `loop` keyword with manual breaking, including `while`. It's not really clear to me why for loops in particular bother you.
Is "hiding" in the sense that you just need to have read the docs or know how the language works at a pretty basic level really a problem, or even a negative? I would certainly say that the readability and clarity on the form of loop being used is a bigger win, either way.
It should be `v.into_iter()`, and that distinction matters because of ownership / move semantics.
It just so happens that for most collections, `IntoIter` is also defined for references to them, which typically gives you the same behavior that `.iter()` would give.
More specifically for x in y consumes y in Rust.
https://doc.rust-lang.org/std/keyword.for.html explains how a loop is de-sugared
https://rust.godbolt.org/z/5jzhxYM51
... shows that today ranges like 0..5 aren't Copy even if that would be possible, which means if they're consumed they're gone, whereas an array of integers is Copy and so consuming it doesn't mean it's gone, you can just consume it again.
The desire is that Rust 2027 edition will change the nice syntax for ranges to produce new ranges like core::ranges::Range which are Copy if possible and only IntoIterator, the original ranges are never Copy but are Iterator, we now regret this choice.
Which is funny, because whenever I encounter a language for which `for` *doesn't* work this way it feels antiquated. I do however wish another keyword was used in many cases, becuase `for` in C and Go is so much different then `for` in Rust or Python. I think the higher-level case (Rust and Python) should really use a word like `foreach` or maybe something compeletely different like `itr`, although I get that they want to "look" more like C
I would say Python really wants to look as much not-C as it can. In this case it's not the word "for" but the "for x in" construct.
AI slop. Flagged.