new.instancemethod as a form of partial()

[bonono@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 :
[color=blue][color=green][color=darkred]
>>> import operator
>>> import new
>>> new.instancemet hod(operator.is _,None,object)( None)[/color][/color][/color]

Traceback (most recent call last):
File "<pyshell#5 >", line 1, in -toplevel-
new.instancemet hod(operator.is _,None,object)( None)
TypeError: is_ expected 2 arguments, got 1[color=blue][color=green][color=darkred]
>>> new.instancemet hod(operator.is _,False,object) (False)[/color][/color][/color]
True

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

[Alex Martelli]

Re: new.instancemet hod as a form of partial()

<bonono@gmail.c om> wrote:
...[color=blue]
> So it seems that instancemethod( ) don't like "None" as the instance.[/color]

"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

[bonono@gmail.com]

Re: new.instancemet hod as a form of partial()


Alex Martelli wrote:[color=blue]
> <bonono@gmail.c om> wrote:
> ...[color=green]
> > So it seems that instancemethod( ) don't like "None" as the instance.[/color]
>
> "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;-)]).
>[/color]
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]

Re: new.instancemet hod as a form of partial()

<bonono@gmail.c om> wrote:
...[color=blue]
> 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 ?[/color]

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

[bonono@gmail.com]

Re: new.instancemet hod as a form of partial()


Alex Martelli wrote:[color=blue]
> 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.[/color]
So long the new partial() has this case covered, it is fine. As it
seems that this recipe
http://aspn.activestate.com/ASPN/Coo...n/Recipe/52549 also
forgot this special case(down to the bottom, the current curry code).