Module initialization problem when using COM

[Mark Hammond]

[From comp.lang.python; cc to the PythonCOM developers mailing list]
Christian Tismer wrote in message
<37495899.62DA32ED at appliedbiometrics.com>...

>Without having tried, here my guess: (may be very wrong)

Also without trying, here is my guess, which is very close to yours.

When Python is hosting a COM object, it tries to be a good citizen by
cleaning up.  When the last PythonCOM object destructs, Python is finalized.
When the first PythonCOM object is created, Python is initialized.

This means that the process of creating one COM object, freeing it, then
creating another is transitioning between these states.  As Python has been
finalized and reinitialized, the imports are indeed happening again, as you
would expect in this scenario.

It is unclear if this behaviour of PythonCOM is desirable; if it is not, I
cant see a better way to determine that Python should be finalized - so we
could simply _never_ finalize Python.  However, this is not nice for a long
running process (eg, IIS) that happens to use a Python COM object once.
Ideally (but probably not realistically) finalizing Python should remove
_all_ traces that it ever existed (ie, every scrap of memory should be
freed)

Either way, it does appear that this is the underlying ILU problem.  I would
guess we could invoke the same behaviour from a test program that init'd
then finalized then re-init'd Python before again using ILU.  Is this
possible to confirm?

Mark.