On Thu, May 27, 2021 at 9:34 AM Ricky Teachey <ri...@teachey.org> wrote:
> On Thu, May 27, 2021 at 10:25 AM Steven D'Aprano <st...@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
_______________________________________________
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/ANVAFR7OMMZN6UBOV2PVVP255GS77PCB/
Code of Conduct: http://python.org/psf/codeofconduct/
