Pythonwin and Office 2000

[Mark Hammond]

[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.

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.  (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).

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.

Anyway, I have thought about this, and could not come up with a decent
solution.  The "gencache" implementation was the result - I knew it to be
half-baked, but really couldnt come up with a reasonable solution.

>In fact, the most Pythonish way would be to do what Python does with
>Pyc's. When Pythonwin does a win32com.client.Dispatch, it could generate
>the gencache module if possible. If not possible then no problem, it just
>works in the dynamic mode.

Yes - this could also work.  Indeed, we could change the generation so that
instead of doing the whole type library, it only does the classes of
interest.  In many respects, you could consider makepy itself a hack that
should be removed once Python can do a better job dynamically.

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.  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).

There is plenty of scope to rationalize some of this.  As Python COM support
has grown from its humble beginnings, some of the existing code is no longer
appropriate.  It is also big and scary enough that fiddling will not have
the desired effect - it needs a good, hard think and a revamp.
Compatibility shouldnt be an issue - there are only about 4 truly public
functions in the whole package - 99% of users will only care that
"win32com.client.Dispatch" does what they expect!

>Also, is there any chance of having win32com.client.Dispatch renamed
>CreateObject() for JavaScript and VBScript compatibility?

This sounds reasonable (well, not rename, but alias).  OTOH, maybe we should
reserve this name for the "new world order" - eg, just incase someone _does_
step forward and some of this does get rationalised, there may be
better-but-slightly-different semantics better exposed as CreateObject()
(with Dispatch()" becoming a backwards compatible interface)

Hope this all makes sense...  Just incase people hadnt noticed, COM
development is very quite these days.  Almost no new activity and only
maintenance type work is being done.  This sort of work is unlikely to get
done without a volunteer.

Mark.