[Python-Dev] suggestion: except in list comprehension (original) (raw)
tomer filiba tomerfiliba at gmail.com
Wed Apr 26 20:49:57 CEST 2006
- Previous message: [Python-Dev] suggestion: except in list comprehension
- Next message: [Python-Dev] Must objects with __enter__/__exit__ also supply __context__?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
first, i posted it two days ago, so it's funny it got posted only now... the moderators are sleeping on the job :)
anyway.
Note that of the continue cases you offer, all of them are merely simple if condition
yes, i said that explicitly, did you read my mail? but i also said it's not always possible. you can't always tell prior to doing something that it's bound to fail. you may have os.path.isfile, but not an arbitrary "is_this_going_to_fail(x)"
and doing
[1.0 / x for x in y if z(x != 0)] is quite an awkward way to say "break"... if then_break(cond) instead of if cond then break
anyway, i guess my friend may have better show-cases, as he's the one who found the need for it. i just thought i should bring this up here. if you think better show cases would convince you, i can ask him.
If you couldn't guess; -1, you can get equivalent behavior without complicating the generator expression/list comprension syntax.
so how come list comprehensions aren't just a "complication to the syntax"? you can always do them the old way,
x = [] for ....: x.append(...)
but i since people find {shorter / more to-the-point / convenience} reason enough to have introduced the list-comprehension syntax in the first place, there's also a case for adding exception handling to it.
if the above snippet deserves a unique syntax, why not extend it to cover this as well?
x = [] for ....: try: x.append(...) except: ...
and it's such a big syntactic change. don't worry, i'm not going to argue it past this.
-tomer
On 4/26/06, Josiah Carlson <jcarlson at uci.edu> wrote:
"tomer filiba" <tomerfiliba at gmail.com> wrote: > "[" for in [if ] [except > : ] "]" Note that of the continue cases you offer, all of them are merely simple if condition (though the file example could use a better test than os.path.isfile). [x for x in a if x.startswith("y") except AttributeError: continue] [x for x in a if hasattr(x, 'startswith') and x.startswith("y")] [1.0 / x for x in y except ZeroDivisionError: continue] [1.0 / x for x in y if x != 0] [open(filename) for filename in filelist except IOError: continue] [open(filename) for filename in filelist if os.path.isfile(filename)] The break case can be implemented with particular kind of instance object, though doesn't have the short-circuiting behavior... class StopWhenFalse: def init(self): self.t = 1 def call(self, t): if not t: self.t = 0 return 0 return self.t z = StopWhenFalse() Assuming you create a new instance z of StopWhenFalse before doing the list comprehensions... [x for x in a if z(hasattr(x, 'startswith') and x.startswith("y"))] [1.0 / x for x in y if z(x != 0)] [open(filename) for filename in filelist if z(os.path.isfile (filename))] If you couldn't guess; -1, you can get equivalent behavior without complicating the generator expression/list comprension syntax. - Josiah -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20060426/21b8fdfe/attachment-0001.htm
- Previous message: [Python-Dev] suggestion: except in list comprehension
- Next message: [Python-Dev] Must objects with __enter__/__exit__ also supply __context__?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]