Split __init__.py
into some modules (only NOT tightly coupled)
#559
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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", callingCoInitializeEx
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 currentGUID
module),__init__.py
will become lightweight.Firstly, before tackling more complex elements such as metaclasses like
_cominterface_meta
and global mappings likecom_interface_registry
, I will be separating out the loosely coupled implementations likeinstancemethod
and/orBSTR
into different modules.In order to keep the change history even if we squash & merge, I will divide it into several PRs.