Conversation
| @@ -0,0 +1,669 @@ | |||
| PEP: 9999 | |||
| Title: Deep Immutability in Python | |||
| Author: Matthew Johnson <matjoh@microsoft.com>, Matthew Parkinson <mattpark@microsoft.com>, Sylvan Clebsch <sylvan.clebsch@microsoft.com>, Fridtjof Peer Stoldt <fridtjof.stoldt@it.uu.se>, Tobias Wrigstad <tobias.wrigstad@it.uu.se> | |||
There was a problem hiding this comment.
TODO: make sure anyone else who wants authorship is added!
| As writes are common but lack a common path that most writes to through | ||
| the PEP requires a ``Py_CHECKWRITE`` call, there are several places in | ||
| the CPython code base that are changed as a consequence of this PEP. | ||
| So far we have identified around 70 writes spread across a dozen files. |
There was a problem hiding this comment.
Would these Py_CHECKWRITE checks be added mainly at the public C API boundary, or are there places where they are required in internal functions as well. The surprisingly low number of 70 makes me think it's the former, but maybe clarifying that here would be helpful.
Things like
assert(Py_CHECKWRITE(op))
in a number of internal places would probably also be helpful for debugging.
| C extensions that define data that is outside of the heap traced by the | ||
| CPython cycle detector should either manually implement freezing by using | ||
| ``Py_CHECKWRITE`` and the ``__freeze__`` hook, or alternatively ensure | ||
| that all accesses to this data is *thread-safe*. |
There was a problem hiding this comment.
My guess is that most of the major C extensions (e.g. Numpy) are storing their data in data structures that they control on the C side. I expect how onerous this is on library authors is likely to be a big point of contention.
EDIT: You already answered my questions below ;)
| The ``Foo`` instance pointed to by ``x`` consists of several objects: its fields are stored in a | ||
| dictionary object, and the assignment ``x.f = 42`` adds two objects to the dictionary in the form | ||
| of a string key ``"f"`` and its associated value ``42``. These objects each have a class pointers | ||
| pointing to the ``string`` and ``int`` classes respectively. Similarly, the ``foo`` instance has |
There was a problem hiding this comment.
| pointing to the ``string`` and ``int`` classes respectively. Similarly, the ``foo`` instance has | |
| pointing to the ``str`` and ``int`` classes respectively. Similarly, the ``foo`` instance has |
| of a string key ``"f"`` and its associated value ``42``. These objects each have a class pointers | ||
| pointing to the ``string`` and ``int`` classes respectively. Similarly, the ``foo`` instance has | ||
| a pointer to the ``Foo`` class. Finally, all these classes have a pointer to the same meta class | ||
| object. |
There was a problem hiding this comment.
What are the implications of freezing the very pervasive built-ins of str and int? It's rare to mutate these, but maybe a GitHub code search could reveal interesting places where people do. Understanding those use cases might be helpful to understand if this would mess with that.
| consistent with current Python semantics or backwards-compatible. | ||
|
|
||
| A reasonable design would make all numbers immutable, not just those | ||
| in the small integer cache. This should be properly investigated. |
There was a problem hiding this comment.
Aren't all numbers already immutable? (They aren't all immortal, but I think they are immutable -- or are you referring to optimizations where the memory is re-used and mutated?)
| Implementation Details | ||
| ====================== | ||
|
|
||
| 1. Introduce an ``is_immutable`` property on objects that tracks whether or |
There was a problem hiding this comment.
I assume "property" here is meant in the abstract sense. To avoid confusion with Python object properties, maybe say "concept"?
| not generalize well to arbitrary objects and adds considerable | ||
| complexity to all code bases. | ||
| 4. Deep freezing immutable copies as proposed in `PEP 351: The | ||
| freeze protocol <https://peps.python.org/pep-0351/>`_. That PEP |
There was a problem hiding this comment.
Getting Barry's (author of PEP 351) advance feedback on this PEP might be helpful.
| @@ -0,0 +1,669 @@ | |||
| PEP: 9999 | |||
There was a problem hiding this comment.
Add section on Backwards compatibility
Co-authored-by: Michael Droettboom <mdboom@gmail.com>
initial PEP draft