This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author abarry
Recipients Guido.van.Rossum, abarry, benjamin.peterson, berker.peksag, dirn, eric.araujo, eric.smith, eric.snow, gvanrossum, infinity0, james, ncoghlan, peyton
Date 2016-07-31.21:32:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1470000752.12.0.592837176995.issue19660@psf.upfronthosting.co.za>
In-reply-to
Content
TL;DR - Use case is dynamic decorators. Not all of the syntax would make sense, see below.

The main benefit of this feature would be for dynamic decorators (as was evidenced from others in this issue). In a project I contribute to, we use dynamic decorators to set a function as being a command, and we use the object (a wrapper around the function) directly, so we need a bit more boilerplate around the place.

Ultimately, we would definitely use such a feature (just the '@spam().eggs()' part; we'd have no use for the other ones) , but we probably won't notice its absence either; we've worked around it for years, after all.

As far as readability goes, I think allowing only the '@spam().eggs()' version would actually improve readability quite a bit, by reducing the need to separate the decorator assignment in two (or more) parts. I can see the desire to have a '@spam[eggs]' kind of syntax though, again for the dynamic decorators case.

I see no reason to allow creating lambdas or conditional expressions inside decorators expressions. If anything, that'll encourage anti-patterns, whereas e.g. '@spam(value=eggs)' would be more readable, and would let the decorator decide what it wants to do with the value.

And if your decorator can be expressed as a lambda, why don't you put that in/below the function? Surely it's less work than writing the lambda everytime ;)
History
Date User Action Args
2016-07-31 21:32:32abarrysetrecipients: + abarry, gvanrossum, ncoghlan, eric.smith, benjamin.peterson, eric.araujo, infinity0, eric.snow, berker.peksag, dirn, Guido.van.Rossum, james, peyton
2016-07-31 21:32:32abarrysetmessageid: <1470000752.12.0.592837176995.issue19660@psf.upfronthosting.co.za>
2016-07-31 21:32:32abarrylinkissue19660 messages
2016-07-31 21:32:31abarrycreate