For loop comprehensions

[Ian Kelly]

On Fri, Feb 11, 2011 at 7:34 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Fri, 11 Feb 2011 16:59:52 -0700, Ian Kelly wrote:
>
>> Why not allow the same thing in for-loop conditions?
>
> Because new syntax and new language features means more work. Somebody
> has to write the code, make sure that it doesn't break existing Python
> code, test it for bugs, change the documentation, write regression tests
> for it... And then, having done it for CPython, somebody else has to do
> the same for IronPython, Jython, PyPy, CLPython, Stackless ... And all
> that code has to be maintained.
>
> Because new syntax and features increases the size and complexity of the
> Python code base, which means more bugs and more tests needed.
>
> Because new syntax and features increases the size and complexity of the
> documentation needed, and hence increases the amount of things that need
> to be learned.
>
> Because the guiding philosophy of Python is "there should be one, and
> preferably only one, obvious way to do it". That doesn't mean that
> multiple ways of doing it are forbidden (far from it!) but it does mean
> that Python is conservative about adding multiple ways of spelling the
> same thing.

These things occurred to me, but they don't seem terribly compelling
in this instance.  We're not talking about adding an entirely new
feature.  We're talking about adapting an existing syntax feature to
make it more widely useful.

However, I've come up with what I think is a better reason:

for x in a for y in b if condition(a, b):
    break
else:
    found = False

I can argue about what I think this code should do, but it certainly
would not be clear to somebody unfamiliar with the syntax.  Does the
'break' break out of the entire loop or just the inner part?  Does the
'else' apply to the loop or to the 'if'?

>> I think that
>> anything that makes the language syntax more consistent is good.
>
> "A foolish consistency is the hobgoblin of little minds."

If you think that quote is applicable here, then you misapprehend it.
It has nothing whatsoever to do with uniformity as a language design
principle.