Pythonwin and Office 2000

[Toby Dickenson]

"Mark Hammond" <MHammond at skippinet.com.au> wrote:

>[CC'd from the newsgroup to the python-com developers list]
>
>Paul Prescod wrote in message <3776D1E6.45E1AAF7 at prescod.net>...
>
>>Is there an equivalent to EnsureModule that works from the textual library
>>name? I know that the textual library name still changes from version to
>>version but I don't think it is Pythonish (easy, clean and readable) to
>>put UUIDs in code at all.
>
>I agree.  Worse, as you found out, it breaks when upgrading the COM object.
>However, the only way to do it textually would be to search the registry for
>the name.  Depending on the system, this can be significant.  The IID and
>version info give us a direct key into the registry.  On my development
>system, searching for an IID name could take a few seconds, and (IMO) we
>can't afford this hit just to check.

If you need to ensure that the makepy wrapper is always available, independent
of type library, then I have found the most convenient approach is to copy the
appropriate module out of the genpy directory and import it directly. No UUIDs
in sight, and it works with freeze. This is effectively what Mark describes
below.

makepy should always generate the same wrapper for the same version of each type
library, so you don't lose anything after this initial inconvenience. 

In theory, the old wrapper should continue to work after upgrading the com
server. In practice, any uprade involves some risk but this strategy seems to
minimise it.

>I can't think of a better solution.  The Python equivilent to the VB system
>would be for the developer of a script to nominate the type libraries they
>reference, and to generate the necessary makepy support into a single file.
>This single file would then be shipped with the script.

(this is possible to hack today, described above)

> (VB puts the
>generated code in the same .exe, hiding this extra distribution - in Python
>terms, this would be integrating with freeze etc).  To go this route would
>really require that makepy no longer generate source code, but instead
>generate a tight binary format (which may be desirable anyway).

Why single out the makepy wrapper for this compacting effort? Several other
modules lead to embarrasingle big .pyc and frozen .exe files, but I have never
found this a practical problem.

VB and C++ (and maybe Delphi) gain an advantage from the compile-time approach
since, in combination with static typing, they can optimise into vtbl method
calls. Today, Python is firmly tied to Invoke. We could gain this same
_performance_ advantage by extending makegw to understand type libraries, but
that just changes the problem into having big .dlls. And you also need a
compiler.

(Note: this may be a practical approach if you need to run many python processes
on the one machine; the dll images could be shared between processes. However I
don't see it as a general solution)

>VBScript, for example, does not have the concept - it only understands (in
>Python parlance) "dynamic dispatch".  Delphi, AFAIK, also makes it a
>build-time step, rather than a run-time step.
>However, it is worth noting that speed is no longer a good justification for
>using makepy.  Recent changes to dynamic dispatch mean that we are now
>comparable speed wise to VB without makepy support.



>  The reason you often
>now need makepy support is to get decent parameter support, but the problem
>is worse than that.

Is the parameter support still a continuing problem? I had the impression that
in general only older servers had this problem, with newer servers being much
better behaved?

>  In many non-trivial cases, the code you write is simply
>not compatible between makepy supported and dynamic dispatch.  So, if you
>want to ensure your code will run when installed, you must _insist_ on
>makepy support.  (ie, silent failure of makepy is usually not a good option,
>as you are simply delaying the inevitable error, but in a less obvious way).

Agreed.



Toby Dickenson