The __init__.py of this package is very large.
I think this is a barrier for newcomers to the community trying to understand this package.
Considering that the responsibility of __init__.py is to "handle the initialization of the package", calling CoInitializeEx is indeed initialization, so it is necessary in __init__.py.
However, for example, if we define things like the BSTR in other private modules and import it into __init__.py (such as current GUID module), __init__.py will become lightweight.
Firstly, before tackling more complex elements such as metaclasses like _cominterface_meta and global mappings like com_interface_registry, I will be separating out the loosely coupled implementations like instancemethod and/or BSTR into different modules.
In order to keep the change history even if we squash & merge, I will divide it into several PRs.
The
__init__.pyof this package is very large. I think this is a barrier for newcomers to the community trying to understand this package.Considering that the responsibility of
__init__.pyis to "handle the initialization of the package", callingCoInitializeExis indeed initialization, so it is necessary in__init__.py.However, for example, if we define things like the
BSTRin other private modules and import it into__init__.py(such as currentGUIDmodule),__init__.pywill become lightweight.Firstly, before tackling more complex elements such as metaclasses like
_cominterface_metaand global mappings likecom_interface_registry, I will be separating out the loosely coupled implementations likeinstancemethodand/orBSTRinto different modules.In order to keep the change history even if we squash & merge, I will divide it into several PRs.