COM with Python?

[Mark Hammond]

Gordon McMillan wrote:
> Well, having just done some testing, let me put a resolution on this:
> the global Python object approach works (which surprised me!), and
> the Running Object Table approach, while it works, seems to have
> stability problems.

Excellent!
>
> To explain: I hadn't realized that the COM plumbing would, when using

he he - I did, so I knew it would :-)

> CLSCTX_LOCAL_SERVER, reconnect to a running instance, (so I doubted
> that the global Python object approach would work). It does, and
> while I haven't left one running for 24 hrs yet, it appears to work
> flawlessly - the COM invoked pythonw process goes away as soon as all
> refs go to zero.

With build 125, here is an even better trick to impress your friends.
Install Python on 2 NT or DCOM capable 95/98 machines.  One one machine,
say:

x = win32com.client.DispatchEx("Python.Interpreter", "other_machine_name")

And bang away.  Looking at the remote machine show pythonw.exe living
happily, and correctly going away when the remote client deletes x.  [Even
better, we could substitute a proper NT service in place of pythonw.exe,
but that is a different thread, hopefully not for some time :-]

> The ROT approach (using pythoncom.RegisterActiveObject()) is flaky.
> Sometimes the COM invoked pythonw goes away when it should, sometimes

My guess is that this is because we dont handle the concept of "weak
references" that (IIRC) the ROT has.  Ive never really understood it, but I
wouldnt be surprised to find it tied up with IExternalConnection that
AXControls (and Active Scripting) attempt to use to implement "weak
references".  Python can handle this interface, but the framework doesnt -
ie, you must explicitely declare you support this interface and implement
it.  Ive seen my objects be QI'd for this interface, but never seen any
difference in functionality regardless of what I do (ie, implement it,
ignore it, implement it strangely, etc!)

> it hangs around. Worse, if you leave it running for long periods, it
> seems capable of freezing NT's UI (the machine appears to still be

Eeek!

> alive, but you can't _do_ anything except reboot). I'm more than
> willing to believe that this is NOT Mark's fault.

Whew :-)  Although it would seem clear we are screwing _something_ up -
many other apps use the ROT without this problem.  But Ive never seen a
good example of using the ROT that does anything we dont...

Thanks...

Mark.