Skip to content

PEP 697: Clean up before PSC acceptance #3041

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Mar 7, 2023
Merged

PEP 697: Clean up before PSC acceptance #3041

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 16 additions & 14 deletions pep-0697.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,10 +15,15 @@ Abstract
========

Add `Limited C API <https://docs.python.org/3.11/c-api/stable.html#stable-application-binary-interface>`__
for extending types with opaque data,
support for extending some types with opaque data
by allowing code to only deal with data specific to a particular (sub)class.

Make the mechanism usable with ``PyHeapTypeObject``.
This mechanism is required to be usable with ``PyHeapTypeObject``.

This PEP does not propose allowing to extend non-dynamically sized variable
sized objects such as ``tuple`` or ``int`` due to their different memory layout
and perceived lack of demand for doing so. This PEP leaves room to do so in
the future via the same mechanism if ever desired.


Motivation
Expand Down Expand Up @@ -218,7 +223,7 @@ This turned out to be hard to explain, and goes against the idea of decoupling
the subclass from the base layout.

The new flag will be used to allow safely extending variable-sized types:
creating a type with ``spec->basesize < 0`` and ``base->tp_itemsize > 0``
creating a type with ``spec->basicsize < 0`` and ``base->tp_itemsize > 0``
will require the flag.

Additionally, this PEP proposes a helper function to get the variable-sized
Expand All @@ -238,10 +243,10 @@ big-picture decision tree.
The individual cases are easier to explain in isolation (see the
:ref:`reference implementation <697-ref-impl>` for draft docs).

* ``spec->basesize > 0``: No change to the status quo. (The base
* ``spec->basicsize > 0``: No change to the status quo. (The base
class layout is known.)

* ``spec->basesize == 0``: (Inheriting the basicsize)
* ``spec->basicsize == 0``: (Inheriting the basicsize)

* ``base->tp_itemsize == 0``: The item size is set to ``spec->tp_itemsize``.
(No change to status quo.)
Expand All @@ -252,7 +257,7 @@ big-picture decision tree.
* ``spec->itemsize > 0``: The item size is set. (This is hard to use safely,
but it's CPython's current behavior.)

* ``spec->basesize < 0``: (Extending the basicsize)
* ``spec->basicsize < 0``: (Extending the basicsize)

* ``base->tp_itemsize == 0``: (Extending a fixed-size class)

Expand Down Expand Up @@ -388,7 +393,7 @@ is set, either on the base or in ``spec->flags``.
(See :ref:`697-var-sized` for a full explanation.)

Extending a class with positive ``spec->itemsize`` using negative
``spec->basesize`` will fail.
``spec->basicsize`` will fail.


Relative member offsets
Expand Down Expand Up @@ -525,13 +530,10 @@ so it's just a theoretical possibility.
Rejected Ideas
==============

None yet.


Open Issues
===========

Is negative basicsize the way to go? Should this be enabled by a flag instead?
Instead of a negative ``spec->basicsize``, a new ``PyType_Spec`` flag could've
been added. The effect would be the same to any existing code accessing these
internals without up to date knowledge of the change as the meaning of the
field value is changing in this situation.


Footnotes
Expand Down