On Fri, Aug 26, 2011 at 2:30 PM, Sebastian Wiesner <lunary...@googlemail.com> wrote: > 2011/8/26 Lauro Moura <lauro.n...@openbossa.org>: >> On Fri, Aug 26, 2011 at 1:53 PM, Markus Hubig <mhu...@imko.de> wrote: >>> Hi @all, >>> in psep-0104 the use of the use of the decorator style @Property's is >>> documented like this: >>> class C(QObject): >>> >>> def __init__(self): >>> self._x = None >>> >>> xChanged = Signal() >>> >>> @Property(float, doc="I'm the 'x' property.", notify=xChanged) >>> def x(self): >>> return self._x >>> >>> @x.setter >>> def x(self, value): >>> self._x = value >>> >>> But in my tests I can't give the setter and getter the same name (x). >>> So in this example I had to name the setter eg. _x(self, value) to got >>> it Working ... got me a while to figure this out! Seems like a bug!? >>> >> >> @mydecorator >> def method(self): >> pass >> >> is equivalent to >> >> def method(self): >> pass >> method = mydecorator(method) > > These snippets are not completely equivalent. While they somehow have > similar semantics, there a subtle differences when it comes to name > binding. > > The second example actually binds "method" in the module namespace, > *before* the decorator is executed, but the first example does *not*. > In a definition with decorator syntax, the function is not created in > the module namespace, but in an entirely new namespace. The decorator > is evaluated in this new namespace, and only the *return value* of the > decorator is eventually bound in the module namespace. See language > reference [1] for further details. >
Yep, looking at an disassemble of a simple example there's this (subtle) difference. When the decorator is used only the result is assigned to the "method" name in the current namespace while the non-decorator version stores "method" twice. One for the original version and another for the decorated version. What do you mean by "the function is not created in the module namespace"? The docs states: "Decorator expressions are evaluated when the function is defined, in the scope that contains the function definition. ". > Thus, your assumption > >> So, your code is reassigning the 'x' name, overwriting the first one. > > is wrong. The name is not reassigned, because the second "def x(…)" > never binds to module namespace. Only the return value of "x.setter" > (which is the property decorator again) is bound in the module > namespace. > "...the return value of 'x.setter' is bound in the module namespace"... to the name "x", which means it is indeed overwritten in the class namespace. Remember that before @x.getter... there is aready a name "x" in the current scope. It would work as Markus asked only if x.setter() return the Property object itself ... which does not, and I don't think it should. It would break, for example, Qt properties where they take the form of "x" for getters and "setX" for setters. If the name "setX" is replaced by the Property object, calling myobj.setX(arg) would call Property.__call__(arg), which is already used to assign the getter function. -- Lauro Moura INdT - Instituto Nokia de Tecnologia _______________________________________________ PySide mailing list PySide@lists.pyside.org http://lists.pyside.org/listinfo/pyside
