On 2019-11-03 12:24 p.m., Andrew Barnert via Python-ideas wrote:
On Nov 2, 2019, at 21:02, Random832 <random...@fastmail.com> wrote:
>
>> On Sun, Oct 27, 2019, at 19:17, Andrew Barnert via Python-ideas wrote:
>>> On Oct 27, 2019, at 15:07, Ben Rudiak-Gould <benrud...@gmail.com> wrote:
>>>
>>> throw is an expression, not a statement, in C++. I see no reason raise
>>> couldn't be an expression in Python. It doesn't even need a special
>>> rule in the grammar:
>>>
>>> from __future__ import raise_function
>>>
>>> foo.setParseAction(lambda a, b, c: raise(MumbleMumble()))
>>
>> That’s a pretty big breaking change. Every line of code in every
>> library and app that raises would have to change to add parens.
>
> Could raise be made an expression without adding parens?
I think the best idea is to use yield as a model: the precedence is as
“statement-like” as reasonably possible, so you almost never need parens around
the expression being raised, but the raise expression itself is not an
expression; it’s only usable (at least initially) in parens or as a statement
on its own. Like this:
raise_stmt ::= raise_expr
enclosure ::= ... | raise_atom
raise_atom ::= "(" + raise_expr + ")"
raise_expr ::= "raise" [expression ["from" expression]]
(I think making it an enclosure, a sister production to parenth_form, is the
right answer, but I haven’t actually tried it or worked through any complex
examples.)
> Or, C#'s throw is allowed in certain specific contexts (lambda bodies and conditional expressions) without being a general expression.
Just like, e.g., yield_expr is allowed in assignment statements without being a
general expression, and generator_expr is allowed in a call with one arg
without being a general expression. Obviously neither of those makes sense for
raise (not that it would be ambiguous there, just that it would nearly always
be completely useless), but maybe there are places that are, maybe including
the same ones as in C#.
counter-argument: foo = raise NIY
But I think it’s better to start with the most restrictive rule, and then add
additional constructions or exceptions later. If it turns out that lambda could
take expression | raise_expr without ever to being ambiguous to humans or the
parser, and it would often make real code read nicer, it’s easy to add that
later. If we start our allowing it and it turns out to be sometimes
human-ambiguous, it probably either takes 3 versions to deprecate away or has
to stay as a language wart forever.
> Being in the true portion of a conditional expression in python would require
parentheses *around* the raise, though, e.g. (raise whatever) if condition else
true.
Sure. One of the advantages of making raise_stmt just raise_expr is that it
gives all of these questions obvious answers. Zillions of lines of working code
raise the result of a conditional expression without parens, so raise_stmt has
to still take one, so raise_expr has to as well. And that means a raise_expr
obviously can’t be used as the true clause of a conditional or it would be
ambiguous. (Of course a raise_atom, in parens, is a general expression, and
more specifically an or_test, so it can be used there.)
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/BMC2MWKJ47MMVMAWLHFPLSSKIKAQNIIE/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/RJUUCKOZOLEUIBXXV5H5WFEUZTKJ2EDP/
Code of Conduct: http://python.org/psf/codeofconduct/
