On 2021-05-26 09:43, Ricky Teachey wrote:
These two ideas of a decorator syntax result are not the same:
RESULT A: function decorator # func = decorator("spam")(func)
RESULT B: variable decorator # name = decorator("spam")("name")
...because func is passed as an object, but "name" a string representing the name of the object. Two very different things.
For this reason I think I would agree even more so that the differences in the decorator behavior would be an extremely significant point of confusion.
This got me to thinking: what if access to the variable name were provided by another means, and ONLY when the decorator syntax is employed?
This seems contradictory to me. It looks like you're saying, "We shouldn't use decorator syntax to represent two different things (object vs name), but instead decorator syntax should give us access to two different things (object vs name)." I realize based on your proposal there is a distinction here but I think it's quite a narrow one and doesn't resolve the basic problem, which is that currently decorators operate on objects and these new proposals are about making them operate on names. I think there may be value in having some feature that lets us get access to the name side of an assignment. But I wouldn't call such a thing a "decorator", nor would I want to use the same @ syntax that is used for decorators. To me that would be confusing, because the behavior is totally different. Even with your __decorator_call__ proposal, there's still a jarring shift from, in some cases, using just the object, and in other cases stuffing a new parameter (the name) into the parameter list. That seems awkward to me. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown