Overloading operators on the rigth.

[Alex Martelli]

Bengt Richter <bokr at oz.net> wrote:

> On Wed, 13 Oct 2004 10:18:28 +0200, aleaxit at yahoo.com (Alex Martelli) wrote:
> 
> >Bengt Richter <bokr at oz.net> wrote:
> >   ...
> >> >>>> class foo:
> >> >...   def __getattr__(self, name):
> >   ...
> >> On my system, (NT4, python 2.3.2) what really happens for newstyle classes
> >> isn't apparent from that experiment:
> >
> >Heh, of course not -- the main difference between old-style and
> >new-style classes is that, for the latter, implicit lookup of special
> >methods when needed for operations starts with the *class*, not with the
> Well, it always starts with the class if there's no attribute on the instance,

I find this a strange meaning for the word "start".  To ensure the
instance doesn't have the attribute, that's where (conceptually) one
could say the lookup "starts", I think.

> but the key is whether the "implicit lookup" for methods needed for
> operations uses an overridable __getattribute__ somewhere, or just chases
> down the bases chain looking for the actual __gt__ or whatever, not
> allowing a hook to synthesize a result.

Actually, it reaches right into the appropriate slot of the type
structure.  The slots are generated or changed when the type (i.e., the
class object) is generated or changed.  So, it may be improper on my
part to call this procedure a 'lookup'.

> >I just used an old-style class because, that way, I could show the
> >lookups happening without having to code a custom metaclass.  The
> Could you show such a metaclass? I have tried a few things and not
> succeeded. It almost makes me think there is no place to hook the internal
> __getattribute__ that looks for the methods for code generated from 12<f
> and the like. I'd be interested in seeing it.

I think I'd basically have to repeat what types.ClassType is doing --
essentially, prefill all slots with functions that _do_ perform the
lookups.  To be honest, I haven't tried to see if that strategy hits any
snags, I just don't think it would.

 
> >special names being looked for are just the same, whether for classic or
>                                     ^^^^^^^^^^^^^^
> but maybe not the same order, see below 
> >newstyle classes, anyway -- all that changes is _where_ they're looked
> >up (starting on the instance, vs starting on the class).

You're right -- coercion is "fading" so it's now attempted _after_ 3-way
comparison rather than before; so the 'where' isn't quite _all_ that's
changed (I had never coded nor seen a classic class which depended on
coercion for its comparisons, which may explain though not excuse my
imprecision).


> NBD, but perhaps the order change is a version difference?

Yep, it's part of coercion slowly going away.

> Not that the OP was asking any of this ;-)

No, but they may still be meaningful in some cases, of course.


Alex