[Python-Dev] FW: [Python-checkins] python/nondist/peps pep-0318.txt, 1.25, 1.26

List some possible reasons why arriving at consensus about decorators has been so hard (or impossible) to achieve
Thanks. I think that was an important contribution to the discussion. At this point, looking at the meta-discussion is likely to best way to help cut through the current morass. +There is no one clear reason why this should be so, but a +few problems seem to be most problematic. A possible social issue is that decorators can be used in a tremendous variety of ways, each of which is only needed or appreciated by small, disjoint groups of users. For instance, applications to ctypes have unique needs that not understood or shared by others. Some users want to use decorators for metaclass magic that scares the socks off of the rest.
+ Almost everyone agrees that decorating/transforming a function at + the end of its definition is suboptimal.
One other point of agreement is that no one like having to write the function name three times: def f(): ... f = deco(f)
+* Syntactic constraints.
There is an existing (though clumsy) syntax. Most of the proposals are less flexible but more elegant. This trade-off has created much more consternation than if there were no existing ways to apply decorations. +* Overall unfamiliarity with the concept. For people who have a + passing acquaintance with algebra (or even basic arithmetic) or have + used at least one other programming language, much of Python is + intuitive. Very few people will have had any experience with the + decorator concept before encountering it in Python. There's just no + strong preexisting meme that captures the concept. My take on this one is that there are some existing memes from C# and Java and that in the future they will be more widely known. However, there are not good existing, thought-out concepts of what exactly decorators should do in terms of preserving docstrings, attributes, using parameters, etc. Most have only a single application in mind and the full implications (and possible applications) of a given syntax are shrouded in the mists of the future. Like metaclasses, everyone knew they were powerful when they were put in, but no one knew how they would be used or whether they were necessary. In fact, two versions later, we still don't know those answers. Raymond

At 06:24 PM 8/24/04 -0400, Raymond Hettinger wrote:
The people who've been using metaclasses since Python 1.5 (including e.g., the Zope developers) would probably disagree. (Metaclasses got an upgrade in capabilities due to type/class unification, plus a more convenient syntax in 2.2, but they were around long before that.) Similarly, there are plenty of "pyoneers" with use cases today for decorators, and they know how they're being used today, and that an improved syntax is necessary. I'd point to the fact that there has been *very* little argument among decorator proponents regarding the desired semantics, as an indication that we *do* know what capabilities are necessary and/or desirable. (By decorator proponents, I mean people who have developed and use their own decorators, who have spoken in favor of having PEP 318 implemented for 2.4. That is, people interested enough in the functionality to have used the current syntax to get them.)

Thomas Heller wrote:
I would suggest we don't know the practical range of application yet. It is clear that some black magicians are happy, but metaclasses are not yet as well understood as list comprehensions in the sense of, "this is when you use them; this is an abuse." Metaclasses are more structural and less linguistic; such things take longer to absorb as design structure elements. This is all by way of saying, "nope, he has a point." -- Scott David Daniels Scott.Daniels@Acm.Org

At 06:24 PM 8/24/04 -0400, Raymond Hettinger wrote:
The people who've been using metaclasses since Python 1.5 (including e.g., the Zope developers) would probably disagree. (Metaclasses got an upgrade in capabilities due to type/class unification, plus a more convenient syntax in 2.2, but they were around long before that.) Similarly, there are plenty of "pyoneers" with use cases today for decorators, and they know how they're being used today, and that an improved syntax is necessary. I'd point to the fact that there has been *very* little argument among decorator proponents regarding the desired semantics, as an indication that we *do* know what capabilities are necessary and/or desirable. (By decorator proponents, I mean people who have developed and use their own decorators, who have spoken in favor of having PEP 318 implemented for 2.4. That is, people interested enough in the functionality to have used the current syntax to get them.)

Thomas Heller wrote:
I would suggest we don't know the practical range of application yet. It is clear that some black magicians are happy, but metaclasses are not yet as well understood as list comprehensions in the sense of, "this is when you use them; this is an abuse." Metaclasses are more structural and less linguistic; such things take longer to absorb as design structure elements. This is all by way of saying, "nope, he has a point." -- Scott David Daniels Scott.Daniels@Acm.Org
participants (4)
-
Phillip J. Eby
-
Raymond Hettinger
-
Scott David Daniels
-
Thomas Heller