Extending objects through methods' __call__

[Mark Hammond]

This is the exact same problem PythonCOM faces.  If PythonCOM had this,
quite a few nasty hacks and surprises could be removed.

However, as far as I can tell, it really can't be done.

On of the most obvious examples why is:
You want:
x.Foo() # resolves to s.__methcall__("Foo", *args)

So what would:
meth = x.Foo
meth()

resolve to?  Surely this wouldnt work using your scheme.  It can't simply be
changed to "__getmeth__", as at the time "x.Foo" is executed, we have no
idea what later code will do with the object (ie, will it call it?)

This points to the underlying problem - at the time Python does a
__getattr__, it has no idea of the context, and I can't see how it can.  I
can not come up with anything that works as expected in all cases...

Mark.


Hrvoje Niksic wrote in message <87pv40vbwv.fsf at pc-hrvoje.srce.hr>...
>Something appears to be lacking in Python's class interface.  If I
>have a class X and its instance x, then I can customize what x() will
>do (via X.__call__), what reading and assigning to x.foo will do (via
>X.__getattr__ and X.__setattr__), what reading and assigning to x[foo]
>will do (via X.__getitem__ and X.__setitem__) and a bunch of other
>things, but...  I cannot tell what x.foo() will do, at least not
>without knowing all the foo's in advance.  Or can I?