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. 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. Yours, Kay
_______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
