new.instancemethod as a form of partial()

[bon...@gmail.com]

I came across this while searching for a way to DIY partial(), until it
is available in 2.5

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/229472

However, when trying for the following, it doesn't work and is
wondering if it is a bug or intended :

>>> import operator
>>> import new
>>> new.instancemethod(operator.is_,None,object)(None)

Traceback (most recent call last):
File "<pyshell#5>", line 1, in -toplevel-
new.instancemethod(operator.is_,None,object)(None)
TypeError: is_ expected 2 arguments, got 1
>>> new.instancemethod(operator.is_,False,object)(False)
True

So it seems that instancemethod() don't like "None" as the instance.

[Alex Martelli]

<bon...@gmail.com> wrote:
...

> So it seems that instancemethod() don't like "None" as the instance.

"bound methods" and "unbound methods" are instance of the same type,
distinguished by one thing: the im_self of an unbound method is None,
the im_self of a bound method is anything else.

So, when you pass None as the instance, instancemethod likes it just
fine... and returns an "unbound method" as the result, so you haven't
actually achieved your goal (you must still pass the first parameter
explicitly -- all you've "gained" by wrapping a function into an unbound
method is an implicit typecheck on the first argument, and if, as the
class, you're using 'object' as in your example, that's not much use
[even in other cases, it's no great shakes;-)]).

Alex

[bon...@gmail.com]

thanks. So in this special case, None is being treated as a "flag"
rather than just an instance(I just read the doc) like any other
instance and the behaviour is intended. Is there any reason why it is
designed this way ?

[Alex Martelli]

<bon...@gmail.com> wrote:
...

> thanks. So in this special case, None is being treated as a "flag"
> rather than just an instance(I just read the doc) like any other
> instance and the behaviour is intended. Is there any reason why it is
> designed this way ?

I didn't yet know Python back when it was designed (dark ages, really),
but I assume the point was that, back then, we only had what's now the
legacy object model: bound methods could only be bound to instances,
classes were distinct from types, etc. So, an im_self that wasn't an
instance had no possible "normal" meaning, and None was a handy
placeholder. Of course, this design then couldn't be changed (nor can
it be now, until 3.0) to preserve backwards compatibility.

Guido has mused about abolishing "unbound methods" (in 3.0, I guess), so
there's hope for the future. But a more complete 'partial' is likely to
be acceptable sooner than any fix to bound/unbound methods: I suspect
the only ingredient that's missing is a generous helping of irrefutable
use cases.

Alex

[bon...@gmail.com]

Alex Martelli wrote:
> Guido has mused about abolishing "unbound methods" (in 3.0, I guess), so
> there's hope for the future. But a more complete 'partial' is likely to
> be acceptable sooner than any fix to bound/unbound methods: I suspect
> the only ingredient that's missing is a generous helping of irrefutable
> use cases.

So long the new partial() has this case covered, it is fine. As it
seems that this recipe
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52549 also
forgot this special case(down to the bottom, the current curry code).