Pythonwin and Office 2000
MHammond at skippinet.com.au
Mon Jun 28 20:25:54 EDT 1999
Toby Dickenson wrote in message <377cdaaa.6963555 at news.freeserve.net>...
>If you need to ensure that the makepy wrapper is always available,
>of type library, then I have found the most convenient approach is to copy
>appropriate module out of the genpy directory and import it directly. No
>in sight, and it works with freeze. This is effectively what Mark describes
And back to how makepy worked originally. Damn it.
>> (VB puts the
>>generated code in the same .exe, hiding this extra distribution - in
>>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
>found this a practical problem.
>VB and C++ (and maybe Delphi) gain an advantage from the compile-time
>since, in combination with static typing, they can optimise into vtbl
>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
>>is worse than that.
>Is the parameter support still a continuing problem? I had the impression
>in general only older servers had this problem, with newer servers being
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.]
More information about the Python-list