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