[Python-Dev] [Python-checkins] peps: Add PEP 422: Dynamic Class Decorators (original) (raw)
PJ Eby pje at telecommunity.com
Wed Jun 6 01:06:38 CEST 2012
- Previous message: [Python-Dev] [Python-checkins] peps: Add PEP 422: Dynamic Class Decorators
- Next message: [Python-Dev] [Python-checkins] peps: Add PEP 422: Dynamic Class Decorators
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Jun 5, 2012 at 5:31 PM, Terry Reedy <tjreedy at udel.edu> wrote:
On 6/5/2012 2:26 PM, PJ Eby wrote:
On Tue, Jun 5, 2012 at 12:42 PM, Terry Reedy <tjreedy at udel.edu_ _<mailto:tjreedy at udel.edu>> wrote:
I think you should just store the decorators in the correct order of use + decorators = [deco1, deco2] and avoid the nonsense (time-waste) of making an indirect copy via listiterator and reversing it each time the attribute is used.
It's for symmetry and straightforward translation with stacked decorators, i.e. between: @deco1 @deco2 [declaration] and decorators = [deco1, deco2] Doing it the other way now means a different order for people to remember; there should be One Obvious Order for decorators, and the one we have now is it. You and I have different ideas of 'obvious' in this context.
To be clearer: I've written other APIs which take multiple decorators, or things like decorators that just happen to be a pipeline of functions to be applied, and every time the question of what order to put the API in, I always put them in this order because then in order to remember what the order was, I just have to think of decorators. This is easier than trying to remember which APIs use decorator order, and which ones use reverse decorator order.
So, even though in itself there is no good reason for one order over the other, consistency wins because less thinking. At the least, if they're not going to be in decorator order, the member shouldn't be called "decorators". ;-)
But since you will use this and and me probably not, let your idea rule.
For my motivating use case, I actually don't care about the order within a class very much. Nick's proposal will actually be the reverse of the application order used by my in-class decorators, but I can easily work around that. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120605/b5e1dbbe/attachment.html>
- Previous message: [Python-Dev] [Python-checkins] peps: Add PEP 422: Dynamic Class Decorators
- Next message: [Python-Dev] [Python-checkins] peps: Add PEP 422: Dynamic Class Decorators
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]