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[3]: <COMObject Excel.Application>
Then trying 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 EnsureDispatch
:
import win32com.client as win32
xl_ens = win32.gencache.EnsureDispatch("Excel.Application")
xl_ens
Out[3]: <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 COM
object.
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.