Distinguishing between functions and methods in a decorator.

B

Berteun Damman

Hello,

I was wondering a bit about the differences between methods and
functions. I have the following:

def wrap(arg):
print type(arg)
return arg

class C:
def f():
pass

@wrap
def g():
pass

def h():
pass

print type(C.f)
print type(h)

Which gives the following output:
<type 'function'>
<type 'instancemethod'>
<type 'function'>

The first line is caused by the 'wrap' function of course. I had
expected the first line to be 'instancemethod' too. So, I would guess,
these methods of C are first created as functions, and only then become
methods after they are 'attached' to some classobj. (You can do that
yourself of course, by saying, for example, C.h = h, then the type of
C.h is 'instancemethod' too.)

Why does the wrapping occur before the function is 'made' into an
instancemethod?

The reason for asking is that I would like to differentiate between
wrapping a function and an instancemethod, because in the latter case,
the first parameter will be the implicit 'self', which I would like to
ignore. However, when the wrapping occurs, the method still looks like
a function.

Berteun
 
D

Diez B. Roggisch

Berteun said:
Hello,

I was wondering a bit about the differences between methods and
functions. I have the following:

def wrap(arg):
print type(arg)
return arg

class C:
def f():
pass

@wrap
def g():
pass

def h():
pass

print type(C.f)
print type(h)

Which gives the following output:
<type 'function'>
<type 'instancemethod'>
<type 'function'>

The first line is caused by the 'wrap' function of course. I had
expected the first line to be 'instancemethod' too. So, I would guess,
these methods of C are first created as functions, and only then become
methods after they are 'attached' to some classobj. (You can do that
yourself of course, by saying, for example, C.h = h, then the type of
C.h is 'instancemethod' too.)

Why does the wrapping occur before the function is 'made' into an
instancemethod?

Because a decorator could choose to return any function-object as it likes,
see this example:

def bar(self):
print "bar"

def makebar(f):
return bar

class Foo(object):

@makebar
def baz(self):
pass

foo = Foo()
foo.baz()

So you can't decide if a function is an instancemethod until the very last
moment.

Diez
 
D

Diez B. Roggisch

Berteun said:
Hello,

I was wondering a bit about the differences between methods and
functions. I have the following:

def wrap(arg):
print type(arg)
return arg

class C:
def f():
pass

@wrap
def g():
pass

def h():
pass

print type(C.f)
print type(h)

Which gives the following output:
<type 'function'>
<type 'instancemethod'>
<type 'function'>

The first line is caused by the 'wrap' function of course. I had
expected the first line to be 'instancemethod' too. So, I would guess,
these methods of C are first created as functions, and only then become
methods after they are 'attached' to some classobj. (You can do that
yourself of course, by saying, for example, C.h = h, then the type of
C.h is 'instancemethod' too.)

Why does the wrapping occur before the function is 'made' into an
instancemethod?

The reason for asking is that I would like to differentiate between
wrapping a function and an instancemethod, because in the latter case,
the first parameter will be the implicit 'self', which I would like to
ignore. However, when the wrapping occurs, the method still looks like
a function.

Can you provide an example of what you are actually after? The
descriptor-protocol might come to use there.

Diez
 
A

Arnaud Delobelle

Hello,

I was wondering a bit about the differences between methods and
functions. I have the following:

def wrap(arg):
print type(arg)
return arg

class C:
def f():
pass

@wrap
def g():
pass

def h():
pass

print type(C.f)
print type(h)

Which gives the following output:
<type 'function'>
<type 'instancemethod'>
<type 'function'>

The first line is caused by the 'wrap' function of course. I had
expected the first line to be 'instancemethod' too. So, I would guess,
these methods of C are first created as functions, and only then become
methods after they are 'attached' to some classobj. (You can do that
yourself of course, by saying, for example, C.h = h, then the type of
C.h is 'instancemethod' too.)

Why does the wrapping occur before the function is 'made' into an
instancemethod?

Consider this:
.... def bar(self): pass
....

It shows that when Foo.bar is evaluated, a new instancemethod object
is created and that the 'bar' in the dictionary of 'Foo' is forever a
plain function object. In fact, Foo.bar is equivalent to
Foo.__dict__['bar'].__get__(None, Foo):
Foo.__dict__['bar'].__get__(None, Foo)

For more details you can read http://users.rcn.com/python/download/Descriptor.htm.
The reason for asking is that I would like to differentiate between
wrapping a function and an instancemethod, because in the latter case,
the first parameter will be the implicit 'self', which I would like to
ignore. However, when the wrapping occurs, the method still looks like
a function.

Berteun

I think you're better off having a 'wrap' decorator for functions and
a 'wrapmethod' decorator for methods.

HTH
 
B

Berteun Damman

Can you provide an example of what you are actually after? The
descriptor-protocol might come to use there.

Thanks for your responses. I have read the Descriptor protocol how-to,
which clarifies method access on objects, and indeed provides a
solution.

My idea was to have some @pre and @post decorators, which check some
pre-conditions. When applied to a method, the first parameter will be an
instance-object, and I wondered whether I could detect whether the
precondition cared about it or not.

So,
@pre(lambda x: x > 0)
def method(self, x):

Here the precondition function does not use 'self', yet it will of
course be provided in a call, so I need to strip it. In case of a @pre
applied to a function, this does not happen. I'm not sure whether this
magic is such a nice solution though.

However, the descriptor protocol indeed is what I need. If I provide the
__get__ method, this will be invoked instead of __call__, which will
happen on functions (or methods, if __get__ is not provided). This way
the two are clearly distinguishable, and I need not worry about
heuristics (such as, is the first parameter called 'self' or something).

Besides, it taught me a bit more about the inner design of Python. :)

Thanks,

Berteun
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top