This continued trend of saying that easily-understandable language features that, even when unfamiliar, are a simple Google away should be avoided just in case someone hasn’t seen them before needs to end. We put features in the languages to be used, maybe not used every time the opportunity comes up, or in “overly clever” ways, but avoiding them in clear cases to avoid anyone else needed to learn anything just reduces the level of learning industry-wide.
I think there are language features out there that are so esoteric they should be avoided – Ruby’s flip-flop operator comes to mind. This doesn’t seem to be in the same category; I was able to grok the idea after a 30-second explanation.
For-else is esoteric as well. It’s mentioned once in the Python documentation, and no example is given. Same with try-else. Guido himself said he wouldn’t have put the functionality in there if he’d had a time machine https://mail.python.org/pipermail/python-ideas/2009-October/006157.html
The filter-based example uses some other Python features that might not be familiar to a beginner, but I think that the broader point still stands with something like this.
next_song = None
for song in songs:
if song.name == next_song_name:
next_song = song
break
if next_song is None:
next_song = download_song(next_song_name)
It’s not as concise, but the logic is definitely more explicit and would be easily understood by any Python programmer.
Ultimately, I think that there is some subjectiveness in what one considers readable. Python gives you a lot of leeway in terms of coding style, and different programmers will have different preferences and levels of familiarity with different features of the language. I know that there’s the whole “there should be one–and preferably only one–obvious way to do it” thing, but that’s often not true in practice.
At least for me, calling it with filter may help understand faster the purpose of the code. But yeah, I’m not sure if I would call it “more readable” either.
There’s something about break statements I’ve never liked, for some reason they always seem wrong. Not that there’s anything programmatically incorrect about using them.
I personally use next() instead whenever feasible, and like that python gives you a concise alternative.
I have felt the same way for many years about break, but I can’t put my finger on it. Often it’s possible to factor the loop into a separate function and use return in place of break; for some reason this feels less dirty.
The article is flawed because the focus on eliminating loop-else needed an example that maintained the loop but didn’t have the loop-else. So it appears spurious.
By resorting to the filter example, it effectively removed the loop thus no need for the loop-else.
And yes loop-else is under justified and might not really “belong”. Just needs to be argued against better.
BTW, it’s not a bad idea to remove spurious loops as well, as that can allow significant improvement in cases where, for example, the filter case allows for a more efficient/compact implementation (or parallelism).
This continued trend of saying that easily-understandable language features that, even when unfamiliar, are a simple Google away should be avoided just in case someone hasn’t seen them before needs to end. We put features in the languages to be used, maybe not used every time the opportunity comes up, or in “overly clever” ways, but avoiding them in clear cases to avoid anyone else needed to learn anything just reduces the level of learning industry-wide.
I think there are language features out there that are so esoteric they should be avoided – Ruby’s flip-flop operator comes to mind. This doesn’t seem to be in the same category; I was able to grok the idea after a 30-second explanation.
With flip-flop, the case is a little different though: Matz himself has said so, even very long ago.
(See the relevant chapter in Matsumoto/Flanegan: The Ruby Programming Language)
For-else is esoteric as well. It’s mentioned once in the Python documentation, and no example is given. Same with try-else. Guido himself said he wouldn’t have put the functionality in there if he’d had a time machine https://mail.python.org/pipermail/python-ideas/2009-October/006157.html
It’s not often this construct is required, but I’d hardly call the filter-based example more readable either.
The filter-based example uses some other Python features that might not be familiar to a beginner, but I think that the broader point still stands with something like this.
It’s not as concise, but the logic is definitely more explicit and would be easily understood by any Python programmer.
Ultimately, I think that there is some subjectiveness in what one considers readable. Python gives you a lot of leeway in terms of coding style, and different programmers will have different preferences and levels of familiarity with different features of the language. I know that there’s the whole “there should be one–and preferably only one–obvious way to do it” thing, but that’s often not true in practice.
At least for me, calling it with filter may help understand faster the purpose of the code. But yeah, I’m not sure if I would call it “more readable” either.
There’s something about break statements I’ve never liked, for some reason they always seem wrong. Not that there’s anything programmatically incorrect about using them.
I personally use
next()instead whenever feasible, and like that python gives you a concise alternative.I have felt the same way for many years about break, but I can’t put my finger on it. Often it’s possible to factor the loop into a separate function and use return in place of break; for some reason this feels less dirty.
The article is flawed because the focus on eliminating loop-else needed an example that maintained the loop but didn’t have the loop-else. So it appears spurious.
By resorting to the filter example, it effectively removed the loop thus no need for the loop-else.
And yes loop-else is under justified and might not really “belong”. Just needs to be argued against better.
BTW, it’s not a bad idea to remove spurious loops as well, as that can allow significant improvement in cases where, for example, the filter case allows for a more efficient/compact implementation (or parallelism).
But then it’s not getting rid of the loop-else.