I fundamentally disagree with 1, unless there is a performance benefit or some other benefit not covered by your simplistic example.
For a non-python coder or inexperienced python coder, your initial example is much more readable. It is obvious what is happening.
Someone unfamiliar with enumerate needs to learn what it does, what the parameter order is and then apply that understanding to the code below, with the first this is not required.
Additionally, the enumerate is potentially subject to errors as operator precedence is critical to its operation.
For 2, I have a passionate hatred of nested for or if operations, there are occasions where they are necessary, but these are generally quite rare.
As you mention, they affect code readability, but they also affect maintainability of the code, when the addition or change of functionality can become difficult.
A lot of people use them too frequently on the premise of code compaction, but this is just a cover for poor design, where better abstraction would be more beneficial.
Thanks for the extensive feedback!
Agree with 2, a lot of people use them too frequently and we should be careful here.
I also agree that range(len()) is fine and might be better suited for a beginner. I would never teach a beginner this method the first time I'm showing the for-loop. But as I said in the beginning, I wanted to show how the code can be more elegant and Pythonic. I'm not sure if better readability always has to mean that the code should be suited for a complete beginner. And the enumerate function shouldn't be too hard to understand once someone learned about it.
I also prefer enumerate anytime. range(len()) seems to defeat the motto of “simple over complex”. enumerate seems quite descriptive to me (non-English speaker) and otherwise once explained falls flat. If you are concern about variable unpacking...it makes sense to iterate over an index if you come from C, but python “for-each” approach seems to me more readable. IMHO ❤️
First, please read python.org/dev/peps/pep-0279/. Python design is (or at least it was at the time enumerate was introduced) itself a well-designed community-driven peer-reviewed process. Somebody thought about all your objections and addressed them in a way that was deemed satisfactory by BDFL. Also see nedbatchelder.com/text/iter.html. There is more to loops than C-style "compare, add, dereference, increment" low-level twiddling.
Second, your other objections are just FUD. Parameter order? There is only one parameter. Yes, there is an optional one, but the usual convention (not only in Python) is that the optional parameter always follows the mandatory one. [It's incredibly ironic that the builtin you defend as completely obvious, range, is one of very rare exceptions to that rule.] And what does operator precedence do there? There are no operators at all in the usual use of enumerate.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I fundamentally disagree with 1, unless there is a performance benefit or some other benefit not covered by your simplistic example.
For a non-python coder or inexperienced python coder, your initial example is much more readable. It is obvious what is happening.
Someone unfamiliar with enumerate needs to learn what it does, what the parameter order is and then apply that understanding to the code below, with the first this is not required.
Additionally, the enumerate is potentially subject to errors as operator precedence is critical to its operation.
For 2, I have a passionate hatred of nested for or if operations, there are occasions where they are necessary, but these are generally quite rare.
As you mention, they affect code readability, but they also affect maintainability of the code, when the addition or change of functionality can become difficult.
A lot of people use them too frequently on the premise of code compaction, but this is just a cover for poor design, where better abstraction would be more beneficial.
Thanks for the extensive feedback!
Agree with 2, a lot of people use them too frequently and we should be careful here.
I also agree that range(len()) is fine and might be better suited for a beginner. I would never teach a beginner this method the first time I'm showing the for-loop. But as I said in the beginning, I wanted to show how the code can be more elegant and Pythonic. I'm not sure if better readability always has to mean that the code should be suited for a complete beginner. And the enumerate function shouldn't be too hard to understand once someone learned about it.
I disagree that it is more elegant, my personal opinion is good code can be read by a non coder, at least from an overview perspective.
With the other solution they would struggle as it requires inside knowledge, whereas range and len are much more obvious.
I also prefer
enumerateanytime.range(len())seems to defeat the motto of “simple over complex”.enumerateseems quite descriptive to me (non-English speaker) and otherwise once explained falls flat. If you are concern about variable unpacking...it makes sense to iterate over an index if you come from C, but python “for-each” approach seems to me more readable. IMHO ❤️First, please read python.org/dev/peps/pep-0279/. Python design is (or at least it was at the time enumerate was introduced) itself a well-designed community-driven peer-reviewed process. Somebody thought about all your objections and addressed them in a way that was deemed satisfactory by BDFL. Also see nedbatchelder.com/text/iter.html. There is more to loops than C-style "compare, add, dereference, increment" low-level twiddling.
Second, your other objections are just FUD. Parameter order? There is only one parameter. Yes, there is an optional one, but the usual convention (not only in Python) is that the optional parameter always follows the mandatory one. [It's incredibly ironic that the builtin you defend as completely obvious, range, is one of very rare exceptions to that rule.] And what does operator precedence do there? There are no operators at all in the usual use of enumerate.