PEP 803: Stable ABI for Free-Threaded Builds #4556
Conversation
peps/pep-0803.rst
Outdated
| that is, only a subset of the functions, structures, etc. that CPython | ||
| exposes. | ||
| The limited API is versioned, and building against Limited API 3.X | ||
| yields an extension that is ABI-compatible with CPython 3.X *and above* (modulo |
There was a problem hiding this comment.
Not sure what "modulo bugs" means in this sentence.
| However, CPython will add a line of defense against outdated or misconfigured | ||
| tools, or human mistakes, in the form of a new *module slot* containing | ||
| basic ABI information. |
There was a problem hiding this comment.
| However, CPython will add a line of defense against outdated or misconfigured | |
| tools, or human mistakes, in the form of a new *module slot* containing | |
| basic ABI information. | |
| However, CPython will help defend against outdated or misconfigured | |
| tools, or human mistakes, in the form of a new *module slot* containing | |
| basic ABI information. |
There was a problem hiding this comment.
I think my wording better suggests that we're adding a distinct mechanism.
| This information will be checked when a module is loaded, and incompatible | ||
| extensions will be rejected. |
There was a problem hiding this comment.
| This information will be checked when a module is loaded, and incompatible | |
| extensions will be rejected. | |
| Checks will be done when a module is loaded, and incompatible | |
| extensions will be rejected. |
There was a problem hiding this comment.
I'd like to say which information is checked (with “this” referring to the previous sentence).
| Projects that need this can build separate extensions specifically for | ||
| the 3.14 free-threaded interpreter, and for older stable ABI versions. | ||
|
|
||
| API changes are OK |
There was a problem hiding this comment.
That's what the next sentence says. Do you think the 4 words don't make sense as a heading?
| This information will be checked when a module is loaded, and incompatible | ||
| extensions will be rejected. |
There was a problem hiding this comment.
I'd like to say which information is checked (with “this” referring to the previous sentence).
| However, CPython will add a line of defense against outdated or misconfigured | ||
| tools, or human mistakes, in the form of a new *module slot* containing | ||
| basic ABI information. |
There was a problem hiding this comment.
I think my wording better suggests that we're adding a distinct mechanism.
| Users -- or rather the tools they use for building and installing extensions -- | ||
| will continue to be responsible for not putting incompatible extensions on | ||
| Python's import paths. |
There was a problem hiding this comment.
The tools can only be responsible for their own actions; they're not expected to prevent anything else from messing things up.
| - :c:type:`!PyModuleDef_Base` | ||
| - :c:type:`PyModuleDef` | ||
|
|
||
| - no longer include the following macros: |
There was a problem hiding this comment.
I'd like to keep the current wording if you don't mind.
AFAIK, “exclude” sounds more like “prevent from being included” or “expel” than a passive “not include”. (And a few dictionaries I checked at least put the definitions in this order.)
Co-authored-by: Carol Willing <[email protected]> Co-authored-by: Jelle Zijlstra <[email protected]>
Basic requirements (all PEP Types)
pep-NNNN.rst), PR title (PEP 123: <Title of PEP>) andPEPheaderAuthororSponsor, and formally confirmed their approvalAuthor,Status(Draft),TypeandCreatedheaders filled out correctlyPEP-Delegate,Topic,RequiresandReplacesheaders completed if appropriate.github/CODEOWNERSfor the PEPStandards Track requirements
Python-Versionset to valid (pre-beta) future Python version, if relevantDiscussions-ToandPost-History📚 Documentation preview 📚: https://pep-previews--4556.org.readthedocs.build/