enthought / enthought/comtypes

`type(_compointer_base)` might be replaced with `_compointer_meta`.

Open
#656 0 comments 0 reactions 0 assignees View on GitHub
good first issue
Dominant language
Python
Stars
345
Forks
105
PR merge metrics
No merged PRs in 30d

Description

Whether it’s a remnant of Python 2.x or a legacy from the early stages of this project, the metaclass is directly accessible as shown below, it still retrieves the metaclass indirectly using `type`.

https://github.com/enthought/comtypes/blob/d80810b50eb642053b8dc1c3a2a4735bedf0a059/comtypes/_post_coinit/unknwn.py#L112-L126

If it can be confirmed that there are no problems, replacing them would improve the readability of the codebase.

```diff
_ptr_bases = (self, POINTER(bases[0]))

# The interface 'self' is used as a mixin.
- # HACK: Could `type(_compointer_base)` be replaced with `_compointer_meta`?
- # `type(klass)` returns its metaclass.
- # Since this specification, `type(_compointer_base)` will return the
- # `_compointer_meta` type as per the class definition.
- # The reason for this implementation might be a remnant of the differences in
- # how metaclasses work between Python 3.x and Python 2.x.
- # If there are no problems with the versions of Python that `comtypes`
- # supports, this replacement could make the process flow easier to understand.
- p = type(_compointer_base)(
+ p = _compointer_meta(
f"POINTER({self.__name__})",
_ptr_bases,
{"__com_interface__": self, "_needs_com_addref_": None},
```

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.