-
-
Notifications
You must be signed in to change notification settings - Fork 30.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add tests to verify the behavior of basic COM methods. #126384
Comments
The behavior when calling the COM method fails depends on what was passed to the prototype to generate the foreign function. If an Although this behavior is undocumented, I will prioritize adding a test to reproduce this difference in behavior. |
Thank you for the test, @junkmd! |
…s. (pythonGH-126610) (cherry picked from commit 7725c03) Co-authored-by: Jun Komoda <[email protected]>
…s. (pythonGH-126610) (cherry picked from commit 7725c03) Co-authored-by: Jun Komoda <[email protected]>
Feature or enhancement
Proposal:
I am one of the maintainers of
comtypes
.comtypes
is based onctypes
to implementIUnknown
and other COM stuffs.In the past, I reported in gh-124520 that projects dependent on
ctypes
was broken due to changes in Python 3.13.I am currently researching whether there are any effective ways to proactively prevent such regressions beyond what I attempted in gh-125783.
I noticed that the
cpython
repository might not contain tests for basic COM methods, such asQueryInterface
,AddRef
, andRelease
.There are many projects besides
comtypes
that define COM interfaces and call COM methods, so I think it’s important to test them.I think that simple tests like the one below, which implements a very basic COM interface and calls its methods, might help prevent regressions.
(I removed the complex parts in
comtypes
, such as defining methods, registering pointer types, and using__del__
to callRelease
through metaclasse magic.)(I have confirmed that this test passes in a virtual environment with Python 3.11.2, which I could quickly set up.)
WindowsError
is raised instead of aCOMError
whenQueryInterface
fails.I welcome any feedback.
Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
No response
Linked PRs
The text was updated successfully, but these errors were encountered: