Here is very similar version that works (tested on python27)
>>> def stop():

>>> list((i if i<50 else stop()) for i in range(100))
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49]

On Tue, Jan 29, 2013 at 12:59 PM, Shane Green <> wrote:
Unfortunately "else break" also kind of falls flat on its face when you consider it's being used in context of an expression.

Shane Green 
408-692-4666 |

On Jan 29, 2013, at 2:44 AM, Nick Coghlan <> wrote:

On Tue, Jan 29, 2013 at 11:30 AM, Steven D'Aprano <> 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


Nick Coghlan   |   |   Brisbane, Australia
Python-ideas mailing list

Python-ideas mailing list