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.
I think this discussed when decorators were first proposed, and the consensus
wasn’t “yuck” but rather “let’s see if we need it, and only worry about it when
it comes up”. If so, that’s a small point in favor of your proposal, so you
might want to search the original discussion.
> 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.
> 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?
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.
_______________________________________________
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/BA3XNS254WGO4642YKFH5676Y4T7CULI/
Code of Conduct: http://python.org/psf/codeofconduct/
