En Tue, 29 Jul 2008 08:45:02 -0300, Themis Bourdenas <bourdenas@gmai l.com>
escribi�:
In a very strict sense, I'd say that all those references to "method
decorators" are wrong - because those "def" statements inside a "class"
statement define functions, not methods. In that sense almost every Python
programmer is wrong too: in this example
class X:
@decorator
def foo(self): pass
most (if not all) people would refer to "foo" as "the foo method in class
X" - even if foo is really a function, not a method.
So a less restrictive meaning is usually adopted - and we all consider
"foo" a method, and we're all happy... except in your case, when you just
hit a point where the distinction is relevant.
Perhaps a more careful wording in the PEP would help in those corner cases.
>class
>>
>"the class inside decorate"? What do you mean? The type of the x
>instance
>in an x.foo() call? That should be determined inside the wrapped
>function
>-when it is actually called-.
>>
>Yes, what I was hoping is that it might be possible to get the name of
>the
class the function is eventually is going to be bound to, but I guess
that's
not very likely to be possible. I wanted the name well before the
function
is called, actually even before an instance of the class is created.
No, I think it's not possible - not using a function decorator, because
when it is applied, the class doesn't exist yet.
You might use a metaclass (or a class decorator, available on 2.6 and
3.0); iterate over the dictionary of the class about to be created and
process their functions in any way you like.
Mmm... methods are ephemeral objects, once the call is completed, the
method usually gets destroyed, so I don't think a true "method decorator"
would be very useful.
If you really want to customize a method, since they are created by the
function type's __get__, a crazy idea would be to inherit from the
function type and return something different in its __get__ - but I've
never done something like that and don't even know if it's possible at
all...
--
Gabriel Genellina
escribi�:
On Mon, Jul 28, 2008 at 11:12 AM, Gabriel Genellina
<gagsl-py2@yahoo.com.a r>wrote:
>
>
well a few occurrences of it can be found in PEP 318
<gagsl-py2@yahoo.com.a r>wrote:
>
>En Sun, 27 Jul 2008 15:26:39 -0300, Themistoklis Bourdenas <
>tbourden@doc.ic .ac.ukescribió:
>>
>but
>decorate
>functions
>me.
>>
>Where have you found it? I've always seen the expression "function
>decorator" or just "decorator" , not "method decorator".
>tbourden@doc.ic .ac.ukescribió:
>>
On a related note, as the actual instance method of myclass is not foo
decorate(foo), why are they called method decorators? This does not
methods, they decorate functions and eventually the decorated
become methods. The name method decorator sounds a bit misleading to
>>
>Where have you found it? I've always seen the expression "function
>decorator" or just "decorator" , not "method decorator".
well a few occurrences of it can be found in PEP 318
decorators" are wrong - because those "def" statements inside a "class"
statement define functions, not methods. In that sense almost every Python
programmer is wrong too: in this example
class X:
@decorator
def foo(self): pass
most (if not all) people would refer to "foo" as "the foo method in class
X" - even if foo is really a function, not a method.
So a less restrictive meaning is usually adopted - and we all consider
"foo" a method, and we're all happy... except in your case, when you just
hit a point where the distinction is relevant.
Perhaps a more careful wording in the PEP would help in those corner cases.
So returning to my original question is there any way I can get the
inside decorate()? I guess there is not, but just asking to make sure.
>"the class inside decorate"? What do you mean? The type of the x
>instance
>in an x.foo() call? That should be determined inside the wrapped
>function
>-when it is actually called-.
>>
>Yes, what I was hoping is that it might be possible to get the name of
>the
that's
not very likely to be possible. I wanted the name well before the
function
is called, actually even before an instance of the class is created.
when it is applied, the class doesn't exist yet.
You might use a metaclass (or a class decorator, available on 2.6 and
3.0); iterate over the dictionary of the class about to be created and
process their functions in any way you like.
Anyway,
I 've solved my problem with other means. Just out curiosity though, has
there been any talk about actual method decorators? I guess you can work
around them with the introduction of class decorators or even now with
meta-classes, but you have to wrap methods manually with no syntactic
sugar.
I 've solved my problem with other means. Just out curiosity though, has
there been any talk about actual method decorators? I guess you can work
around them with the introduction of class decorators or even now with
meta-classes, but you have to wrap methods manually with no syntactic
sugar.
method usually gets destroyed, so I don't think a true "method decorator"
would be very useful.
If you really want to customize a method, since they are created by the
function type's __get__, a crazy idea would be to inherit from the
function type and return something different in its __get__ - but I've
never done something like that and don't even know if it's possible at
all...
--
Gabriel Genellina