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