Simple if-else question

[Iain King]

On Sep 30, 7:12 am, Steven D'Aprano
<ste... at REMOVE.THIS.cybersource.com.au> wrote:
> On Tue, 29 Sep 2009 22:29:10 -0700, John Yeung wrote:
> > On Sep 29, 1:15 pm, Carl Banks <pavlovevide... at gmail.com> wrote:
> >> Hmm, I wonder if Python should emit a warning if an else is used on a
> >> for block with no break inside.  I don't think the else can be invoked
> >> in any other way.  As a bonus it could catch some cases where people
> >> mistakenly use it thinking it will execute [only] when there are no
> >> iterations.
>
> > [Edit from Duncan Booth]
>
> > I would definitely be in favor of a warning.  Yes, people should read
> > the docs more carefully, and yes, it would cost a certain amount of
> > annoyance to implement this.  But I don't think it would get in people's
> > way if they do know how to use else,
>
> Of course it would. It would mean that everybody who knows how to use
> for...else correctly would have to deal with a totally useless warning.
>
> > and I think it would cut down on
> > the number of questions from mystified beginners, some of whom are much
> > more aggressive than this particular OP about claiming that Python is
> > broken (when it's actually behaving as designed).
>
> By raising a warning, you are implying that the behaviour is broken, or
> at least suspicious. Warnings mean something needs to be warned against
> -- "don't do this". Warnings shouldn't be perfectly legitimate behaviours
> on the off-chance that the user is confused. "Warning, are you sure you
> want to put the car into reverse? Perhaps you meant neutral?"
>
> What would the warning say?
>
> "Warning, you have used a legitimate Python control structure but you
> might be confused by it."
>
> "Warning, did you mean if...else instead of for...else?"
>
> Then we can add a whole lot of extra warnings to protect newbies who
> don't read docs (and probably won't read the warnings either) from
> themselves:
>
> "Warning, did you mean obj(1) instead of obj[1]?"
>
> "Warning, did you mean def f(object) instead of class f(object)?"
>
> "Warning, did you mean class f(object) instead of def f(object)?"
>
> "Warning, did you mean 2*3 instead of 2**3?"
>
> "Warning, did you mean %s instead of %x?"
>
> "Warning, we think you're helpless and don't know what you want, perhaps
> you should be programming in PHP?"
>
> I'm sympathetic to the desire to educate the n00bs, and in fact I've even
> suggested similar warnings myself. But I've been convinced that this is
> the wrong approach. Certainly the language shouldn't assume the
> programmer is confused. If this sort of warning belongs anywhere (and
> that's a big if), it belongs in an IDE.
>
> --
> Steven

Read the suggestion again - it's not a warning on the for-else
structure, it's a warning when the for-else doesn't contain a break;
he's theorising that a for-else without a break will always trigger
the else, in which case it's almost certainly an error, and having the
warning is not a bad idea.
However, I assume you can get past the else by raising an exception,
so the idea becomes a little muddled - do you warn when there is no
break and no explicit raise caught outside the loop?  What about an
implicit exception?  I would guess that code intentionally using an
implicit exception to break out of a for loop is in need of a warning
(and the author in need of the application of a lart), but I'm sure
you could construct a plausible situation where it wouldn't be that
bad...

Anyway, I'm ambivalently on the fence.

Iain