3211: Enable v2 resolver on the workspace to enable dropping PYO3_CI workaround r=davidhewitt a=adamreichold
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
3210: Drop the xtask helper as it is superseded by Nox. r=davidhewitt a=adamreichold
While the xtask code base is better engineered than our slightly messy Nox manifest, all functionality is available via Nox including some that is not available via xtask. Finally, only the Nox sessions are used in the CI by now so that xtask does not see regular automated usage.
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
While the xtask code base is better engineered than our slightly messy Nox
manifest, all functionality is available via Nox including some that is not
available via xtask. Finally, only the Nox sessions are used in the CI by now so
that xtask does not see regular automated usage.
3209: Remove the conditional compilation flags which are made redundant by the MSRV bump r=davidhewitt a=adamreichold
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
3203: support ordering magic methods for `#[pyclass]` r=adamreichold a=davidhewitt
Closes#2089
This adds `__lt__`, `__le__`, `__eq__`, `__ne__`, `__gt__`, and `__ge__` as per the Python implementations of what we call `__richcmp__`.
There's a UI test confirming that the user cannot implement split forms and `__richcmp__` simultaneously.
There's also a benchmark comparing implementing these split methods against using `__richcmp__`. I couldn't see a meaningful performance difference, so I'm tempted to deprecate `__richcmp__`, given that's not a magic method which exists in Python. Potentially we can provide options such as the opt-in `#[pyclass(eq, ord)]` to avoid boilerplate for people who don't want to implement six different methods.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
3208: bump msrv to 1.56 r=davidhewitt a=davidhewitt
The MSRV changes from #3204, plus a commit which should hopefully make CI pass.
With luck this is mergeable and resolves CI pain while we decide what to do about the Python version.
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
3200: RFC: remove copyright headers from source files r=davidhewitt a=davidhewitt
As part of our relicensing effort - I've observed that over time we haven't applied COPYRIGHT headers consistently to source files.
I've seen different organisations take different approaches to this. I note that for [`rust-lang/rust`, headers only exist where code has been moved inside the Rust repo without relicensing](https://github.com/search?q=repo%3Arust-lang%2Frust+copyright+language%3ARust&type=code&l=Rust).
For PyO3, I suggest we follow this and remove COPYRIGHT headers from source. We may wish to consider attributing to `rust-cpython` as the original project from which PyO3 was forked, possibly in the License section of the readme?
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
3198: Add abi3 + num_bigint conversion r=davidhewitt a=youknowone
<!--
Please consider adding the following to your pull request:
- an entry for this PR in newsfragments - see [https://pyo3.rs/main/contributing.html#documenting-changes]
- docs to all new functions and / or detail in the guide
- tests for all new or changed functions
PyO3's CI pipeline will check your pull request. To run its tests
locally, you can run ```cargo xtask ci```. See its documentation
[here](https://github.com/PyO3/pyo3/tree/main/xtask#readme).
-->
Fix#3196
Co-authored-by: Jeong YunWon <jeong@youknowone.org>
3185: Fix `abi3` conversion of `__complex__` classes r=adamreichold a=jakelishman
Python classes that were not `complex` but implemented the `__complex__` magic would have that method called via `PyComplex_AsCComplex` when running against the full API, but the limited-API version `PyComplex_RealAsDouble` does not attempt this conversion. If the input object is not already complex, we can call the magic before proceeding.
Happy to modify if I've made a mess of testing strategy - I'm not sure I've managed to do it in the same style as other tests.
Fix#3164.
Co-authored-by: Jake Lishman <jake.lishman@ibm.com>
3199: update PR template to detail state of licensing r=davidhewitt a=davidhewitt
Adds detail about #3108 to the README and the PR template.
`@DataTriny` - I thought that adding this would help encourage new contributors to be aware of the licensing terms and also that they would need to explicitly accept the future license.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
Python classes that were not `complex` but implemented the `__complex__`
magic would have that method called via `PyComplex_AsCComplex` when
running against the full API, but the limited-API version
`PyComplex_RealAsDouble` does not attempt this conversion. If the input
object is not already complex, we can call the magic before proceeding.
`PyAny::lookup_special` is an approximate equivalent to the CPython
internal `_PyObject_LookupSpecial`, which is used to resolve lookups of
"magic" methods. These are only looked up from the type, and skip the
instance dictionary during the lookup. Despite this, they are still
required to resolve the descriptor protocol.
Many magic methods have slots on the `PyTypeObject` or respective
subobjects, but these are not necessarily available when targeting the
limited API or PyPy. In these cases, the requisite logic can be worked
around using safe but likely slower APIs.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
Fix up lookup-special
3187: release: 0.19.0 r=davidhewitt a=davidhewitt
As per #3154 I think we're ready to push 0.19.
I'll put this live on Tuesday evening unless I hear a reason to postpone.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
3188: Verify that macros do work without any imports r=adamreichold a=lifthrasiir
Currently virtually all (positive) tests import `pyo3::prelude::*`, making it hard to detect a certain class of bugs. This PR adds an explicit test that never imports from `pyo3` to fix this.
Also this fixes a minor bug from #3157 which didn't work without `use pyo3::types::PyType;`. I think this should be a part of 0.19.0 (#3187), so no additional changelog would be required (as this feature is new in 0.19.0).
Co-authored-by: Kang Seonghoon <public+git@mearie.org>
