RetroSearch Browse

Wed Apr 26 20:49:57 CEST 2006 · https://mail.python.org/pipermail/python-dev/2006-April/064455.html

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:
> > "[" <expr> for <expr> in <expr> [if <cond>] [except
> > <exception-class-or-tuple>: <action>] "]"
>
> 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 

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-April/064455.html below:

[Python-Dev] suggestion: except in list comprehension