Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Erik <python@lucidity.plus.com>
Newsgroups: comp.lang.python
Subject: Re: for / while else doesn't make sense
Date: Sat, 21 May 2016 08:20:02 +0100
Lines: 30
Message-ID: <mailman.72.1463815207.27390.python-list@python.org>
References: <CAHJ7fxhOeKFbu3=Jso=wgpBnH9Opr_J_6SHLDO+KtAqVFeGHnA@mail.gmail.com> <mailman.36.1463676220.27390.python-list@python.org> <573dfc0f$0$1586$c3e8da3$5496439d@news.astraweb.com> <slrnnjrvmb.krr.jon+usenet@wintry.unequivocal.co.uk> <573e54f7$0$1615$c3e8da3$5496439d@news.astraweb.com> <57400C22.7050706@lucidity.plus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.uni-berlin.de 4imdZfZdkhrsqK7fKGpwNQUJQWdNdkCZRUq6s3/7G6Vg==
Return-Path: <python@lucidity.plus.com>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
X-Spam-Status: OK 0.004
X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'else:': 0.03; 'model,': 0.05; 'clause': 0.07; '__future__': 0.09; 'subject:while': 0.09; 'syntax': 0.13; '"break"': 0.16; '"for"': 0.16; 'bug,': 0.16; 'complains': 0.16; 'from:addr:python': 0.16; 'hint': 0.16; 'received:io': 0.16; 'received:psf.io': 0.16; 'sources.': 0.16; 'subject:make': 0.16; 'to:addr:pearwood.info': 0.16; "to:name:steven d'aprano": 0.16; 'wrote:': 0.16; 'say,': 0.18; 'runs': 0.18; 'to:2**1': 0.21; 'pass': 0.22; 'code.': 0.23; 'import': 0.24; 'header:In-Reply-To:1': 0.24; 'testing': 0.25; 'header:User-Agent:1': 0.26; "doesn't": 0.26; 'error': 0.27; 'switch': 0.27; 'behaviour': 0.29; 'command-line': 0.29; '(including': 0.30; 'code': 0.30; 'certainly': 0.30; "d'aprano": 0.33; 'instances': 0.33; 'steven': 0.33; 'similar': 0.33; 'add': 0.34; 'could': 0.35; 'done': 0.35; 'but': 0.36; 'should': 0.36; 'there': 0.36; 'keyword': 0.36; 'to:addr:python-list': 0.36; 'subject:: ': 0.37; 'turn': 0.37; 'experience,': 0.38; 'wrong': 0.38; 'mean': 0.38; 'why': 0.39; 'test': 0.39; "didn't": 0.39; 'received:192': 0.39; 'to:addr:python.org': 0.40; 'some': 0.40; 'your': 0.60; 'default': 0.61; 'back': 0.62; 'charset:windows-1252': 0.62; 'subject: / ': 0.63; 'fundamental': 0.66; 'construct': 0.84; 'longest': 0.84; 'subject:else': 0.84; 'subject:sense': 0.84
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.1 cv=COHXJkfD c=1 sm=1 tr=0 a=2lUcMO59U90xkKzxSzK6mw==:117 a=2lUcMO59U90xkKzxSzK6mw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=-LWeCblWLKB-WP568vYA:9 a=pILNOxqGKmIA:10
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
In-Reply-To: <573e54f7$0$1615$c3e8da3$5496439d@news.astraweb.com>
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe: <https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-list/>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
X-Mailman-Original-Message-ID: <57400C22.7050706@lucidity.plus.com>
X-Mailman-Original-References: <CAHJ7fxhOeKFbu3=Jso=wgpBnH9Opr_J_6SHLDO+KtAqVFeGHnA@mail.gmail.com> <mailman.36.1463676220.27390.python-list@python.org> <573dfc0f$0$1586$c3e8da3$5496439d@news.astraweb.com> <slrnnjrvmb.krr.jon+usenet@wintry.unequivocal.co.uk> <573e54f7$0$1615$c3e8da3$5496439d@news.astraweb.com>
Xref: csiph.com comp.lang.python:108900

On 20/05/16 01:06, Steven D'Aprano wrote:

> In my experience, some people (including me) misunderstand "for...else" to
> mean that the else block runs if the for block *doesn't*. It took me the
> longest time to understand why this didn't work as I expected:
>
> for x in seq:
>      pass
> else:
>      print("seq is empty")

So why don't we consider if that should be a syntax error - "else" 
clause on "for" loop with no "break" in its body? I know that doesn't 
change your fundamental mental model, but it's a hint that it's wrong :)

As it's backwards-incompatible, it could be introduced using a 
__future__ import (a precedent is 'generators' and the "yield" keyword 
back in the day) which those who would like the new check could add to 
the top of their sources.

But also, as you say, any instances of that construct in the wild is 
almost certainly a bug, so it would be good to be able to test code 
using a command-line or similar switch to turn on the behaviour by 
default for testing existing bodies of code.

I notice that pylint complains about this (as a warning). Is there any 
reason why this should _not_ just be considered an error and be done 
with it?

E.