But what is actually valid to follow a decorator in this proposal?
Any simple expression, any expression? Is it limited to assignment
espressions?
At this point, I have in mind any expression that appears to the right, which I believe is what is allowed today:
@1/2 "lala" and money
def func(): ...
I don't think I was clear enough with my original question. I agree that any valid expression
can follow the @, just like function decorators; I said as much in my original proposal.
My question is what can follow after the line "@expression"? Could it be a with block; a
lambda; a match statement? Probably just an assignment statement, but even just that
covers a lot including multi-assignment or including a yield expression. But I think I know
your answer to this from your reply to my later examples ;-)
To reiterate my point from earlier in the thread, I am quite firmly opposed to having the decorator on the same line as the statement being decorated. I'll just copy-paste my reasoning for it:
<snip>
Which is in my
mind not very pythonic. Also, my brain just has an easier time parsing
the multiline version than the single-line one (though I concede that a
combination of familiarity and syntax highlighting would solve that
issue eventually).
It also represents an
asymmetry between the syntax of the proposed assignment decorators and
the syntax for function and class decorators.
And finally, it doesn't cleanly accommodate use-cases like those proposed by
Stéfane in the previous thread:
Yes, there seems to have been a lot of rejection of the single-line decorator. I liked it for
variable decorating because I didn't think developers would use it if it meant adding an
extra line to every variable declaration that wanted to take advantage of the new syntax.
Also, limiting its use to only identifiers kept the lines short. But I agree that it could lead
some very unpythonic code, especially if multiple decorators on the same line were
allowed.
I just thought it looked better, but would you and others here like it better if the
NEWLINE requirement was kept for all decorators? There is nothing in the original
proposal that requires a single line.
I also don't know what should happen for complicated assignments, and I think this
has been the death of such variable decorator discussions in the past, so I would
still push for only bare identifiers, with or without a type hint (but maybe it will be
better received by more if the type hint is required?). I still think such a proposal is
strong enough on its own to be of value to the language.
So now the syntax would be:
@decorator
variable: Type
@decorator("spam", eggs)
variable: Type
become
variable = decorator("variable")
variable = decorator("spam", eggs)("variable")
I'm not sure that the type hint shouldn't be passed as an additional parameter,
especially if one is always required. Yes it is still different from a function
decorator in that you are not getting the variable object (which may or may not
exist) but instead its name as a string. However, decorators that expect to be
applied to variables should already be drastically different. Even if they did get
the variable object, there would be not necessarily be a __code__ or
__name__ or __dict__ attribute. They won't be callable (generally) where most
current decorators attempt to call func, wrapped in an internal closure.
In this case Stéfane's long example would still be valid, and some of the
one-liners would instead look like this:
class Colors(Enum):
@str
RED: str
@str
GREEN: str
@str
BLUE: str
@namedtuple("x y z")
Point: NamedTuple
@os.getenv
PATH: Optional[str]
Regards,
~Jeremiah