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

[Wolfgang Maier]

On Jun 27, 2013, at 5:19, Nick Coghlan <ncoghlan at gmail.com> wrote:

>> If you're willing, I'm actually thinking this may be one of those
>> discussions that's worth summarising in a PEP, even if it's just to
>> immediately mark it Rejected. Similar to PEP 315 and a few other PEPs,
>> it can help to have a document that clearly spells out the objective
>> (which I think you summarised nicely as "trying to find a syntactic
>> replacement for itertools.takewhile, just as comprehensions replaced
>> many uses of map and filter"), even if no acceptable solution has been
>> found.
>
>The ideas are pretty broad-ranging. In particular, #1 got two somewhat 
>supportive responses that had nothing to do with the comprehension
termination 
>idea. Do side issues like that need to be discussed first/separately before

>referencing them in a while clause PEP?
>
>Also, we seem pretty far from a consensus on what the actual tradeoffs are
for 
>most of the options. For example, is the definition of comps in terms of
loops 
>the core idea behind the abstraction, or a minor triviality that's only
useful 
>in understanding bad code? Are the differences between comps and genexps a
bug 
>or a feature?
>
>Finally, how does this connect up to the original idea of this thread,
which was 
>to draft a PEP for while clauses in loop statements rather than in 
>comprehensions? Obviously if that existed, it would change the options for
comp 
>syntax. Do we need to include that idea in the discussion? (I completely
forgot 
>about it while digging up all of the ideas that spun off from it...)

I don't think while clauses in loop statements are a big gain for the
language.
There's break and despite all the programming-style discussions going on in
this
part of the thread, it has been working well for many years and most people
find
it intuitive to use.

>> That phrasing of the objective also highlights a counter argument I
>> hadn't considered before: if we don't consider takewhile a common
>> enough use case to make it a builtin, why on *earth* are we even
>> discussing the possibility of giving it dedicated syntax?
>
>Besides early termination for comps, the only good use case I know of is in
code 
>that already makes heavy use of itertools, and making one of the functions
a 
>builtin wouldn't change anything.
>
>And if early termination for comps is a special case, it doesn't seem too 
>unreasonable to consider other ways to handle it.
>
>But you're right that "make takewhile a builtin" should probably be
considered 
>among the alternatives.

But a builtin takewhile would still not come with nicer and easier to read
syntax!
I guess the use cases are not that rare, it's just that right now people
switch
to explicit loops when they need early termination because it keeps things
readable.
I'm encountering this situation quite regularly (reading a small header from
large
files is the most common example, but there are others).

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).

Best,
Wolfgang