Terry J. Reedy added the comment:
Based on my reading of the pydev discussion, the doc correctly describes
the design intent. If there is any bug, it is in the optimization of
skipping the apparently redundant first name binding. I presume the
thinking was that since the decorator gets the fun
Benjamin Peterson added the comment:
On Wed, Dec 31, 2008 at 3:17 PM, Lenard Lindstrom
wrote:
>
> However, the issue is one of definitions. Is the phrase "merely
> syntactic sugar" misleading? In this case it makes promises that may not
> be kept.
It's not misleading because in 99.99% of all c
Lenard Lindstrom added the comment:
The claim "merely" syntactic sugar implies that the inverse is also
true, the decorator expression:
@do_something
def foo():
can be replaced it with:
def foo():
foo = do_something(foo)
This is guaranteed if do_something is purely function
Benjamin Peterson added the comment:
It is possible to "desugar" the exact behavior by creating the function
ones self.
Regardless, the usefulness this behavior is limited because it relys on
the decorator being in the same module as the function. It is also
fragile for nested functions.
-
Lenard Lindstrom added the comment:
It is distinct behavior. Without a decorator a new function is
immediately assigned to the identifier. Any previous reference is lost.
A decorator postpones assignment until the decorator returns. That
allows the decorator to access the previous object. I don'
Guilherme Polo added the comment:
Your example doesn't disprove the "merely syntactic sugar" found in the
documentation about the decorator syntax.
The results you are getting are based on when the decorator is applied.
--
nosy: +gpolo
resolution: -> invalid
status: open -> closed
__
New submission from Lenard Lindstrom :
http://www.python.org/doc/2.6/glossary.html
The decorator entry in the Python 2.6 documentation incorrectly
describes a decorator as "merely syntactic sugar". It is not, as this
example shows:
>>> def decorator(f):
f.prev = globals()[f.__name__]
