if in for loop

[Ryan Lowe]

i thought id ask here before wirting a PEP, if people thought it would be a
good enhancement to allow if clauses in regular for-statements like so:

for x in y if x < 10 :
is semantically equivalent to
for x in [x for x in y if x < 10] :

but is shorter and easier to read. basically, the if works as a filter for
the values in the iterator. its not a major change, purely syntactic sugar.
and clearly backwards-compatible.

seem reasonable?

ryan

[Sean Ross]

"Ryan Lowe" <ry*******@msn.com> wrote in message
news:rk***********************@news4.srv.hcvlny.cv .net...

i thought id ask here before wirting a PEP, if people thought it would be a good enhancement to allow if clauses in regular for-statements like so:

Hi.
This was brought up in July:
http://groups.google.ca/groups?hl=en...ing.google.com

Here's the link for the entire thread:
http://groups.google.ca/groups?hl=en...ing.google.com

This was my response then (and now):
http://groups.google.ca/groups?hl=en...bellglobal.com

Other opinions will differ. (For instance, Michele Simionato was +1 on the
idea)
-0

Sean Ross

[Ryan Lowe]

"Sean Ross" <sr***@connectmail.carleton.ca> wrote in message
news:ig*******************@news20.bellglobal.com.. .

"Ryan Lowe" <ry*******@msn.com> wrote in message
news:rk***********************@news4.srv.hcvlny.cv .net...

i thought id ask here before wirting a PEP, if people thought it would be

a

good enhancement to allow if clauses in regular for-statements like so:
Hi.
This was brought up in July:

http://groups.google.ca/groups?hl=en...1.0307021036.5
08d7d7d%40posting.google.com
Here's the link for the entire thread:
http://groups.google.ca/groups?hl=en...92e1.030702103
6.508d7d7d%40posting.google.com&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3
DUTF-8%26selm%3D840592e1.0307021036.508d7d7d%2540postin g.google.com
This was my response then (and now):
http://groups.google.ca/groups?hl=en...841%24eF3.7215
51%40news20.bellglobal.com
Other opinions will differ. (For instance, Michele Simionato was +1 on the
idea)
-0

Sean Ross

>>> for x in y if x < 10 :

is semantically equivalent to

>>> for x in [x for x in y if x < 10] :

well ok, so it wasnt a unique idea. but hey, if multiple people think the
same thing up independently, maybe theres something there...
i like list-comprehensions, they add a lot to the language, but they do seem
sort of thrown in.
fixing the symmetry, as the july poster put it, is a good way to think about
it.

your complaint is this?
(being symmetrical) we should also be able to write:
msgs = []
for x in words:... for y in otherwords:
... msgs.append("%s %s"%(x,y))
... msgs

['hello foo', 'hello bar', 'bonjour foo', 'bonjour bar']
as follows:

msgs = []
for x in words for y in otherwords:
msgs.append("%s %s"%(x,y))

i agree its not as clear whats going on here as in the if example, but its
no less readable than the list-comprehension version, i.e. msgs = ["%s
%s"%(x,y) for x in words for y in otherwords]
whats the argument? should they do away with double for's in list-comp?

It doesn't do anything for me. I actually find it harder to
read: the brackets at least guide my eyes to the various parts
of the line, which the form you propose doesn't do. Also, its most definitely
not backwards compatible, and I wish you wouldn't
send three duplicate messages to the newsgroup with
different headers but the same body.

**harder** to read!? cmon now. i will buy its certainly not a necessary
change, but harder to read...
all i meant by it being backwards compatible is that for statements without
the clause would work as they did before.
sorry about the triple post. i got error messages when i posted so i didnt
think they went through.

ryan

[Sean Ross]

"Ryan Lowe" <ry*******@msn.com> wrote in message
news:vX***********************@news4.srv.hcvlny.cv .net...

your complaint is this? [snip code example] i agree its not as clear whats going on here as in the if example, but its
no less readable than the list-comprehension version, i.e. msgs = ["%s
%s"%(x,y) for x in words for y in otherwords]
whats the argument? should they do away with double for's in list-comp?

Actually, I hadn't really formulated an argument. I'm indifferent to the
proposal, with some slight leaning towards non-acceptance (as my "-0" vote
suggests). I don't think I can justify why I don't care for the proposal. It
does seem reasonable. If your goal is to maintain consistency within the
language, then this proposal would seem to aid that goal. I also prefer that
a language provide consistency. The problem, I suppose, should you choose to
be consistent, is deciding in which direction to focus that consistency.
While I very much enjoy list comprehensions, and would prefer that they not
be removed from the language (read, "Never remove them from the language,
please!" and "Could we please have generator comprehensions, as well?"), I
also see that they are somewhat of an anomaly and that they can hinder
readability when they are allowed to grow without bound. Of course, the same
can be said for deeply nested for-loops - at some point, as you add more and
more for-loops, the meaning becomes less and less clear (which would be one
reason people refactor such things using functions). Anyway. I suppose the
question I was addressing in the earlier post was this: Does consistency, in
this instance, aid or hinder, and what does it aid or hinder. If we argue
that filtering should be added to the for-loop syntax because that syntax
should be more consistent with the list comprehension syntax, then it seems
reasonable to also argue for the inclusion of multiple for-expressions, on
the same basis (Is this argument fallacious? I'm not sure...looks like a
slippery-slope) . So, anticipating that others might make this argument once
one part of list comprehension syntax had been retro-fitted into the
existing for-loop syntax, it seemed reasonable to ask - do you also think
multiple for-expressions in a for-loop would be of benefit? Do you want only
the one and not the other? (False dichotomy?) If so, why? If not, why not?
These are topics you may wish to address, were you to write a PEP. As I've
said, I'm pretty much neutral towards the whole thing, with some tendency
towards caution.

[snipped quote from John Roth posting] **harder** to read!? cmon now. i will buy its certainly not a necessary
change, but harder to read...

for x in X if condx(x) for y in Y if condy(y) for z in Z if condz(z) for w
in W if condw(w):
suite

for x in X:
if condx(x):
for y in Y:
if condy(y):
for z in Z:
if condz(z):
for w in W:
if condw(w):
suite

Neither strikes me as being particularly easier to read than the other.

for x in X if condx(x):
suite

for x in X:
if condx(x):
suite
Same thing here.

[Gary Feldman]

On Wed, 20 Aug 2003 11:16:04 -0400, "Sean Ross"
<sr***@connectmail.carleton.ca> wrote:

... (which would be one
reason people refactor such things using functions).

Bingo.

The code is complex because the set of conditions is complex, and there's
no way that pure syntactic sugar can eliminate the semantic complexity.
Refactoring does help, because it adds layers of abstraction, allowing the
author and, more importantly, the subsequent maintainers to focus on small
chunks at a time. Moving the conditions around within one function, and
eliminating or adding punctuation or keywords doesn't have the same effect.

Gary