Proposal: [... for ... while cond(x)]

[Eighty]

I suggest a new extension of the list comprehension syntax:

[x for x in xs while cond(x)]

which would be equivalent to

list(itertools. takewhile(cond, xs))

+ Since Python favors list comprehensions over map, filter, and reduce,
this would be the preferred way to do this
+ "Takewhile operations" occur often, at least for me
+ I don't think it would break any existing syntax

An analogous syntax for dropwhile would be nice, but I can't think of
one.

This is not a PEP because it's a very simple idea and probably not just
anyone (read: me) can write and submit one. If there has been a PEP for
this, I've missed it; if not, it would be nice if someone wrote one.

Discuss.

[Terry Reedy]

"Eighty" <ei*****@gmail. comwrote in message
news:11******** **************@ h48g2000cwc.goo glegroups.com.. .

>
Eighty wrote:

>I suggest a new extension of the list comprehension syntax:

[x for x in xs while cond(x)]

This does not work.

e(x) for x in xs if cond(x)

is an abbreviation of

for x in xs:
if cond(x)
yield e(x)

and similarly with more for and if clauses,
whereas the analogous expansion of your proposal

for x in xs:
while cond(x):
yield e(x)

is an infinite loop and not at all what you mean.

>which would be equivalent to

list(itertools .takewhile(cond , xs))

And what would

x for x in xs while cond(x) if blah(x)
x for x in xs if blah(x) while cond(x)
x*y for x in xs while cond(x) for y in ys

mean? The ability to mix and match clauses after the first for clause is
an important part of comprehension syntax.

>+ "Takewhile operations" occur often, at least for me

So keep using the function provided. I am pretty sure takewhile is rare
for most other people.

So does no one have a comment on this?

Ain't gonna happen.

The one objection I can come up with
is that this would change the set builder notation semantics too much

Yes, to the point where you are hijacking the syntax, for no useful gain,
more than extending it ;-).

Terry Jan Reedy

[Eighty]

Terry Reedy wrote:

whereas the analogous expansion of your proposal

for x in xs:
while cond(x):
yield e(x)

is an infinite loop and not at all what you mean.

You're right. The syntax is ambiguous. I agree it's not a good idea,
now. :)

x for x in xs while cond(x) if blah(x)
x for x in xs if blah(x) while cond(x)
x*y for x in xs while cond(x) for y in ys

These wouldn't be a problem.
"... for x in xs while cond(x) ..." would be transformed into "... for
x in takewhile(cond, xs) ..."
which could be applied to an if thingy if you first transform
"... for x in xs if cond(x) ..." into "... for x in filter(cond, xs)
....".

[Neil Hodgson]

Eighty:

So does no one have a comment on this?

Similar proposals have appeared before (such as on python-dev about
a year ago) and haven't attracted much positive comment. The benefits
appear to be small compared to the cost of making the language larger.
You could try the formal route of writing a PEP so that a detailed
proposal and its reasons for (probable) rejection would be available for
others.

Neil