[Python-ideas] except expression

[Amber Yust]

Not everywhere. As previously mentioned, lambdas use a colon which is
followed by an expression, not a block.
On Feb 15, 2014 2:24 PM, "Philipp A." <flying-sheep at web.de> wrote:

> hmm i still don’t like the colon. everywhere else in python, it means “new
> block follows”
>
> and i’m sure nobody here wants to allow the following?
>
> value = hovercraft() except EelsException:
>    remove_eels()
>    no_eels  #this is assigned to “value” if we have too many eels
>
> i like it in coffeescript and scala, but it’s not used in python, so we
> shouldn’t introduce it.
>
> neither should we introduce a colon that *can’t* be followed by a block.
>
> if we wanted the colon in any case, we’d need to do:
>
> winner = germans_win() except EurekaException: return greeks
>
> value = hovercraft() except EelsException:
>    remove_eels()
>    return no_eels
>
> but i’m still partial to stomach_content = eat() except ThinMintError
> pass explode()
>
>
> 2014-02-15 19:11 GMT+01:00 Steven D'Aprano <steve at pearwood.info>:
>
>> On Sat, Feb 15, 2014 at 11:20:13AM +1300, Greg Ewing wrote:
>> > Here's another one:
>> >
>> >    things[i] (except IndexError: 42)
>>
>> I believe Jan Kaliszewski independently came up with the same syntax
>> earlier, which is a good sign. Two people suggesting the same thing is
>> promising.
>>
>> Jan also suggested that this syntax allows binding the exception:
>>
>>     things[i] (except IndexError as exc: exc.args)
>>
>> and multiple except terms:
>>
>>     things[i] (except IndexError as exc: exc.args,
>>                except NameError: "missing",
>>                except KeyError: None,
>>                )
>>
>>
>> One might also catch multiple exceptions in a single term:
>>
>>     things[i] (except IndexError,KeyError as exc: exc.args)
>>
>>
>> It's a tiny bit unusual to have a colon that doesn't introduce a block,
>> but only a tiny bit. There is precedent:
>>
>>     lambda x, y: (x+y)/(x*y)
>>
>>
>> This suggests that perhaps the parentheses aren't needed unless you have
>> multiple except parts:
>>
>>     things[i] (except IndexError, KeyError as exc: exc.args)
>>     things[i] except IndexError, KeyError as exc: exc.args
>>
>>
>> but I think they ought to be compulsory if you use multiple excepts. And
>> of course they are useful for continuing over multiple lines.
>>
>> I think this syntax looks good when used in compound expressions:
>>
>>     mylist = [23, lambda x: x+1, things[i] except IndexError: 42, ""]
>>
>>     result = function(a, b except NameError: "undefined", c)
>>
>>     result = function(a, b, c) except ValueError: float('nan')
>>
>>     if something(x) except TypeError: None:
>>         block
>>
>>
>> Dicts are problematic. Should the dict colon bind more or less strongly
>> than the except colon? I suggest we follow the same rule as for lambda:
>>
>>     adict = {lambda x: x+1: "value",
>>              key+1 except TypeError: 23: "value",
>>              }
>>
>>
>> Here is a torture-test for the syntax: can we combine it with an
>> if-expression? I think we can, although you may need parentheses to
>> disambiguate the expression:
>>
>>     something(x) (except TypeError: a if condition else b)
>>
>>     ((something(x) if x else other(x)) (except ValueError: -1)
>>
>>     something(x) if x else (other(x) except ValueError: -1)
>>
>>
>> Trying to do too much in a single expression is never exactly
>> *beautiful*, but it can be read.
>>
>> This does look a tiny bit like a function call, especially if you delete
>> the space between the leading expression and the opening bracket:
>>
>>     # ugly, don't do this
>>     things[i](except IndexError: 42)
>>
>> but that's not actually ambiguous, since the keyword except cannot be an
>> argument to a function.
>>
>> I like this. I think this is the first non-sucky syntax I've seen (sorry
>> to everyone who proposed sucky syntax *wink*).
>>
>>
>>
>> > This has the advantage of putting the colon inside parens,
>> > where it's less likely to get confused with other uses of
>> > colons in the same line (by humans, if not by the computer).
>> >
>> > Also it might be useful to be able to say
>> >
>> >    things.remove(i) (except ValueError: pass)
>> >
>> > which would be equivalent to
>> >
>> >    things.remove(i) (except ValueError: None)
>> >
>> > but would read more smoothly in cases where you're not
>> > interested in the value of the expression.
>>
>> Certainly not! pass implies that *no return result is generated at all*,
>> which is not possible in Python. Returning None is the right thing to
>> do.
>>
>>
>>
>> --
>> Steven
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140215/cdcd717b/attachment-0001.html>