Hi all, decorators are a very powerful feature in python, but it's syntax is strangely restrictive. decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE for 99% of cases this is not a hindrance, but sometimes we'd rather be able to use full expression syntax. consider the following example (using PyQt): # make 10 buttons buttons = [QPushButton(f'button #{i}') for i in range(10)] # for now we only want to bind an event to the first button @buttons[0].clicked.connect def foo(): ... # do whatever in cases such as this, it would be useful to have any expression acceptable as a decorator. In addition to other use cases such as chained function calling (@buttons_dict.get("foo"). clicked.connect), the restrictiveness of the decorator syntax seems like a strange oversight. Arbitrary expressions are already allowed in decorator lines as arguments, so allowing them as the called decorator shouldn't be too difficult. Any thoughts on this?
I’ve always resisted changing this, but it keeps coming up, and in other cases we don’t restrict the grammar (except when there are real ambiguities). So maybe the SC can accept a PRP for this? On Mon, Feb 3, 2020 at 15:47 Ben Avrahami <avrahami.ben@gmail.com> wrote:
Hi all, decorators are a very powerful feature in python, but it's syntax is strangely restrictive.
decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE
for 99% of cases this is not a hindrance, but sometimes we'd rather be able to use full expression syntax. consider the following example (using PyQt):
# make 10 buttons buttons = [QPushButton(f'button #{i}') for i in range(10)] # for now we only want to bind an event to the first button @buttons[0].clicked.connect def foo(): ... # do whatever
in cases such as this, it would be useful to have any expression acceptable as a decorator.
In addition to other use cases such as chained function calling (@buttons_dict.get("foo"). clicked.connect), the restrictiveness of the decorator syntax seems like a strange oversight. Arbitrary expressions are already allowed in decorator lines as arguments, so allowing them as the called decorator shouldn't be too difficult.
Any thoughts on this? _______________________________________________ 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/WOWD4P... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido (mobile)
Thanks for the reply! Is this really deserving of a PEP? It's such a minor change in the language, can't it be resolved as a python issue? Out of curiosity, why have you always resisted changing this? On Tue, Feb 4, 2020 at 2:08 AM Guido van Rossum <guido@python.org> wrote:
I’ve always resisted changing this, but it keeps coming up, and in other cases we don’t restrict the grammar (except when there are real ambiguities). So maybe the SC can accept a PRP for this?
On Mon, Feb 3, 2020 at 15:47 Ben Avrahami <avrahami.ben@gmail.com> wrote:
Hi all, decorators are a very powerful feature in python, but it's syntax is strangely restrictive.
decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE
for 99% of cases this is not a hindrance, but sometimes we'd rather be able to use full expression syntax. consider the following example (using PyQt):
# make 10 buttons buttons = [QPushButton(f'button #{i}') for i in range(10)] # for now we only want to bind an event to the first button @buttons[0].clicked.connect def foo(): ... # do whatever
in cases such as this, it would be useful to have any expression acceptable as a decorator.
In addition to other use cases such as chained function calling (@buttons_dict.get("foo"). clicked.connect), the restrictiveness of the decorator syntax seems like a strange oversight. Arbitrary expressions are already allowed in decorator lines as arguments, so allowing them as the called decorator shouldn't be too difficult.
Any thoughts on this? _______________________________________________ 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/WOWD4P... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido (mobile)
On 2/4/2020 4:07 AM, Ben Avrahami wrote:
Thanks for the reply! Is this really deserving of a PEP? It's such a minor change in the language, can't it be resolved as a python issue?
Out of curiosity, why have you always resisted changing this?
PEP-318 references https://mail.python.org/pipermail/python-dev/2004-August/046711.html. And there have been a number of other discussions about it over the years. I think mostly on python-ideas, if you want to go searching for them. Eric
Yes, it requires a PEP -- note that I am not longer the decider, and none of the core devs will want to take responsibility for such a change of heart, so it has to go to the Steering Council. And the easiest way for that is a PEP. On Tue, Feb 4, 2020 at 02:04 Eric V. Smith <eric@trueblade.com> wrote:
On 2/4/2020 4:07 AM, Ben Avrahami wrote:
Thanks for the reply! Is this really deserving of a PEP? It's such a minor change in the language, can't it be resolved as a python issue?
Out of curiosity, why have you always resisted changing this?
PEP-318 references https://mail.python.org/pipermail/python-dev/2004-August/046711.html. And there have been a number of other discussions about it over the years. I think mostly on python-ideas, if you want to go searching for them.
Eric _______________________________________________ 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/HNNHXV... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido (mobile)
This has struck me as unnecessarily restrictive ever since I first bumped up against it. I think that the reoccurring threads on this topic, the availability of awful (and inefficient) hacks to circumvent this restriction, and the presentation here of a legitimate use case are all solid arguments in favor of relaxing it.
So maybe the SC can accept a PRP for this?
I'd be willing to draft a PEP and accompanying implementation if there's a core dev to sponsor it.
why not add an identity function to the builtins? @noop(buttons[0].clicked.connect) def foo(): ... # do whatever On 2020-02-03 9:08 p.m., Guido van Rossum wrote:
I’ve always resisted changing this, but it keeps coming up, and in other cases we don’t restrict the grammar (except when there are real ambiguities). So maybe the SC can accept a PRP for this?
On Mon, Feb 3, 2020 at 15:47 Ben Avrahami <avrahami.ben@gmail.com <mailto:avrahami.ben@gmail.com>> wrote:
Hi all, decorators are a very powerful feature in python, but it's syntax is strangely restrictive.
decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE
for 99% of cases this is not a hindrance, but sometimes we'd rather be able to use full expression syntax. consider the following example (using PyQt):
# make 10 buttons buttons = [QPushButton(f'button #{i}') for i in range(10)] # for now we only want to bind an event to the first button @buttons[0].clicked.connect def foo(): ... # do whatever
in cases such as this, it would be useful to have any expression acceptable as a decorator.
In addition to other use cases such as chained function calling (@buttons_dict.get("foo"). clicked.connect), the restrictiveness of the decorator syntax seems like a strange oversight. Arbitrary expressions are already allowed in decorator lines as arguments, so allowing them as the called decorator shouldn't be too difficult.
Any thoughts on this? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org <mailto:python-ideas@python.org> To unsubscribe send an email to python-ideas-leave@python.org <mailto: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/WOWD4P... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido (mobile)
_______________________________________________ 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/FKE7ZF... Code of Conduct: http://python.org/psf/codeofconduct/
I'll sponsor. On Tue, Feb 4, 2020 at 9:43 AM Brandt Bucher <brandtbucher@gmail.com> wrote:
This has struck me as unnecessarily restrictive ever since I first bumped up against it. I think that the reoccurring threads on this topic, the availability of awful (and inefficient) hacks to circumvent this restriction, and the presentation here of a legitimate use case are all solid arguments in favor of relaxing it.
So maybe the SC can accept a PRP for this?
I'd be willing to draft a PEP and accompanying implementation if there's a core dev to sponsor it. _______________________________________________ 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/UDU3YP... Code of Conduct: http://python.org/psf/codeofconduct/
-- --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...>
Great! I'll begin work on this soon and reach out to you when I have something. Thanks, Ben, for bringing this up.
účastníci (5)
-
Ben Avrahami -
Brandt Bucher -
Eric V. Smith -
Guido van Rossum -
Soni L.