In #469, friendly-modules(such as stdole.py) now explicitly import symbols from wrapper-modules(such as _00020430_0000_0000_C000_000000000046_0_2_0.py).
This makes friendly-modules get along better with the modern static type system.
On the other hand, wrapper-modules is now completely hidden from friendly-modules.
Most developers primarily use only friendly-modules.
However, I have to think of a use case where developers define statically COM interfaces that inherited from IUnknown and use automatically generated interfaces as for the external COM libraries they depend on.
As features like #475 would be implemented, where symbols with the same name behave differently in wrapper-modules and friendly-modules, I expect that there will be cases where it will be inconvenient for the wrapper-module to be completely hidden.
I noticed this problem when I tried to define each COM interface in Excel statically rather than automatically with GetModule.
In my experimental hobby project, the symbols of the stdole, VBIDE and Office type libraries that Excel's COM objects depend on is imported from automatically generated wrapper-modules.
As with the Excel wrapper-modules generated by GetModule, importing the dependencies by wrapper-module name requires knowing the type library version in users' environment, which also reduces readability.
I propose alias-importing the wrapper-module into the friendly-module using an abstracted name (e.g., __wrapper_module__).
# .../comtypes/gen/stdole.py
from comtypes.gen._00020430_0000_0000_C000_000000000046_0_2_0 as __wrapper_module__
from comtypes.gen._00020430_0000_0000_C000_000000000046_0_2_0 import (
...
)
...
By doing so, it is possible to achieve a combination of friendly-modules functionalities and improved access to the wrapper-modules.
# .../myproject/xl_com_itfs.py
comtypes.client.GetModule("stdole2.tlb")
from comtypes.gen.stdole import __wrapper_module__ as stdole_w
...
comtypes.client.GetModule(("{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}",))
from comtypes.gen.Office import __wrapper_module__ as Office_w
...
comtypes.client.GetModule(('{0002E157-0000-0000-C000-000000000046}',))
import comtypes.gen.VBIDE import __wrapper_module__ as VBIDE_w
...
In #469, friendly-modules(such as
stdole.py
) now explicitly import symbols from wrapper-modules(such as_00020430_0000_0000_C000_000000000046_0_2_0.py
). This makes friendly-modules get along better with the modern static type system.On the other hand, wrapper-modules is now completely hidden from friendly-modules.
Most developers primarily use only friendly-modules.
However, I have to think of a use case where developers define statically COM interfaces that inherited from
IUnknown
and use automatically generated interfaces as for the external COM libraries they depend on.As features like #475 would be implemented, where symbols with the same name behave differently in wrapper-modules and friendly-modules, I expect that there will be cases where it will be inconvenient for the wrapper-module to be completely hidden.
I noticed this problem when I tried to define each COM interface in Excel statically rather than automatically with
GetModule
. In my experimental hobby project, the symbols of thestdole
,VBIDE
andOffice
type libraries that Excel's COM objects depend on is imported from automatically generated wrapper-modules. As with theExcel
wrapper-modules generated byGetModule
, importing the dependencies by wrapper-module name requires knowing the type library version in users' environment, which also reduces readability.I propose alias-importing the wrapper-module into the friendly-module using an abstracted name (e.g.,
__wrapper_module__
).By doing so, it is possible to achieve a combination of friendly-modules functionalities and improved access to the wrapper-modules.