On Thu, May 27, 2021 at 12:39 PM Ricky Teachey <ricky@teachey.org> wrote:
On Thu, May 27, 2021 at 2:32 PM micro codery <ucodery@gmail.com> wrote:
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 ;-) On Thu, May 27, 2021 at 2:19 PM Matt del Valle <matthewgdv@gmail.com> wrote:
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