Automagic type conversions, was: Re: I come to praise .join, not to bury it...

[Rainer Deyke]

"Steve Holden" <sholden at holdenweb.com> wrote in message
news:qZvp6.29197$ML1.1439945 at e420r-atl2.usenetserver.com...
> "Rainer Deyke" <root at rainerdeyke.com> wrote in message
> > I'm curious: how do you feel about the automagic conversions of
functions
> > (and only true function, not function-like objects) into unbound
methods,
> > and from unbound methods into bound methods?  I'm thinking that the
former
> > could be eliminated entirely, and the latter replaced by a __bind__
magic
> > method that allows the mechanism to apply to function-like objects.
> >
> >
> Surely no type conversion is involved: the interpreter just converts
>
>     instance.method(*args)
>
> into
>
>     class.method(instance, *args)
>

>>> class X: pass
...
>>> def f(self): pass
...
>>> type(f)
<type 'function'>
>>> X.f = f
>>> type(X.f)
<type 'instance method'>
>>> x = X()
>>> x.f is X.f
0

As of 2.0, 'x.f' and 'X.f' have the same type but are different objects.
This is misleading, and I prefer the 1.5.2 behavior where the types of 'x.f'
and 'X.f' were different.  In either version, two automagic conversions took
place, both based on hardwired type.  Consider:


>>> class Y:
...   class Z:
...     def __init__(self, outerself):
...        print outerself
...
>>> y = Y()
>>> Y.Z(y)
<__main__.Y instance at 0077221C>
<__main__.Z instance at 00773BCC>
>>> y.Z()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: not enough arguments; expected 2, got 1


--
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games           -           http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor