Pythonwin and Office 2000

Mark Hammond MHammond at
Tue Jun 29 02:38:27 CEST 1999

[This is getting too esoteric for the newsgroup.  I'll continue this on the
pycom-dev at list]

Paul Prescod wrote in message <3777C93C.F0B5E236 at>...

>Would that be the same speed as .Dispatch("..."), or ar you saying it
>would be slower? Anyhow, could we store the mapping from string names to
>UUIDs in the gencache directory so that the second time is fast?

Significantly slower.  Using Dispatch(), there are 2 indexed lookups in the
registry to locate the object.  Using a typelibrary description, there will
need to be a search down "HKCR\Typelib" - have a quick look at this sub-tree
(and the reason for the EnsureModule() params should become more obvious :-)

>Okay, I don't understand what stuff works with makepy and what stuff

Neither do I most of the time :-(  This often depends on the COM object

>doesn't. Let's put it this way: if we did everything dynamically the same
>stuff VBScript does dynamically would we slow down so much that makepy
>would be significantly faster again?

If I understand the question, then "No".  But again, it depends on the COM
object, and what type information it provides at runtime.  Some provide all
info both in a typelib and at runtime.  Some provide all info in only one
place or another.  Some (like Notes :-) provide half the info in half the

PythonCOM does the worst job without _any_ typeinfo.  Then it guesses, and
byref or other complex parameters will be wrong.  The level of type info
available determines the likely success.

>Part of the reason I was using makepy was because I needed access to
>constants. How does JScript/VBscript handle this? Do you just have to use

I believe so.

>Even if makepy is 10 times faster than dynamic dispatch, if code at least
>behaved the same with and without it, then we could just try to do the

Yes.  But as I mentioned, speed is no longer the driver.  The type info and
constants are.  And there is no way we can _guarantee_ the same level of
support will be available.  Best we can do is get this working for a class
of "nice" servers (where "nice" may be defined as providing all type info
both statically (ie, type library) and as runtime type info.  Most MS
servers, and indeed most servers written with VB or ATL, will conform.

>You're suggesting a volunteer take your big, scary code and improve upon
>it? :)
Actually, most of this code did not originate from me (is Curt Hagenlocher
still out there:-)  But I have certainly hacked it beyond recognition since

>Is this just Python code that needs fixing or a mix of Python and C++?
>(i.e. are the C++ primatives you provide enough to build the cool new
>Python system on top?)

Just Python.  And just in the win32com.client directory.


More information about the Python-list mailing list