-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
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 prevent regressions with the combination of ctypes
and metaclasses.
#125783
Comments
Before calling something a “breaking change”, please check that you're not using internal API. Things like this are fragile:
I appreciate that Python's backwards compatibility policy is unclear on some of these techniques; should we clarify it? I also appreciate that what you're doing isn't possible with public API. I will try to not break your use case (and time permitting, to add supported API). But let's be clear that your warranty is void, so to say. Expect that with some CPython version will break All that said, it would definitely be good to add tests like this, to make sure the internals don't change unexpectedly -- especially if people are relying on the internals. Even better: we could expose some public API for adding things to |
As you pointed out, it is true that the implementation of I don't think we can clearly define a backward compatibility policy for Python here. I agree with transitioning from directly manipulating private elements to using the public API. For now, I think it’s reasonable to continue using |
Would defining a class with a metaclass be sufficient for the test? |
I came up with the idea of adding assertions to confirm superclass relationships to prevent projects like Even if the registration method for pointer types changes in the future, as long as these assertions don't fail, those projects should continue to work. |
…ctypes` and metaclasses. (GH-125881)
…n of `ctypes` and metaclasses. (pythonGH-125881) (cherry picked from commit 1384409) Co-authored-by: Jun Komoda <45822440+junkmd@users.noreply.github.com>
…n of `ctypes` and metaclasses. (pythonGH-125881) (cherry picked from commit 1384409) Co-authored-by: Jun Komoda <45822440+junkmd@users.noreply.github.com>
…on of `ctypes` and metaclasses. (GH-125881) (GH-125988) cherry picked from commit 1384409 by Jun Komoda Also: Add test_ctypes/_support.py from 3.13+ This partially backports be89ee5 (#113727) by AN Long Co-authored-by: Jun Komoda <45822440+junkmd@users.noreply.github.com> Co-authored-by: AN Long <aisk@users.noreply.github.com> Co-authored-by: Erlend E. Aasland <erlend.aasland@protonmail.com>
Thank you! The backports are merged now. |
… of ctypes and metaclasses. (GH-126126)
…nation of ctypes and metaclasses. (pythonGH-126126) (cherry picked from commit 6c67446) Co-authored-by: Jun Komoda <45822440+junkmd@users.noreply.github.com>
…nation of ctypes and metaclasses. (pythonGH-126126) (cherry picked from commit 6c67446) Co-authored-by: Jun Komoda <45822440+junkmd@users.noreply.github.com>
The PRs to add tests that creates and registers pointer types within the I believe there is nothing more to do in this issue, so I’ll close it. There may be some areas that haven’t been tested in terms of using COM with I’m also interested in adding a public API like |
Feature or enhancement
Proposal:
There were breaking changes to
ctypes
in Python 3.13.Projects like
comtypes
andpyglet
, which implement functionality by combiningctypes
and metaclasses, no longer work unless their codebases are updated.We discussed what changes such projects need to make to their codebases in gh-124520.
I believe the easiest and most effective way to prevent regressions from happening again is to add tests on the
cpython
side.I wrote a simple test like the one below.
If no errors occur when this test is executed, we can assume that no regressions have occurred with the combination of
ctypes
and metaclasses.However, I feel that this may not be enough. What should we specify as the target for the
assert
?Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
#124520
Linked PRs
ctypes
and metaclasses. #125881ctypes
and metaclasses. (GH-125881) #125987ctypes
and metaclasses. (GH-125881) #125988The text was updated successfully, but these errors were encountered: