Document stability of ABI resulting from the private API #102313
Conversation
Signed-off-by: Filipe Laíns <lains@riseup.net>
FFY00
added
docs
|
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.). Patch releases are already reserved for bugfixes -- they should get the smallest change necessary to fix a bug. |
|
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. |
They shouldn't be using private API. It's private.
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). |
There was a problem hiding this comment.
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.
|
This is not a minor clarification, so I'll close it. Meanwhile, let's try to be nice to our users, but this is not a guarantee we can give. |
Minor clarification regarding ABI stability.