a potential pep to extend the syntax of for loops

[pang]

Hello,
This is an idea about something I'd like to see implemented in
python.
I understand that's the purpose of PEPs, so I'll write it as a PEP,
but
send it here to receive your valuable feedback.

Abstract

This is a proposal to increase the richness of for loops, only to the
extent that it equals that of list and generator comprehensions. In
the
opinion of the proponent, this will make the language more uniform and
would reduce the excessive level of nesting that is required
sometimes,
without introducing special keywords, or breaking backwards
compatibility.

This PEP is independent of, but related to PEP 3142.

Rationale
The syntax of a for loop is restricted to the following:
Nesting for loops and conditionals is possible, of course:
However, for list and generator comprehensions, the syntax is more
concise:

list=[func(x,y,..) for x in list1 for y in list2 ... if

condition(x,y,...)]

Loops and comprehensions serve for similar purposes, and sometimes
what
was first written in one way is finally changed into the other. Thus
it
would be convenient to allow for more similar syntax in both of them.
This requires that the syntax of a for loop allows for nested for and
conditionals (and possibly while loops (see PEP 3142))

In general, whenever

[expression1 iterator] is a valid list comprehension, then
iterator:
statements

should be a valid loop.

As another example, it is sometimes the case that an iteration over
two
lists can be rewritten as a single iteration:it is somewhat more conceptual to think of the first iteration as a
single loop.

It is actually possible to come very close to the notation proposed
using the generator comprehensions introduced in python 2.5:but this notation is cumbersome.

This PEP responds to the philosophy that if a nesting level is unused,
it should be avoided. For example, in the code:

the second nesting level doesn't contain any statements and thus,
should this PEP be passed, it should be written:

 

[Chris Rebert]

 Hello,
 This is an idea about something I'd like to see implemented in
python.
I understand that's the purpose of PEPs, so I'll write it as a PEP,
but
send it here to receive your valuable feedback.

Abstract

This is a proposal to increase the richness of for loops, only to the
extent that it equals that of list and generator comprehensions. In
the
opinion of the proponent, this will make the language more uniform and
would reduce the excessive level of nesting that is required
sometimes,
without introducing special keywords, or breaking backwards
compatibility.

This PEP is independent of, but related to PEP 3142.

Rationale
The syntax of a for loop is restricted to the following:
Nesting for loops and conditionals is possible, of course:
However, for list and generator comprehensions, the syntax is more
concise:

   list=[func(x,y,..) for x in list1 for y in list2 ... if

condition(x,y,...)]

Loops and comprehensions serve for similar purposes, and sometimes
what
was first written in one way is finally changed into the other. Thus
it
would be convenient to allow for more similar syntax in both of them.
This requires that the syntax of a for loop allows for nested for and
conditionals (and possibly while loops (see PEP 3142))

In general, whenever

[expression1  iterator] is a valid list comprehension, then
iterator:
    statements

should be a valid loop.

As another example, it is sometimes the case that an iteration over
two
lists can be rewritten as a single iteration:it is somewhat more conceptual to think of the first iteration as a
single loop.

It is actually possible to come very close to the notation proposed
using the generator comprehensions introduced in python 2.5:but this notation is cumbersome.

This PEP responds to the philosophy that if a nesting level is unused,
it should be avoided. For example, in the code:

the second nesting  level doesn't contain any statements and thus,
should this PEP be passed, it should be written:

This syntax sugar seems to be too sweet, to the point that it causes
*cavities* IMHO.
It seems Perlish (always a bad sign), quite similar to how Perl lets
you add 'if' and 'while' suffixes to statements; it undermines the
uniformity and simplicity of Python's syntax.

The extra indentation and nesting level is useful in that it
unambiguously indicates what order the for-loops are nested in. Also,
if the loop body of the outer loop ever becomes more complicated
beyond just containing an inner loop, the lines are easily added,
whereas this proposal would require a more drastic and complicated
splitting back up of the loop statement.

Though list comprehensions and for-loops are indeed closely related,
this is one instance where there shouldn't be a middle ground of
comprehension-like for-statements because it complicates things too
much. It's like with if-elif-else and the ternary operator -- one is
for very simple cases, and one is for anything else; anything in
between makes it harder to choose and makes the right choice in a
situation more ambiguous. Python is not Lisp and `for` is not the DO
macro ;-).

I'll conclude by citing the Zen: "Special cases aren't special enough
to break the rules."
And secondly: "There should be one-- and preferably only one --obvious
way to do it."
This PEP seems to break both these principles without enough of a gain
to have "practicality beat purity".

