first, i posted it two days ago, so it's funny it got posted only now... <br>the moderators are sleeping on the job :)<br><br>anyway.<br><br>> Note that of the continue cases you offer, all of them are merely simple<br>
> if condition<br><br>yes, i said that explicitly, did you *read* my mail?<br>but i also said it's not always possible. you *can't* always tell prior to doing something<br>that it's bound to fail. you may have os.path.isfile
, but not an arbitrary <br>"is_this_going_to_fail(x)"<br><br>and doing <br>> [1.0 / x for x in y if z(x != 0)]<br>is quite an awkward way to say "break"... <br>if then_break(cond) <br>instead of <br>
if cond then break<br><br>- - - - -<br><br>anyway, i guess my friend may have better show-cases, as he's the one who found the<br>need for it. i just thought i should bring this up here. if you think better show cases<br>
would convince you, i can ask him.<br><br>> If you couldn't guess; -1, you can get equivalent behavior without<br>> complicating the generator expression/list comprension syntax.<br><br>so how come list comprehensions aren't just a "complication to the syntax"?
<br>
you can always do them the old way,<br><br>x = []<br>for ....:<br> x.append(...)<br><br>but i since people find {shorter / more to-the-point / convenience} reason enough to <br>have introduced the list-comprehension syntax in the first place, there's also a case
<br>for adding exception handling to it.<br><br>if the above snippet deserves a unique syntax, why not extend it to cover this as well?<br><br>x = []<br>
for ....:<br> try:<br> x.append(...)<br> except:<br> ...<br><br>and it's such a big syntactic change.<br>don't worry, i'm not going to argue it past this.<br><br><br>-tomer<br><br><div><span class="gmail_quote">
On 4/26/06, <b class="gmail_sendername">Josiah Carlson</b> <<a href="mailto:jcarlson@uci.edu">jcarlson@uci.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>"tomer filiba" <<a href="mailto:tomerfiliba@gmail.com">tomerfiliba@gmail.com</a>> wrote:<br>> "[" <expr> for <expr> in <expr> [if <cond>] [except<br>> <exception-class-or-tuple>: <action>] "]"
<br><br>Note that of the continue cases you offer, all of them are merely simple<br>if condition (though the file example could use a better test than<br>os.path.isfile).<br><br> [x for x in a if x.startswith("y") except AttributeError: continue]
<br> [x for x in a if hasattr(x, 'startswith') and x.startswith("y")]<br><br> [1.0 / x for x in y except ZeroDivisionError: continue]<br> [1.0 / x for x in y if x != 0]<br><br> [open(filename) for filename in filelist except IOError: continue]
<br> [open(filename) for filename in filelist if os.path.isfile(filename)]<br><br>The break case can be implemented with particular kind of instance<br>object, though doesn't have the short-circuiting behavior...<br><br>
class StopWhenFalse:<br> def __init__(self):<br> self.t = 1<br> def __call__(self, t):<br> if not t:<br> self.t = 0<br> return 0<br> return self.t<br><br>z = StopWhenFalse()
<br><br>Assuming you create a new instance z of StopWhenFalse before doing the<br>list comprehensions...<br><br> [x for x in a if z(hasattr(x, 'startswith') and x.startswith("y"))]<br> [1.0 / x for x in y if z(x != 0)]
<br> [open(filename) for filename in filelist if z(os.path.isfile(filename))]<br><br><br>If you couldn't guess; -1, you can get equivalent behavior without<br>complicating the generator expression/list comprension syntax.
<br><br> - Josiah<br><br></blockquote></div><br>