Pythonwin and Office 2000

[Paul Prescod]

Mark Hammond wrote:
> 
> 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.  

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?

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

Okay, I don't understand what stuff works with makepy and what stuff
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?

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
numbers?

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
makepy generation when possible and fallback to dynamic dispatch
otherwise. Savvy programmers could manually force makepy generation if
they really care about speed.

> 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!

You're suggesting a volunteer take your big, scary code and improve upon
it? :)

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

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

Those who profess to favor freedom and yet depreciate agitation, are men 
who want crops without plowing up the ground. They want rain without 
thunder and lightning. They want the ocean without the roar of its many 
waters. - Fredrick Douglass
 http://www.informamerica.com/Articles/Quotes.htm