Whoops, replying all this time.
I am still very confused as to the scope of this counter proposal re variable
decorating. I have only seen two such examples here
@decorator variable
# variable = decorator.__decoration_call__(None, "variable")
@decorator variable = "spam"
# variable = decorator.__decoration_call__(variable, "variable")
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(): ...
Here are some interesting uses that were brought up
in the other thread and I would like to know how they would work.
@decorator
spam = eggs = cheese = "tomatoes"
@decorator
spam, eggs, cheese = "tomatoes"
@decorator
spam, eggs = cheese = "tomatoes"
@decorator
spam = (eggs := "cheese)
@decorator
locals()[find_it() or "default"] = spam()
Regards,
~Jeremiah
I would also like to know how all of these work :D I am not sure about most of them but open to suggestions.
The only one that I feel confident about is:
@decorator
spam = (eggs := "cheese)
...which, I think, should be:
decorator.__decoration_call__(spam, "spam")
Unfortunately for the proposal most people don't seem too thrilled with it. So I don't plan to spend a lot of time thinking through these examples and suggesting behavior. Anyone is welcome to do that though, this isn't MINE in the sense I am jealously guarding ownership of the details. :)
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
Yes, and for this reason I really liked Steve's googly eyes proposal in the other thread. But I wonder if there value in specifically giving decorators access to the name side?
It seems to me that it would open up a lot of possibilities, just as when descriptors learned their names.
class Desc:
def __set_name__(self, owner, name):
def __get__(self, instance, owner):
if instance is None:
pass
class C:
v = Desc()
>>> C().v
I am C.v
We could make the __decoration_call__ method even more powerful. We could give it access not just to the name side, but to the type info, and even the code object/expression side (i.e., RHS).
@decorator
x: Fraction = 1/2
# decorator.__decoration_call__(x, "x", "1/2", Fraction)
So, for example, a Math library can create the feature:
@Math
x: Fraction = 1/2
And x is:
Fraction(1, 2)
Yes, you can do:
x = Fraction("1/2")
...today. I get that. But it's not as if this Math example is the ONLY thing it allows you to do. You also can easily avoid repeating things and making mistakes:
@namedtuple_factory Point = "x y"
I'm sure there are many other things I haven't thought of.
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler