Jun Komoda

## Type hinting for statically defined module, like `comtypes/__init__.py`. I realized that it would be hard to update the `.pyi` files statically defined to match the updating `.py` files statically...

I would like to use a similar process to generate runtime code and type stub code. I will create a base class that abstracts the `tools.codegenerator.CodeGenerator` class. I would like...

@kdschlosser Thank you for your interest in this enhancement. Thank you for coming back with your knowledge of COM and `ctypes`. As a matter of fact, I don't care how...

@kdschlosser This package still supports Python 2.7. However, [a milestone has now been set for the removal of support for Python2](https://github.com/enthought/comtypes/milestone/4). It will be about one year from the time...

@kdschlosser I agree that there should be type hints in the runtime code generated by the `codegenerator`. However, since there is also the matter of #216, I have come up...

@kdschlosser > modules dictionary The `Friendly.py` issue is also covered in #328. It would be great if it were easy to stop manipulating the module dictionary. > a really large...

@kdschlosser > No I don't mean https://github.com/enthought/comtypes/pull/263. > > I did a redo of the code and made it easy to access the data. If so, please PR that revised...

@kdschlosser > ```python > from ctypes import POINTER > from typing import TypeVar, Type > > _TV_POINTER = TypeVar("_TV_POINTER", bound=POINTER) > _T_POINTER = Type[_TV_POINTER] > ``` This should be a...

@kdschlosser > The use of `TYPE_CHECKING` really should only be reserved for the importation of modules that would cause a circular import. You would need to wrap whatever the type...

@kdschlosser > I feel that making a branch to start working on dropping python2 is the way to go. There is really no sense in doing all the type hints...