Future of this package

[lassoan]

This package is very useful, thanks a lot for providing it! I would like to use it in a large open-source project (3D Slicer) but I'm not sure if I can rely on it in the long term, due to the followings:

1. It seems that there have been no new tags (and releases on PyPI) for almost two years
2. It is still not a native Python3, but patched using 2to3
3. Large backlog of open issues and 10+ open pull requests

Could somebody provide information about current status and future plans for this package?

I see that there have been some recent commits, so I still have some hope. Thanks in advance!

[cfarrow]

Hi Andras. I know of no long term plans for this package, except perhaps for users keeping it running for their use cases. The package can live on for a while in this self-service mode, but nice-to-haves like native python 3 support are not likely be prioritized.

I do virtually no work on this package, as my job and personal life no longer involve coding. @vasily-v-ryabov does the bulk of reviewing and committing. I'd welcome a discussion about building a critical mass of contributors and admins for this project.

[lassoan]

@cfarrow thanks a lot for the quick answer. @vasily-v-ryabov do you have any comments?

[vasily-v-ryabov]

Hi guys, I have some plans on diving deeper into the comtypes source code with potential improvements. My interest is mostly comtypes' usage in pywinauto as a dependency (we're already using it for few years). I'll try to explain my immediate interests and nice-to-have things which I can support as a reviewer.

• I'm not pursuing better Python 2.x/3.x support, but can review/discuss it.
• Running all unit tests on AppVeyor would be more helpful for potential contributors. It is also nice to have.
• The most critical for now is new wheel versions support which is reported in both projects already. Hope to take this task in nearest two months if nobody takes care of it. It could be a reason for 1.1.8 version update.
• I do want to debug some issues with 32-bit/64-bit Python / COM libraries that we have in pywinauto's backlog. This is medium priority for me, but there are a lot of high priority tasks in pywinauto which is also a hobby project in its turn. :)
• Also I'm interested in more convenient packaging into a single executable (low priority for now, may be raised in the future) so I may think about on-the-fly code generation into a memory without saving to cache file or something like that.

No more global things for now.

[lassoan]

A new release would be important, because if there are no new releases then fixes and improvements will not get to users. It would be also important to merge pull request and review issues. Setting up AppVeyor would be nice because then pull requests could be more confidently merged.

If there is a consensus that Python2 support can be dropped then updating the syntax for Python3 should not be hard, especially if there are automated tests. I can help with this, as we try to avoid depending libraries that are not updated to Python3.

[vasily-v-ryabov]

pywinauto is not planning to drop Py2.7 support. So I vote against it in comtypes as well. Also I'd prefer to keep comtypes a pure Python library (without any dependencies). We may think about six usage only, but I'm not sure it's so necessary.

[lassoan]

pywinauto is not planning to drop Py2.7 support

My understanding is that projects are actively encouraged to drop Python2 support before the end of 2020 to reduce frictions in the Python ecosystem (https://python3statement.org/). Anyway, if you are ready to pull the plug on Python2, then I'm ready to help with the update.

[vasily-v-ryabov]

I think it would be easy to make better Py2/Py3 support with already working AppVeyor tests. So making better CI is a fundamental task for further progress. Currently it is implemented as python setup.py test command which looks a bit old fashioned. And this command is not running on AppVeyor due to some failures in the full test set. I added some installation tests to AppVeyor a while ago. I'd appreciate if this work was continued.

[wkschwartz]

I just wanted to contribute one user's voice to this discussion.

1. I vote for the quote below. My use case is packaging apps using PyOxidizer. The apps depend on comtypes. I haven't gotten far enough down the rabbit hole of getting it to work to know whether comtypes needs to change for me to use PyOxidizer. I just wanted to let you know that's a use case I care about.

Also I'm interested in more convenient packaging into a single executable (low priority for now, may be raised in the future) so I may think about on-the-fly code generation into a memory without saving to cache file or something like that.

2. I care about CI/automated testing because it would give me confidence in comtypes' reliability, which matters a lot for my apps.
3. On Python 2/3 in response to the quote below: Since Python 2 has died, perhaps it would be better to use future than six. Putting future; python_version <= "2.7" in setup.py's install_requires would burden the few remaining Python 2 users rather than the mass of Python 3 users.

We may think about six usage only, but I'm not sure it's so necessary.

[nanonyme]

Even if there's no larger changes to the project done, it would be really great if #172 (or something equivalent) could be integrated and a new release could be done. Currently this project is randomly failing on Windows with new Python 3 versions which is causing issues with pywinauto. (which depends on this project for UIAutomation support) Afaik many other UI automation tools also use Windows UIAutomation through comtypes so they have the same problem.

[snoopyjc]

Please let Python 2 die!

[nanonyme]

IMHO debating killing Python 2 is futile if the person who is more or less maintaining this project intents on keeping the support for now. This should not and must not mean halting improving the quality of this project on Python 3 though.

[vasily-v-ryabov]

comtypes==1.1.8 is out.

[junkmd]

A long time has passed since this issue was posted.

And now,

• comtypes==1.1.11 has been released and is coded Python3 native.
  • while still being backward compatible to 2.7
• AppVeyor CI in each Python version now runs on PRs to the main branch.
  • it is only environment-independent, so Excel, Word, and other env-dependent testings are excluded.

As I planned in #327, I am trying to tie the comtypes type definition system into Python's type hinting system.

• It is possible to write type hints in versions where typing or inline (variable or function) annotations are not supported(see PEP561 and PEP484).

I think it is important to once again discuss plans in the future, and this issue is a good place to discuss it.

• For example, it has been more than three years since Python 3.4 EOL. It is longer than since sunset Python 2.

What are participants thoughts on this now?

[vasily-v-ryabov]

Removing Py3.4 is OK to me. Even if someone has legacy Python 3.4 environment, there is a very low risk something is broken in comparison with 3.5 or even 3.6. But keeping Py2.7 covers more legacy users in my opinion. I would remove Py2.7 after 1 more year of support which shouldn't bother all us so much. For example, we can release comtypes 1.1.13 and 1.1.14 with Py2.7 support and then release comtypes 1.2.0 with Py3.6+ support only. So type hints are natively supported from some moment without any additional efforts.

[junkmd]

@vasily-v-ryabov

I agree with your suggestion to support only Py 3.6+ when dropping Py 2.7.

With Py3.6+, we can use the built-in typing.
And enum module is also supported, which may be able to provide new features related to enumerations.

I understood that it will be about a year later we release the version of Py2.7 dropped.

I will develop this package according to that plan.