Confused with methods

Diez B. Roggisch deetsNOSPAM at web.de
Mon Feb 7 06:59:22 EST 2005


> HOWEVER, what I ask is WHY don't we set the tp_descr_get of
> the boundmethod object to be the same as the func_descr_get???
> Or WHY do they *have* to differ in this specific part?
> 
> I quickly looked at the source of python and it seems that a
> one-liner would be enough to enable this. So it's not that it
> would be hard to implement it, or inefficient.
> 
> A bound method would *still* be a boundmethod.
> We could additionally have:
> 
>  >>>type(x)
>   <boundmethod of <boundmethod of <boundmethod of....<__main__.A
> instance at 0x>>>
> 
> If there a good reason that the __get__ of a boundmethod does not
> create a new boundmethod wrapper over the first boundmethod?

I already gave you the good reason:

class A:
   def callback(self, arg):
       print self, arg

def callback(arg):
    print arg

class DoSomethingWithCallback:
    def __init__(self, cb):
        self.cb = cb

    def run(self):
        for i in xrange(100):
             self.cb(i)

u = DoSomethingWithCallback(A().callback)
v = DoSomethingWithCallback(callback)

# would crash if your suggestion worked
u.run()
v.run()


Bound methods aren't a general purpose currying scheme - they exist sorely
for the OO-style implicit first argument. That they exist at all is a great
difference to e.g. C++, where you can't pass callbacks around that are
instance methods. 

If you are after currying - look at the cookbook, there are recipes for
that.
-- 
Regards,

Diez B. Roggisch



More information about the Python-list mailing list