PEP 795: Add deep immutability to Python

[blhsing (Ben Hsing)]

Have you considered my suggested consenting-adult approach of limiting the recursion to only the subordinates of an object being frozen to make the proposal a lot less prone to freezing unintended objects?

@jsbueno

Other than rejecting class freezing outright, I’d pursue the proxy idea: That is, instead of eagerly freezing everything in a subject graph, guard the attribute/item retrievals on a frozen object so that nested items are either lazily frozen, or retrieved as a “frozen proxy” (which seems suitable for classes) - in this scenario, a 'frozen proxy" for a class would have the same guards.

It’s hard for me to imagine how a proxy approach can work when a proxy object cannot possibly be of the same type as the actual object. It may be able to behave like the actual object, but it will fail if its exact type is checked on or if direct access to a slot of the actual object is needed.

@ZeroIntensity

@steve.dower

Was there any discussion of an immutable proxy alternative?

Yeah, I think this is a much more robust approach, because the wrapped object doesn’t even have to be immutable, or follow strict Py_CHECKWRITE contracts. Immutability is nice sometimes, but you still generally want some shared data between threads. Several months ago, I threw together a POC for this exact idea with subinterpreters via an immortal object proxy. There are definitely some issues with it, but I think this PEP doing something similar would play better with the ecosystem (particularly because you wouldn’t need to modify every C type out there).

Thanks for the POC. I haven’t spent time looking into the implementation, but can you quickly brief me at a high level on how for example a proxy dict can work with, say, PyDict_GetItem? Does PyDict_GetItem need to be modified such that it will obtain the actual object first if it finds that the object passed in is a proxy?