On 21Oct2019 20:41, Andrew Barnert <abarnert@yahoo.com> wrote:
On Oct 21, 2019, at 19:53, Cameron Simpson <cs@cskk.id.au> wrote:
On 21Oct2019 17:18, Yonatan Zunger <zunger@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 <cs@cskk.id.au>