Skip to content

Document stability of ABI resulting from the private API #102313

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

Closed
wants to merge 1 commit into from

Conversation

FFY00
Copy link
Member

@FFY00 FFY00 commented Feb 28, 2023

Minor clarification regarding ABI stability.

Signed-off-by: Filipe Laíns <lains@riseup.net>
@encukou
Copy link
Member

encukou commented Feb 28, 2023

It's good practice for CPython core devs to not break this ABI, for various reasons (including non-obvious ones -- it's hard to tell what's breaking, the API/ABI boundary is very unclear in non-C languages, etc.).
But I'd rather not make this promise externally.

Patch releases are already reserved for bugfixes -- they should get the smallest change necessary to fix a bug.

@FFY00
Copy link
Member Author

FFY00 commented Feb 28, 2023

That begs the question, then, should binary distributions (wheels) that are built using private API add any dependency constraint regarding the CPython interpreter version they are compatible with?

It seems like the answer is that it doesn't happen enough for us to bother doing it and having to deal with its implications, so we just ignore it and hope for the best. I personally really don't like this answer, but there I don't think there's much I can do, fixing this basically means breaking the world.

Is there anything the CPython upstream can do to alleviate this? Perhaps we could version the ABI in patch releases, keeping the same commitment that it would only change when really necessary, but still allowing binary packages to accurately represent their compatibility. Or a more complex but more stable approach, we could have a registry of the ABI symbols that changed, that way only the objects that use the affected symbol need to be rebuilt.

@encukou
Copy link
Member

encukou commented Feb 28, 2023

That begs the question, then, should binary distributions (wheels) that are built using private API add any dependency constraint regarding the CPython interpreter version they are compatible with?

They shouldn't be using private API. It's private.
That won't happen overnight, but before it does, it's IMO better to treat Cython as an exception than to standardize what Cython does.

Is there anything the CPython upstream can do to alleviate this?

Yes, provide better public API. Potentially in the new unstable C API tier.

are private API that can change without notice even in patch releases.
are private API that can change without notice even in patch releases. ABI
resulting from it, however, should stay stable across patch versions, unless
there's critical reason to break compatibility (eg. security issue).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tiny note: You could make the sentence start on the next line, to avoid «touching» the existing line 22 and changing the git blame info for it.

This is minor here, but for other PRs in general it’s good to avoid changing (like re-wrapping) lines that don’t have content changes, so that git history stays useful for future investigations.

@hugovk hugovk removed the needs backport to 3.10 only security fixes label Apr 7, 2023
@encukou
Copy link
Member

encukou commented Feb 13, 2024

This is not a minor clarification, so I'll close it.
The PEP-731 C API workgroup is having a lively discussion on this and similar topics. Watch Discourse for a public summary, proposal and call for comments.

Meanwhile, let's try to be nice to our users, but this is not a guarantee we can give.

@encukou encukou closed this Feb 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants