PEP 614: Relaxing Grammar Restrictions On Decorators
I have just pushed the first draft of PEP 614: https://www.python.org/dev/peps/pep-0614/ It proposes that the current decorator syntax restrictions be relaxed to allow any valid expression. Please let me know what you think! Brandt
On 2/11/2020 10:58 AM, Brandt Bucher wrote:
I have just pushed the first draft of PEP 614:
https://www.python.org/dev/peps/pep-0614/
It proposes that the current decorator syntax restrictions be relaxed to allow any valid expression. Please let me know what you think!
I think it should start with a description of the current expression restrictions. It assumes the reader is familiar with them. Other than that, it seems okay to me. Eric
restrictions. It assumes the reader is familiar with them.
Yes please — it does note at the end that many people aren’t currently aware of the restriction(s). Count me in that group. I have always presumed that any expression that yielded a callable would work. But the PEP is quite clear otherwise - thanks! -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
there are no known examples of binary matrix multiplication results which may used as decorators.
This is misleading. There are multiple libraries on PyPI that wrap up functions to add additional operators and methods including @ for compose. (It’s also been proposed and rejected repeatedly for the builtin type, going back to the rejected PEPs in 2000 that originally proposed a matmul operator.) And composing two decorators isn’t binary matrix multiplication, but it is a use of the @ operator; and it gives you results which could be used as decorators. For example, if I have a logcall decorator that wraps its function with calls to logging.log that show when the function is entered and exited, and a daytime decorator that skips the function call if it’s nighttime, then logcall@daytime is a decorator which skips the function call if it’s nighttime but always logs either way, while daytime@logcall skips both. I don’t think that this is a practical problem. I don’t know how often people use these libraries to compose decorators, but even if it’s very frequent (which it probably isn’t), it wouldn’t look at all ambiguous to a human to mix with this feature, because the following end up meaning the same thing: @daytime@logcall def cheese(…): @daytime @logcall def cheese(…): Try it with composing decorators that take arguments and return the actual decorator, etc.; it’s never ambiguous or misleading to the reader. So, I think the PEP can dismiss the problem, just not in the way it currently does.
Thanks for bringing this up; I didn't know that there were any libraries using @ like this. I've spent some time searching on Google, PyPI, and GitHub, though, and I can't find anything that advertise this functionality. Do you have the names of any of them handy, so I could perhaps add a simple, real-world example of the newly valid usage? Brandt
It doesn't look like it's popular or used much, but i spent a minute or two looking via github search and found this library that uses @ for currying: https://github.com/kanales/spycy/blob/master/spycy/__init__.py#L87 On Tue, Feb 11, 2020 at 11:26 AM Brandt Bucher <brandtbucher@gmail.com> wrote:
Thanks for bringing this up; I didn't know that there were any libraries using @ like this.
I've spent some time searching on Google, PyPI, and GitHub, though, and I can't find anything that advertise this functionality. Do you have the names of any of them handy, so I could perhaps add a simple, real-world example of the newly valid usage?
Brandt _______________________________________________ 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/AU62SR... Code of Conduct: http://python.org/psf/codeofconduct/
This github search seems to return more direct hits of this usage pattern: https://github.com/search?l=Python&q=__matmul__+curry&type=Code On Tue, Feb 11, 2020 at 11:38 AM Nathan <nathan.goldbaum@gmail.com> wrote:
It doesn't look like it's popular or used much, but i spent a minute or two looking via github search and found this library that uses @ for currying:
https://github.com/kanales/spycy/blob/master/spycy/__init__.py#L87
On Tue, Feb 11, 2020 at 11:26 AM Brandt Bucher <brandtbucher@gmail.com> wrote:
Thanks for bringing this up; I didn't know that there were any libraries using @ like this.
I've spent some time searching on Google, PyPI, and GitHub, though, and I can't find anything that advertise this functionality. Do you have the names of any of them handy, so I could perhaps add a simple, real-world example of the newly valid usage?
Brandt _______________________________________________ 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/AU62SR... Code of Conduct: http://python.org/psf/codeofconduct/
On Feb 11, 2020, at 10:27, Brandt Bucher <brandtbucher@gmail.com> wrote:
Thanks for bringing this up; I didn't know that there were any libraries using @ like this.
I've spent some time searching on Google, PyPI, and GitHub, though, and I can't find anything that advertise this functionality. Do you have the names of any of them handy, so I could perhaps add a simple, real-world example of the newly valid usage?
fn-compose looks like the right thing, and, even though I’ve never heard of it, it was the first thing to come up in a PyPI search (once I figured out how to skip over all the docker-compose helpers…). I don’t know if anyone’s using it in real life code, but it should be fine to use as an example to show that even with such libraries there’s no ambiguity.
i spent a minute or two looking via github search and found this library that uses @ for currying...
fn-compose looks like the right thing...
Hm, exploring these a bit more, both libraries are unstable, haven't been updated in several years, and have no watchers, stars, or dependents on GitHub. I think it would be inappropriate to use either of these as a "real world" example, but I still am considering rewording the section to acknowledge that this design pattern does seems to exist in some form.
Honestly I don't see why the PEP even needs to bring up the matrix multiply operator. There is no ambiguity, and there is no backwards compatibility issue. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
Honestly I don't see why the PEP even needs to bring up the matrix multiply operator.
I was on the fence when writing this draft anyways. Given that the feedback ranges from "this problem should be dismissed differently" to "this isn't a problem", I think I'll just go ahead and drop it. :)
Thanks for all of your feedback. I've updated the PEP to explain the current restrictions up front, and removed the section covering the interaction between decorators and binary @ operations. My overall impression is that there were no issues with the substance of the PEP itself, just its presentation. If there are no major objections raised in the next few days, I'll bring the discussion over to Python-Dev. Brandt
participants (6)
-
Andrew Barnert -
Brandt Bucher -
Christopher Barker -
Eric V. Smith -
Guido van Rossum -
Nathan