On 21Oct2019 20:41, Andrew Barnert <abarn...@yahoo.com> wrote:
On Oct 21, 2019, at 19:53, Cameron Simpson <c...@cskk.id.au> wrote:
On 21Oct2019 17:18, Yonatan Zunger <zun...@humu.com> wrote:
I came across a case which *might* be a use case for a syntax extension, but
I'm not sure. Wanted to get feedback from the group.
*The extension: *Extend the decorator syntax from
decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE
to
decorator ::= "@" expression NEWLINE
where the expression must return a callable that accepts a function of the
indicated signature as its argument.
[...]
Personally, I have 2 concerns. 1: this introduces a lot of scope for
arbitrary complexity after the @ versus the extremely readable
"name(...)" form.
This seems like a consenting-adults thing. Any flexible syntax can be abused to
write unreadable code, but unless there’s a good reason to suspect it will be
abused often (and/or won’t be used helpfully very often) that’s not much of an
argument against it. I don’t think many people would write horrible arbitrary
decorator expressions, except for the kind of people who already do horrible
unpythonic things like writing a ten-line function as a lambda just to assign
it to a variable anyway.
Maybe so. I still have personal reluctance to open such a door without a
good reason.
2: I'm not sure what this would to to uses of "@" as an operator, as has been
suggested various times for various laudable reasons; remember that an @decorator or
other function definition is just another statement, and arbitrary expressions are
already statements.
I don’t understand this. @ already exists as an operator, and already takes
arbitrary expressions for the left and right operands, with no parser
ambiguity. What future worthwhile suggestions to that existing syntax are you
imagining that might break that?
None. I've not thought it through other than that suddenly arbitrary
expressions can occur here where before they could not.
Even if you’re imagining that people might want @ to be a unary prefix
operator as well as a binary operator (like + and -), how does
restricting decorator syntax help ambiguity there? Surely you’d want
the @ operator to be able to take a dotted-name operand.
I guess so. My concerns here are looking specious.
Cheers,
Cameron Simpson <c...@cskk.id.au>
_______________________________________________
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/N6GUHOJNRVJ2Z2UQ24XMXYEDGCOQKCQO/
Code of Conduct: http://python.org/psf/codeofconduct/
