Skip to content
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

Closed
AllSeeingEyeTolledEweSew opened this issue Oct 19, 2021 · 5 comments
Labels

Comments

@AllSeeingEyeTolledEweSew
Copy link
Contributor

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 from master 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 from master 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.

@stale
Copy link

stale bot commented Jan 17, 2022

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.

@AllSeeingEyeTolledEweSew
Copy link
Contributor Author

@arvidn could you reopen this? it's been requested by other users (#6730)

@arvidn arvidn reopened this May 12, 2022
@stale stale bot removed the stale label May 12, 2022
@arvidn
Copy link
Owner

arvidn commented Jun 12, 2022

is there a way to ensure type stubs stay in sync with the bindings? just a test that fails would be helpful.

@AllSeeingEyeTolledEweSew
Copy link
Contributor Author

The mypy config in .pre-commit-config.yaml type-checks the python test suite against the type stubs. That's as good as we can do right now.

This is an extra incentive to make the test suite extremely complete. All the lines in the master test suite like assert isinstance(some_enum_value, int) are there to exercise the type stubs more than to exercise the runtime types of every enum value.

The only way to do better would be to generate type stubs rather than handcraft them. There's an official stubgen tool that generates stubs from python extensions. But to work well it relies on some runtime introspection, and this introspection is particularly mangled in boost.python. I know pybind11 (a boost.python alternative) puts more effort into the introspection of its output, so I believe it will work better with stubgen, but I haven't tested this. I believe pybind11 has a number of advantages over boost.python so I want to explore it more, but this won't happen for a while.

@stale
Copy link

stale bot commented Sep 21, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants