On Thu, May 27, 2021 at 12:39 PM Ricky Teachey <ri...@teachey.org> wrote:
> On Thu, May 27, 2021 at 2:32 PM micro codery <ucod...@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 <matthew...@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
_______________________________________________
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/PPQQUUMPF7G4742JIUMUGD4WL7TRCHGW/
Code of Conduct: http://python.org/psf/codeofconduct/
