Confused with methods

[Alex Martelli]

On 2005 Feb 07, at 22:15, jfj wrote:

> Alex Martelli wrote:
>> jfj <jfj at freemail.gr> wrote:
>>> Then, without looking at the previous code, one can say that "x" is a
>>> function which takes one argument.
>> One can say whatever one wishes, but saying it does not make it true.
>> One can say that x is a green frog, but that's false: x is a
>> boundmethod.
>> One can say that x is a function, but that's false: x is a 
>> boundmethod.
>> One can say that x is a spade, but that's false: x is a boundmethod.
>
> I understand that a function and a boundmethod are *different* things.
> For one a *boundmethod* has the attributes im_self, im_class, which
> a function does not have (a green frog neither). Thus they are not
> the same thing.

Great!  So, do *NOT* ``say that "x" is a function'', when you know that 
is false.

> 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?

Why we don't change boundmethods' binding behavior NOW is obvious -- 
can't break backwards compatibility.  If you're talking about Python 
3.0, which _will_ be allowed to break backwards compatibility when it 
comes, then I, personally, have no special objection to changing that 
binding behavior; a PEP may be necessary, of course, but it may also be 
possible to get the idea into the existing PEP 3000 by presenting a 
good case on python-dev (not here -- no decisions on Python's future 
are made here).

> 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

You looked too quickly.  Currently, PyMethod objects are used to 
implement both bound and unbound methods, and function 
instancemethod_descr_get (around line 2430 of classobject.c) has the 
logic to implement the differences in __get__ behavior between them.  
Recently GvR mused about doing away with unbound-methods per se, but 
after some discussion on python-dev he currently seems to have 
withdrawn the proposal; you may want to read that discussion in the 
python-dev archives since it's relevant to prototyping your idea.  In 
any case, a one-liner would not be enough, although:

> would be hard to implement it, or inefficient.

...that doesn't necessarily make it either hard or inefficient.

> If there a good reason that the __get__ of a boundmethod does not
> create a new boundmethod wrapper over the first boundmethod?

There might be some inefficiencies in the multiple indirections, but 
that remains to be proven until we have a prototype.  Besides, if there 
are, the right approach would probably be to have some generalization 
of boundmethods able to bind the first N arguments rather than one at a 
time.


Alex