-1 for me on this (not that I'm entitled to cast a vote .

Cheers,
Chris

 

[Lie Ryan]

Hello,

This is an idea about something I'd like to see
implemented in python. I understand that's the purpose of
PEPs, so I'll write it as a PEP, but send it here to receive
your valuable feedback.

Abstract

This is a proposal to increase the richness of for loops,
only to the extent that it equals that of list and generator
comprehensions. In the opinion of the proponent, this will
make the language more uniform and would reduce the excessive
level of nesting that is required sometimes, without
introducing special keywords, or breaking backwards
compatibility.

The PEP suffers from several problems. Some of them related to being
quite unclear in several edges, others are real problems.

This PEP is independent of, but related to PEP 3142.

Rationale
The syntax of a for loop is restricted to the following:
Nesting for loops and conditionals is possible, of course:
However, for list and generator comprehensions, the syntax is
more concise:

list=[func(x,y,..) for x in list1 for y in list2

... if condition(x,y,...)]

Loops and comprehensions serve for similar purposes, and
sometimes what was first written in one way is finally
changed into the other. Thus it would be convenient to allow
for more similar syntax in both of them. This requires that
the syntax of a for loop allows for nested for and
conditionals (and possibly while loops (see PEP 3142))

In general, whenever

[expression1 iterator] is a valid list comprehension, then
iterator:
statements

should be a valid loop.

As another example, it is sometimes the case that an
iteration over two lists can be rewritten as a single
iteration:

What is that supposed to mean? Nested looping? Why is that (confusing
thing) better than:

from itertools import product

for x, y in product(range(10), range(10)) if x + y == 5:
print x, y

is equivalent to

How is that equivalent? The second one is generated using completely
different logic than the second one (not to mention it is shorter,
simpler, and faster).

it is somewhat more conceptual to think of the first
iteration as a single loop.

It is actually possible to come very close to the notation
proposed using the generator comprehensions introduced in
python 2.5:
but this notation is cumbersome.

This PEP responds to the philosophy that if a nesting level
is unused, it should be avoided. For example, in the code:

If a nesting level is unused... shouldn't just the whole thing be
deleted? I'm unclear on what you mean by "unused nesting level"

the second nesting level doesn't contain any statements and
thus, should this PEP be passed, it should be written:

What do you mean by "doesn't contain any statements"? If statement is
not a statement?


+1 on the "if" and (possibly) "while" conditional looping.
-1 on shorthand nested for.

 

[pang]

for x in range(10) for y in range(10) if x+y==5:

What is that supposed to mean? Nested looping? Why is that (confusing
thing) better than:

from itertools import product

for x, y in product(range(10), range(10)) if x + y == 5:
     print x, y

That confusing thing is what you use every day for list and generator
comprehension.

But I didn't know that python 2.6 incorporated itertools.product (I
use 2.5, and didn't search hard enough)

I agree that itertools.product is a perfectly nice solution

+1 on the "if" and (possibly) "while" conditional looping.
-1 on shorthand nested for.

same thing here, now that I know about itertools.product

 

[Gabriel Genellina]

This is an idea about something I'd like to see implemented in
python.

The python-ideas list exists to discuss this sort of things.

The syntax of a for loop is restricted to the following:

Note that "list" in your description may be any expression list, in
particular a conditional expression. This is currently valid:

for e in iterable1 if cond else iterable2:
do something

In your proposal, depending whether there is an "else" clause or not, the
"if" should be attached to the expression or the for statement. I'm unsure
if this still can be represented as an LL(1) grammar (and Guido always
said he wants the grammar to stay LL(1)).

 

[Terry Reedy]

This is a proposal to increase the richness of for loops, only to the
extent that it equals that of list and generator comprehensions.

This idea has already been proposed and rejected. But discuss away as
you wish ;=).

tjr

 

[pang]

This idea has already been proposed and rejected.  But discuss away as

you wish ;=).

tjr

Where is that? I didn't see any related pep's. Could you post a link?

 

[Terry Reedy]

Where is that?

py-dev and/or python-ideas lists within last year

> I didn't see any related pep's.

Though helpful, not too many people write PEPs to document rejections.

> Could you post a link?

Sorry, no.

tjr

 

[pang]

Sorry, no.

tjr

well, thank you

Even now it's difficult to find the discussion, but at least I know
about python-ideas.

Thanks to all that replied.

 

[Gabriel Genellina]

Even now it's difficult to find the discussion, but at least I know
about python-ideas.

Try http://blog.gmane.org/gmane.comp.python.ideas