On 12 January 2014 16:17, Kay Hayen <kay.ha...@gmail.com> wrote: > > Hello, > > thanks for all the replies. > > Of course I am aware that my use of the "else:" is different from the > "break" case > when it comes to "return". For return, the "else:" is not needed, as it > won't continue > the execution. > > > def _areConstants(expressions): >> > for expression in expressions: >> > if not expression.isExpressionConstantRef(): >> > break >> > if expression.isMutable(): >> > break >> > else: >> > return True >> > return False >> >> That's not an improvement but also not the obvious way to rewrite the >> code to suppress the, IMHO legitimate, warning. Instead of introducing >> ``break``\s for an unnecessary ``else`` clause one could also just >> remove that unnecessary ``else``:: >> > > Mind you, I am using the "else:" specifically to express, that I expect > the loop > to return based on one element. I agree with you that the suggested code is > making that hard to discern and that removing the "else" clause is an > option. >
I'm reversing my earlier opinion ... if all the ways of breaking out of the loop are "return", the "else" is not needed and Pylint should point this out. > > The thing is, I developed a style, where a return in the loop always leads > to > a return in a else. It's the pick and choose method. So any time, I make > decisions based on an iterable, I do it like that. > > def _areConstants(expressions): >> for expression in expressions: >> if not expression.isExpressionConstantRef(): >> return False >> if expression.isMutable(): >> return False >> return True >> >> Which improves the situation in a way, because now the fellow Python >> coder doesn't wonder where the ``break`` should be or if the author >> understood the semantics of ``else`` on loop constructs. >> > > That precisely is the question. Is the "else" an emphasis, or is it an > error > indicator. I can assure you that I did it on purpose. But if nobody gets > that, > it kinds of misses the point. > > I take the general feedback to say "yes, using else: without need is a > style > problem". So I will try and give it up. :-) > > >> I would also avoid this question by using `all()` here. :-) >> > > I learned of "any" and "all" relatively late. I agree for booleans it's > the better > choice, but it's another subject. Many times, it's not a boolean return > value. > "Any" and "all" are just special cases of "max" and "min". ;) And there are many other tools for processing lists without for-loops, e.g.: http://docs.python.org/3/library/itertools.html#itertools-recipes - peter > > Yours, > Kay > > > _______________________________________________ > code-quality mailing list > code-quality@python.org > https://mail.python.org/mailman/listinfo/code-quality > >
_______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
