(original) (raw)
On Tue, Jun 5, 2012 at 12:42 PM, Terry Reedy <tjreedy@udel.edu> wrote:
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.
On 6/5/2012 8:09 AM, nick.coghlan wrote:
� Add PEP 422: Dynamic Class Decorators
+Iterating over decorator entries in reverse order
+-------------------------------------------------
+
+This order was chosen to match the layout of lexical decorators when
+converted to ordinary function calls. Just as the following are equivalent::
+
\+ � �@deco2
\+ � �@deco1
\+ � �class C:
\+ � � � �pass
+
\+ � �class C:
\+ � � � �pass
\+ � �C = deco2(deco1(C))
+
+So too will the following be roughly equivalent (aside from inheritance)::
+
\+ � �class C:
\+ � � � �\_\_decorators\_\_ = \[deco2, deco1\]
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 list\_iterator 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.