A conditional "for" statement
Hello, I've recently been working on some code where i am processing a list, but excluding certain items. The solution is to use a list comprehension in the "for" statement. An example is: for m in [n for n in range( 0 , 5 ) if n != 2] Determining what's going on here isn't immediately obvious (i.e. what's this new variable n doing?). It would be nice to have a more streamlined syntax such as: for m in range( 0 , 5 ) with m != 2 which is much cleaner and obvious. It is also very much like the list comprehension syntax (although i've changed "if" to "with", and the better of the two is subject to personal opinion and debatable). I would hope that the statements following "with" could be any conditional expression. This is just a thought I had while working today. Thank you for your consideration. Best Regards, Mike
On Thu, Apr 23, 2009 at 3:29 PM, Michael S. Gilbert <michael.s.gilbert@gmail.com> wrote:
Hello,
I've recently been working on some code where i am processing a list, but excluding certain items. The solution is to use a list comprehension in the "for" statement. An example is:
for m in [n for n in range( 0 , 5 ) if n != 2]
Determining what's going on here isn't immediately obvious (i.e. what's this new variable n doing?). It would be nice to have a more streamlined syntax such as:
for m in range( 0 , 5 ) with m != 2
I don't see how this is clearer than either of the obvious alternatives: for m in range(0 , 5): if m == 2: continue #loop body for m in range(0 , 5): if m != 2: #loop body It's certainly /slightly/ shorter, but the problem is not severe enough to warrant new syntax, imho. Also, this uses the `with` keyword in a completely different way from its existing use, which could be confusing. Cheers, Chris -- I have a blog: http://blog.rebertia.com
On Thu, 23 Apr 2009 15:34:58 -0700, Chris Rebert wrote:
I don't see how this is clearer than either of the obvious alternatives:
The purpose would also be efficiency. It's less efficient to check the condition m==2 during every loop iteration than it is to set up a list that excludes m=2 to begin with.
It's certainly /slightly/ shorter, but the problem is not severe enough to warrant new syntax, imho. Also, this uses the `with` keyword in a completely different way from its existing use, which could be confusing.
Right, like I said, that's debatable, and "if" probably makes more sense since it mimicks the list comprehension syntax anyway. Example: for m in range( 0 , 5 ) if m != 2: print m vs [m for m in range( 0 , 5 ) if m != 2 ]: Mike
"Michael S. Gilbert" <michael.s.gilbert@gmail.com> writes:
The purpose would also be efficiency. It's less efficient to check the condition m==2 during every loop iteration than it is to set up a list that excludes m=2 to begin with.
Huh? “Set up the list” involves exactly the conditional check for each item in the original sequence. So those condition checks for each item in the original sequence are going to be paid anyway. -- \ “bash awk grep perl sed, df du, du-du du-du, vi troff su fsck | `\ rm * halt LART LART LART!” —The Swedish BOFH, | _o__) alt.sysadmin.recovery | Ben Finney
Proposed and rejected. The difference between for i in seq: if p(i): do(i) and for i in seq if p(i): do(i) is deletion of ':\n'. Hardly worth the bother.
On Thu, 23 Apr 2009 18:56:28 -0400, Terry Reedy wrote:
Proposed and rejected.
The difference between
for i in seq: if p(i): do(i)
and
for i in seq if p(i): do(i)
is deletion of ':\n'. Hardly worth the bother.
What about the difference in efficiency? For the second case, you've reduced the number of iterations (by the number of items that your conditional expression has excluded) and eliminated one operation per iteration (evaluation the if statement). Mike
what makes you think that this would be more efficient? If it was significant, surely the compiler could detect the for/if idiom and optimize it. On Thu, Apr 23, 2009 at 4:07 PM, Michael S. Gilbert < michael.s.gilbert@gmail.com> wrote:
On Thu, 23 Apr 2009 18:56:28 -0400, Terry Reedy wrote:
The difference between
for i in seq: if p(i): do(i)
and
for i in seq if p(i): do(i)
is deletion of ':\n'. Hardly worth the bother.
What about the difference in efficiency? For the second case, you've reduced the number of iterations (by the number of items that your conditional expression has excluded) and eliminated one operation per iteration (evaluation the if statement).
Michael S. Gilbert wrote:
What about the difference in efficiency? For the second case, you've reduced the number of iterations (by the number of items that your conditional expression has excluded) and eliminated one operation per iteration (evaluation the if statement).
No, you haven't. You still have to perform the test for every iteration. Your proposed syntax would do *exactly* the same thing as the 3-line version. -- Greg
Le Thu, 23 Apr 2009 18:29:15 -0400, "Michael S. Gilbert" <michael.s.gilbert@gmail.com> s'exprima ainsi:
Hello,
I've recently been working on some code where i am processing a list, but excluding certain items. The solution is to use a list comprehension in the "for" statement. An example is:
for m in [n for n in range( 0 , 5 ) if n != 2]
Determining what's going on here isn't immediately obvious (i.e. what's this new variable n doing?). It would be nice to have a more streamlined syntax such as:
for m in range( 0 , 5 ) with m != 2
Should be 'if' anyway; certainly not 'with', anyway.
which is much cleaner and obvious.
Actually, I see the syntactic issue differently. I applies to lambdas as well as list comps (that, in fact, also implicitely define unnamed funcs). Often filtering or mapping expressions are straightforward operations on the items, so that the whole construct needed seems heavy redundance: [n for n in numbers if n!=2] filter(numbers, lambda n: n!=2) What we would like to express is only the "operational" part of the expression: [numbers if !=2] filter(numbers, !=2) This would be nice as well for a swtich-like statement: swith on x: case == 0: ... case < 0: ... case > 0: ... else: ;-) But this is (imo elegant) postfix syntax that allows omitting parameters using an implicit value stack, but does not fit in python, I guess. def half: return 2 / def square: return dup * def sum: return + The price to pay is difficult stack juggling as soon as operations are not trivial. What I would certainly like is restricting the field of anonymous func expression (in both lambdas and list comps) to these trivial cases -- so that we could then omit parameters/items using postfix syntax. Otherwise use a defined func wich implicit parameter is the item. Of course the drawback is that expressions of very low level of complication would have to be defined in a func: def hasValidValue(result): return result.value is not None validResults = [results if hasValidValue] But we may allow attribute syntax: noneResults = [results if .value]
Best Regards, Mike
Denis ------ la vita e estrany
participants (7)
-
Ben Finney -
Bruce Leban -
Chris Rebert -
Greg Ewing -
Michael S. Gilbert -
spir -
Terry Reedy