Whoops, replying all this time. On Thu, May 27, 2021 at 2:32 PM micro codery <ucodery@gmail.com> wrote:
On Thu, May 27, 2021 at 10:40 AM Matt del Valle <matthewgdv@gmail.com> wrote:
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 Thu, May 27, 2021 at 3:03 PM Brendan Barnwell <brenbarn@brenbarn.net> wrote:
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): self.name = name def __get__(self, instance, owner): if instance is None: pass print(f"I am { owner.__name__}.{self.name}") 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 On Thu, May 27, 2021 at 3:03 PM Brendan Barnwell <brenbarn@brenbarn.net> wrote:
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 _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/JNJNBY... Code of Conduct: http://python.org/psf/codeofconduct/