>
> I am confused why you are okay with
> @decorator var: bool
>
> but not
>
> @decorator var
>
> Yes, a bare name is currently an error while just a name and a type hint
> is valid,
> but the latter doesn't bind anything to the name, and using that
> identifier is still
> a NameError. So a decorator presumably can't return a value for either (or
> it
> could, but it would always be dropped). What could it do with a name and a
> type hint that is so much better than just a name?
>
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:
I like this:
>
> @typing.TypeVar
> T = str, bytes
>
>
> about a million times better than:
>
> @typing.TypeVar T = str, bytes
>
>
> Because the latter feels (to me) too similar for comfort to this:
>
> int foo = 3
>
>
> 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:
>
> @acl(READ, WRITE)
> @constraint(10 < _ < 100)
> @not_null
> @indexed
> @depends_on(whatever)
> @inject
> first_name: str
>
>
> Whereas the multiline variant does.
>
And regarding your proposal to relax the newline requirement on
function/class decorators:
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 would admittedly resolve the asymmetry between the proposed
single-line variable decorator syntax and current decorators, but
personally I just *really* don't like it. The only benefit is saving a
line, but it comes at (in my opinion, your mileage may vary) a huge cost to
legibility, and it goes against the zen:
There should be one-- and preferably only one --obvious way to do it.
And it's just something that has (almost) no precedent in python (aside
from `async def`). It has the feel of something like:
public static final native abstract void SomeMethod() {...}
I'm imagining a future of reading python code like:
@too @many("!") @decorators @on("a", "single", "line") def foo(...):
And it makes me unhappy :(
So going back to your original point of why I'm okay with decorating a bare
type-hint, like:
@decorate
foo: int
But not
@decorate
foo
The reason is simply that if you take the decorator away the first one is
legal, and the second one will raise `NameError`. I'm happy to decorate a
statement that is valid on its own, but I'm against the idea of
special-casing decorator syntax so that it can decorate otherwise-invalid
statements.
And I do think that there are legitimate uses for decorating a bare
type-hint, since it does actually contain useful information the decorator
might want to capture (for example, in one of its own instance attributes
if the decorator is an object rather than a function, which it would have
to be in order to implement __decoration_call__). You're right in that it
wouldn't be able to return anything since no assignment is taking place,
but there are still potential use-cases for it.
I'll concede that there are also use-cases for decorating a completely
naked name, but none of the ones I've seen so far seem to me compelling
enough to break the rules like this.
On Thu, May 27, 2021 at 8:43 PM Ricky Teachey <ri...@teachey.org> wrote:
> Whoops, replying all this time.
>
> On Thu, May 27, 2021 at 2:32 PM micro codery <ucod...@gmail.com> wrote:
>
>>
>>
>> On Thu, May 27, 2021 at 10:40 AM Matt del Valle <matthew...@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 <brenb...@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 <brenb...@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-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/JNJNBYMNH43TX575WWB6R726C6V2CRXW/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> _______________________________________________
> 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/EUUQXV7MP6QT5YOEFARKGGB4F46XYQAE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
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/3RZ5N4ACMNYAHS4C2PD3SNZARUFFVDWD/
Code of Conduct: http://python.org/psf/codeofconduct/
