[Python-ideas] Is this PEP-able? for X in ListY while conditionZ:

Shane Green shane at umbrellacode.com
Sat Jun 29 14:20:54 CEST 2013


On Jun 29, 2013, at 3:09 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>    data = [x for x in iterable break if x is None]

+1 I like the syntax really like the reasoning and full story.

On Jun 29, 2013, at 3:09 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 28 June 2013 18:20, Wolfgang Maier
> <wolfgang.maier at biologie.uni-freiburg.de> wrote:
>> Let me suggest one more solution although it requires a new keyword:
>> introduce
>> 
>> *breakif* condition
>> 
>> and define its translation as if condition: break .
>> You can now write
>> (x for x in iterable breakif x < 0)
>> and I don't see a way how that could possibly be misread by anyone.
>> Also it would translate unambiguously to the explicit:
>> 
>> for x in iterable:
>>    breakif x<0 # itself translating to if x<0: break
>>    yield x
>> 
>> It would work with genexps, comprehensions and explicit loops alike (with
>> very
>> little benefit for the later, though maybe it increases readability even
>> there
>> by making it clear from the start of the line what the purpose of the
>> condition
>> test is).
> 
> This (or, more accurately, a slight variant that doesn't need a new
> keyword) actually sounds quite attractive to me. My rationale for that
> ties into the just rejected PEP 315, which tried to find an improved
> "loop and a half" syntax for Python, as well as the ongoing confusion
> regarding the meaning of the "else" clause on while and for loops.
> 
> Currently, Python's fully general loop syntax looks like this:
> 
>    while True:
>        # Iteration setup
>        if termination_condition:
>            break
>        # Remained of iteration
> 
> And the recommended idiom for a search loop looks like this:
> 
>    for x in data:
>        if desired_value(x):
>            break
>    else:
>        raise ValueError("Value not found in {:100!r}".format(data))
> 
> Rather than adding a new keyword, we could simply expand the syntax
> for the existing break statement to be this:
> 
>    break [if <EXPR>]
> 
> This would simplify the above two standard idioms to the following:
> 
>    while True:
>        # Iteration setup
>        break if termination_condition
>        # Remainder of iteration
> 
>    for x in data:
>        break if desired_value(x)
>    else:
>        raise ValueError("Value not found in {:100!r}".format(data))
> 
> A "bare" break would then be equivalent to "break if True". The "else"
> clause on the loop could then be *explicitly* documented as associated
> with the "break if <X>" form - the else only executes if the break
> clause is never true. (That also becomes the justification for only
> allowing this for break, and not for continue or return: those have no
> corresponding "else" clause)
> 
> Once the break statement has been redefined this way, it *then*
> becomes reasonable to allow the following in comprehensions:
> 
>    data = [x for x in iterable break if x is None]
> 
> As with other proposals, I would suggest limiting this truncating form
> to disallow combination with the filtering and nested loop forms (at
> least initially). The dual use of "if" would make the filtering
> combination quite hard to read, and the nested loop form would be
> quite ambiguous as to which loop was being broken. If we start with
> the syntax restricted, we can relax those restrictions later if we
> find them too limiting, while if we start off being permissive,
> backwards compatibility would prevent us from adding restrictions
> later.
> 
> I'd be very keen to see this written up as a PEP - it's the first
> proposal that I feel actually *simplifies* the language in any way
> (mostly by doing something about those perplexing-to-many else clauses
> on for and while loops).
> 
> Cheers,
> Nick.
> 
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130629/1ca9cc35/attachment.html>


More information about the Python-ideas mailing list