Hi Barry Thank you for your interest in my proposal. Let me try to answer your question. You wrote: To make the code avoid COW you would need to be able to make sure that all
code memory blocks are not mixed in with PyObject memory blocks.
Then the ref count dance will have trigger COW for the code.
The relevant parts of my proposal are (emphasis added) When a Python function is called, the interpreter increases the refcount of
its code object. At the end of the function's execution, the interpreter decreases the refcount. (An example below shows this.)
**If Python were extended to take advantage of permanent code objects**, then for example popular code objects could be loaded into memory in this way. This can reduce memory usage (by sharing immutable resources) and reduce startup time.
I wanted this to mean that if the interpreter needs access to a permanent code object, it simply accesses it, without changing any reference counts. For this reason, permanent code objects don't need a refcount field. And without that field, there is no refcount dance. The interpreter has privileged access to permanent code objects (just as it has to its own internals, unless deliberately exposed). However, the code that is being interpreted has no such access. To enable something like >>> fn.__code__.co_code b'whatever-the-bytecodes-are' Python must have fn.__code__ return something that DOES have a refcount field. It could be some sort of proxy object. Or it could be a 'transient copy' of the permanent code object. I tried to explain this in the Appendix, perhaps not well enough. I hope this helps. -- Jonathan