[Python-ideas] SyntaxWarning for for/while/else without break or return?

geremy condra debatem1 at gmail.com
Sun Oct 11 06:58:18 CEST 2009

On Sun, Oct 11, 2009 at 12:09 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> Nick Coghlan wrote:
>> Steven D'Aprano wrote:
>>>> The point of a warning is very much that the code works and is legal,
>>>>  but *in most case* is not what people would want.
>>> Can you give any examples in the Python standard library where code
>>> raises a warning on such a basis?
>>> I would be shocked if you can give any examples.
>> See my other post - there are currently 3 in the 2.x branch. Two of them
>> are pure style warnings strongly encouraging people to put their global
>> statements at the beginning of the function,
> If it is perfectly legal to put global statements anywhere in the function,
> and there is no intention to tighten the rule to disallow that (which would
> be ok with me), then I am against the warning. It suggests that one has done
> something wrong, when one has not.
> A global statement as module level has no effect, even though some newbies
> think it does (else why would they write it when they do?). Perhaps we
> should add a warning for *that*, especially given that it is more likely to
> indicate a real error of thinking rather and simply making the 'wrong'
> stylistic choice.
>> In this thread, the proposal is that we encourage people to only use the
>> else clause on loops containing at least one break statement.
> Whereas I want to be able to use while/else and for/else in didactic code
> without having to warn people against a spurious warning.

Nobody is holding a gun to your head. Use it if you must- but
when a construct is obviously confusing the heck out of people
who are demonstrably good programmers, it's time to think
seriously about warning people who are using it in ways
that *do not make good sense*. All kinds of decisions in
python have been made explicitly to discourage buggy, hard to
read code, and the discussion here, complete with numerous
mistakes and misunderstandings, constitutes abject proof that
for-else is both of those things and hard to write correctly to
boot. If we can't make it less dangerous, the least we can
do is make it more obvious when you're screwing it up.

Geremy Condra

More information about the Python-ideas mailing list