[Python-ideas] while conditional in list comprehension ??

Tue Jan 29 13:03:49 CET 2013

> Nick Coghlan <ncoghlan at ...> writes:
>>> On Tue, Jan 29, 2013 at 11:30 AM, Steven D'Aprano <steve at ...> wrote:
> > Why would it translate that way? That would be a silly decision to make.
> > Python can decide on the semantics of a while clause in a comprehension in
> > whatever way makes the most sense, not necessarily according to some
> > mechanical, nonsensical translation.
>> Terry is correct: comprehensions are deliberately designed to have the
> exact same looping semantics as the equivalent statements flattened
> out into a single line, with the innermost expression lifted out of
> the loop body and placed in front. This then works to arbitrarily deep
> nesting levels. The surrounding syntax (parentheses, brackets, braces,
> and whether or not there is a colon present in the main expression)
> then governs what kind of result you get (generator-iterator, list,
> set, dict).
>> For example in:
>> (x, y, z for x in a if x for y in b if y for z in c if z)
> [x, y, z for x in a if x for y in b if y for z in c if z]
> {x, y, z for x in a if x for y in b if y for z in c if z}
> {x: y, z for x in a if x for y in b if y for z in c if z}
>> The looping semantics of these expressions are all completely defined
> by the equivalent statements:
>> for x in a:
> if x:
> for y in b:
> if y:
> for z in c:
> if z:
>> (modulo a few name lookup quirks if you're playing with class scopes)
>> Any attempt to change that fundamental equivalence between
> comprehensions and the corresponding statements has basically zero
> chance of getting accepted through the PEP process.
>> The only remotely plausible proposal I've seen in this thread is the
> "else break" on the filter conditions, because that *can* be mapped
> directly to the statement form in order to accurately describe the
> intended semantics. However, it would fail the "just use
> itertools.takewhile or a custom iterator, that use case isn't common
> enough to justify dedicated syntax". The conceptual basis of Python's
> comprehensions in mathematical set notation would likely also play a
> part in rejecting an addition that requires an inherently procedural
> interpretation.
>> Cheers,
> Nick.
>
Thanks Nick, that is really helpful, as I can now see where the problem really
lies for the developer team.
I agree that under these circumstances my suggestion is inacceptable. You know,
I am just a python user, and I don't know about your development paradigms.
Knowing about them, let me make a wild suggestion (and I am sure it has no
chance of getting accepted either, it's more of a test to see if I understood
the problem):
You could introduce a new 'breakif <condition>' statement, which would be
equivalent to 'if <condition>: break'.
Its use as a standalone statement could be allowed (but since its equivalent is
already very simple it would be a very minor change). In addition, however the
'breakif' could be integrated into comprehensions just like 'if', and could be
translated directly into loops of any nesting level without ambiguities.
another note: in light of your explanation, it looks like the earlier suggestion
of 'else break' would also work without ambiguities since with the rigid logic
applied, there would be no doubt which of several 'for' loops gets broken by the
'break'.
Thanks for any comments on this (and please :), don't yell at me for asking for
a new keyword to achieve something minor, I already understood that part).
Best,
Wolfgang