On Thu, May 27, 2021 at 9:34 AM Ricky Teachey <ricky@teachey.org> wrote:
On Thu, May 27, 2021 at 10:25 AM Steven D'Aprano <steve@pearwood.info> wrote:
No, I understood the OP's proposal perfectly. I was agreeing with you implicitly when you previously said the inconsistency between the OP's proposal and current decorator is a problem:
<STEVE WROTE>:
On the other hand, it would be terribly confusing if the same syntax:
@decorate had radically different meaning depending on whether it was followed by a class/function or a bare name
And furthermore, it is even a bigger problem than you explicitly made it out to be because of passing and object vs. passing a string representing the name of an object.
I got the sense that people both liked reading my examples of same-line decorators and pushed back against not making them appear just like function decorators. One way to have my cake and you eat it too would be to relax the current decorator grammar to not require a NEWLINE. AFAICT there would be no ambiguity since after a decorator there must either be another "@" or a "def". Then both function and assignment decorating can be both. These would all be possible and not change the status quo. @cache def factorial(n): pass # This is your example @namedtuple Point = "x y z" # OP was @namedtuple("x y z") Point @not_null @indexed first_name: str
So I was not illustrating the OP's proposal, but showing (but not proposing) a modified version of it that acts more like decorators today, so that we would have this:
# NOT THE OP's PROPOSAL -- more consistent with decorators today, but not as quickly useful on its own @decorator("spam this") var # decorator("spam this")("var")
..rather than this:
# OP's PROPOSAL @decorator("spam this") var # decorator("spam this", "var")
Actually the original proposal was @decorator("spam this") var # var = decorator("var", "spam this") The implied assignment that is not written was a big part of the proposal, as most of my examples were defining the name for the first time, and also the original proposal disallowed assignment (or any statement) after the decorator; it is only valid to have an identifier after. Also the "var" coming first is a subtle but important distinction. By providing the name as the first argument, all of my examples of callables currently in the standard library will work as you say out of the box. If it were to be passed in last, this new syntax would not be usable by any standard library callable (or even third party? Does anyone create factory functions that need the name and take it last?) and lots of new functions would have to be added. Regards, ~Jeremiah