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
Backport the python type stubs from master to RC_1_2 and RC_2_0 #6532
Comments
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
is there a way to ensure type stubs stay in sync with the bindings? just a test that fails would be helpful. |
The This is an extra incentive to make the test suite extremely complete. All the lines in the The only way to do better would be to generate type stubs rather than handcraft them. There's an official |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
I'd like for https://github.com/AllSeeingEyeTolledEweSew/tvaf to depend on libtorrent's python type stubs.
But the type stubs are only in
master
, and it looks like there won't be releases frommaster
for the foreseeable future. I think they're useful enough to be worthy of backporting.Backporting the stubs is easy, but the existing
test.py
won't exercise them thoroughly. I would greatly prefer to backport the rest of the test infrastructure frommaster
along with the type stubs.I think this is a larger symptom of #6531. We should backport other python binding infrastructure changes, and just be sure to include the type stubs.
This is a separate issue from #6531 because the type stubs are technically new functionality.
The text was updated successfully, but these errors were encountered: