Hello,thanks for all the replies.Of course I am aware that my use of the "else:" is different from the "break" casewhen it comes to "return". For return, the "else:" is not needed, as it won't continuethe execution.> def _areConstants(expressions):That's not an improvement but also not the obvious way to rewrite the
> for expression in expressions:
> if not expression.isExpressionConstantRef():
> if expression.isMutable():
> return True
> return False
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 loopto return based on one element. I agree with you that the suggested code ismaking 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 toa return in a else. It's the pick and choose method. So any time, I makedecisions based on an iterable, I do it like that.def _areConstants(expressions):return True
for expression in expressions:
if not expression.isExpressionConstantRef():
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 errorindicator. 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 styleproblem". 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 betterchoice, but it's another subject. Many times, it's not a boolean return value.
code-quality mailing list