-
Notifications
You must be signed in to change notification settings - Fork 760
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
ci: run checks for all platforms on PR #2826
Conversation
9dd6fbb
to
750b914
Compare
4b4482b
to
ae23e49
Compare
Looks like this works quite well, the clippy jobs take around 10 mins, could be faster if we checked fewer feature combinations / python versions. I think it's probably good as-is, what do people think? Another step to do soon is merge the tests & coverage jobs into one; I think we don't need separate steps for those any more. (We can run coverage for all versions on bors, and just run coverage for 3.11 on PR.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intended functionality looks good to me. Beyond that as usual, more questions than answers...
2784: Automatically generate `__text_signature__` for all functions r=davidhewitt a=davidhewitt This PR makes it so that PyO3 generates `__text_signature__` by default for all functions. It also introduces `#[pyo3(text_signature = false)]` to disable the built-in generation. There are a few limitations which we can improve later: - All default values are currently set to `...`. I think this is ok because `.pyi` files often do the same. Maybe for numbers, strings, `None` and `True`/`False` we could render these in a future PR. - No support for `#[new]` yet. Alternative design ideas: - Only autogenerate for methods with `#[pyo3(signature = (...))]` annotation. I started with this, and then decided it made sense to do it for everything. - Opt-out with `#[pyo3(text_signature = None)]`. This is slightly harder to parse in the macro, but matches the final result in Python better, so if this looks preferable to others, I can change from `text_signature = false` to `text_signature = None`. There's some small tidying up / refactoring to do before this merges (happy to take suggestions on this), however the general logic, design and docs are ready for review. 2827: pypy: enable `PyList::get_item_unchecked` r=davidhewitt a=davidhewitt Split out from #2826. Approved previously as part of that review. Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2784: Automatically generate `__text_signature__` for all functions r=davidhewitt a=davidhewitt This PR makes it so that PyO3 generates `__text_signature__` by default for all functions. It also introduces `#[pyo3(text_signature = false)]` to disable the built-in generation. There are a few limitations which we can improve later: - All default values are currently set to `...`. I think this is ok because `.pyi` files often do the same. Maybe for numbers, strings, `None` and `True`/`False` we could render these in a future PR. - No support for `#[new]` yet. Alternative design ideas: - Only autogenerate for methods with `#[pyo3(signature = (...))]` annotation. I started with this, and then decided it made sense to do it for everything. - Opt-out with `#[pyo3(text_signature = None)]`. This is slightly harder to parse in the macro, but matches the final result in Python better, so if this looks preferable to others, I can change from `text_signature = false` to `text_signature = None`. There's some small tidying up / refactoring to do before this merges (happy to take suggestions on this), however the general logic, design and docs are ready for review. 2827: pypy: enable `PyList::get_item_unchecked` r=adamreichold a=davidhewitt Split out from #2826. Approved previously as part of that review. Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
891d4de
to
710c895
Compare
bors r=adamreichold |
Build succeeded: |
I've been struggling a little to merge PRs with the new bors workflow; overall I think the lighter PR workflow is better but the number of combinations of older pythons / platforms not covered makes it easy for the bors step to fail.
This PR tries to improve the situation by merging the
clippy
andcheck-target
job and running it for all supported platforms on PR. Hopefully if these are green, then there's high likelihood that tests will build and should pass unless there's logic errors.While creating this I found a build error on PyPy which made me notice we can support
PyList::get_item_unchecked
for PyPy, so I added it.