Pythonwin and Office 2000

[Mark Hammond]

Toby Dickenson wrote in message <377cdaaa.6963555 at news.freeserve.net>...

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

And back to how makepy worked originally.  Damn it.

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

Sure.  I wasnt thinking about going that far, simply optimizing the makepy
approach.  Eg, rather than generating Python code, it may be better
generating Pythonish datastructures that can be used at runtime.  A good
example is the "propMap???" entries for each class.  Generating these maps
as Python code is a little pointless.

Im not sure moving to vtables is appropriate for win32com.  I think we
should be looking at the COM+ space, and making sure any significant work
like this will tie in with the future.

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

It is a problem mainly with byrefs, and only for those byrefs used on a
dynamic dispatch object that has a type library available, but does not
provide type info at runtime.  However, for most well-behaved objects this
should work fine, either for makepy or dynamic dispatch objects.

[Then we have servers like Notes, that provide 1/2 the information necessary
as a type library, and dont provide _any_ type info at runtime, leaving poor
win32com with a bit of a mess on its hands.]

Mark.