I have been recently using win32com.client from python as an API for windows applications but am struggling to understand some basic things.
I had been using it with a program called WEAP, in the following way
import win32com.client win32com.client.Dispatch("WEAP.WEAPApplication")
Now, I want to use it with Excel and have found alternatives to the previous lines, one of them as follows (taken from Python: Open Excel Workbook using Win32 COM Api)
import win32com.client as win32 excel = win32.gencache.EnsureDispatch('Excel.Application')
Does anyone know the difference between using
and other alternatives? Does anyone know pros and cons of each one? or some advice regarding when one or another should be used?
I have looked for advice and i have found some useful answers, eg:
However, they are usually focused on answering specific issues, and not describing the bigger picture of the differences between Dispatch, gencache.EnsureDispatch, and perhaps further alternatives, which is what i want.
Any advice would be greatly appreciated.
One thing about it you need to read is this link.
I will try to answer shortly (finally not so short by the end…) your question, but I’m not a expert.
When you create a
COM object with python, how python knows what methods and parameters are available for this object? This is related to the notion of early and late binding.
If you try to create a
COM object you never used before with
Dispatch, you won’t know what is available with your object. If I do in a Jupyter QtConsole:
import win32com.client as win32 xl_dis = win32.Dispatch("Excel.Application") xl_dis Out: <COMObject Excel.Application>
xl_dis. to see what I can do after, I won’t get any choice. I’m in the case of a late binding, “python does not know what the object can do”.
If I do the same thing with
import win32com.client as win32 xl_ens = win32.gencache.EnsureDispatch("Excel.Application") xl_ens Out: <win32com.gen_py.Microsoft Excel 14.0 Object Library._Application instance at 0x35671240>
First, you can see the difference on the output and then if I do
xl_ens. I will get some methods and parameters available. I’m now in early binding and “python knows some of what the object can do”.
What happens is that
EnsureDispatch forces to run
makepy.py at first (look in your folder
Libsite-packageswin32comclient) to create a folder in
Libsite-packageswin32comgen_py containing python scripts with some methods and parameters related to this
Now, if you try again in a new console using
Dispatch, you will get the exact same result. Indeed, after using
EnsureDispatch, the folder created before in
win32comgen_py still exists and “python still knows what the object can do”. To experiment it yourself, go to your folder
win32comgen_py and delete the folder with excel information (for me, the name is
00020813-0000-0000-C000-000000000046x0x1x7, not sure it is the same for you).
Finally, one difference between both is mainly to force or not the early binding the first time you create a
COM object, but if the folder related to your
COM object already exist in
win32comgen_py, then not much difference.
These two sentences of the link I gave:
To force the use of early binding to access COM objects, you must force the MakePy process in your code. Once you have ensured the MakePy support exists, use win32com.client.Dispatch() as usual. It always returns the MakePy-supported wrappers for your COM object.
To force the MakePy process, the win32com.client.gencache module is used. This module contains the code that manages the directory of MakePy-generated source files: the generated cache, or gencache. There are a number of useful functions in this module, and you are encouraged to browse the source file if you need to perform advanced management of these generated files.
kind of summary this.
The other alternative is to use
dynamic such as
win32.dynamic.Dispatch("Excel.Application") and you will always get a
COM object in late binding.
Location of the generated cache may be in USER_PROFILEAppDataLocalTempgen_pyPYTHON_VERSION . This can be useful if one wants to clear the cache.