On Sep 30, 7:12 am, Steven D'Aprano <ste...@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...@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 -- http://mail.python.org/mailman/listinfo/python-list
