Initial support for abi3t, depends on unreleased PyO3 features.#3113
Initial support for abi3t, depends on unreleased PyO3 features.#3113ngoldbaum wants to merge 9 commits into
Conversation
|
@messense do you have any opinions about how tests for abi3t support should look? My first instinct would be to follow and generalize the existing tests for abi3. Does that sound like a good plan, or do you have large test refactorings in mind separate from this? |
|
Sorry missed the reply in the issue, follow and generalize the existing tests for abi3 sounds good to me. |
Sorry for the delay over here. I just added some new tests. Since abi3t support requires Python 3.15 or newer, I needed to also add some utilities to introspect the Python used by the test runner. |
|
I don't think there are any tests for Python 3.15 yet. @messense what do you think about replacing |
|
I should also note that the new test crates depend on my PR branch for PyO3/pyo3#5807 and I'll need to update them after that PyO3 PR is merged and PyO3 does a release. Not quite sure how to sequence landing everything. |
| /// minimum version. Version‑specific fallback builds (e.g. Python 3.10 when | ||
| /// abi3 targets ≥ 3.11) return `false` so that `Py_LIMITED_API` is not | ||
| /// defined and interpreter‑specific linker names are used. | ||
| pub fn is_abi3_for_interpreter(&self, interpreter: &PythonInterpreter) -> bool { |
There was a problem hiding this comment.
Where does this function end up being needed over is_stable_abi_for_interpreter?
3 participants
This depends on a non-existent abi3t-py315 feature in PyO3, which I'm intending to add as soon as I can. Opening as a draft for now.
Thankfully with #3110 merged, this PR is almost trivial.