[python-win32] "Casting" COM objects

[Mark Hammond]

> > I *think* that is what you were asking :)
>
> Exatly. It is so new that my copy of pythonwin doesn't have it. But
> that's not a big deal, my workaround is good enough for now and I'll use
> this when the time comes.
>
> But over time, my question changed. It became: "how can I get dynamic
> behaviour out of a makepy'd class." One suggestion is that MakePy's
> __getattr__ could fall back to trying to do a dynamic dispatch. If
> you're going to raise an exception anyhow, you might as well be sure
> that the thing you're trying to do is going to fail. The downside of
> this is that it might allow people to inefficiently call methods that
> are missing in the static interface and not know why it is so slow. Case
> errors in particular might be worrisome.

I'm not sure this will work.  The problem is the vague distinction between
COM "classes" and "interfaces".

In general, we can introspect all interfaces supported by a class.  However,
given just an interface, we often can't instrospect back to "what class do
you belong to?".  IDispatch does provide some help here, but longer term we
want to support "vtable" interfaces being called, and ideally we should
provide an identical interface to an object regardless of the access method.

To take thus further, we can not assume that just because a given class
nominates that is supports an interface, that all such interfaces are from
that class.

Given just the interface, we could start poking around to try and see if it
really *is* one of those classes, but this doesn't sound right.

To be quite honest, I am not 100% clear on how classes and interfaces really
relate at an IDispatch level - a class looks very much like an interface
from IDispatch's point of view - ie, the object returned from Dispatch() is
generally a class - it is just that makepy generally converts it to the
default interface.

Unfortunately, my time is thin and no one else has recently contributed in a
meaningful way to the COM work - too many things to work on, and not enough
incentive :)  I'd be more than happy to help anyone else with their efforts
in cleaning some of this stuff up.  In particular, what makes sense in a
vtable enabled future.

Mark.