As a user who has been following (if not comprehensively this thread) and followed the subinterpreters work before, I just want to add my opinion, which is that I’m super excited about the potential of this proposal and the overall direction your group is heading, and I think having some version of deep immutability + sharing across interpreters would be a major improvement to Python.
There’s one caveat, which is that while the capability is the first piece, making sure it can be used with popular libraries and getting them to adopt it is necessary to have true impact. e.g. if extension types need to opt-in to freezing, how will you make it easy for extension authors to do so - otherwise you will end up in a similar position as subinterpreters themselves are currently, where one generally can’t even attempt to use well-known extensions because they/their binding generators don’t support it.
Beyond that position, I’ll add what I see as a key response to some counterarguments here. There’ve been statements like: “you can avoid data race problems if you just don’t mutate things”. That’s true in theory, but in practice we have to consider that most Python code is a highly interconnected graph combining objects & functions from many 3rd-party libraries. If I create and know that I have the only references to val and am only touching it with my code, I can just not mutate it. But when I pass it to a function from some library, how do I know whether or not it will mutate it? If I’m using their class, how do I know it doesn’t depend on some module global state which could get updated somewhere I don’t notice? What if the class is designed so that mutating instances is how they’re normally used? What if I write a library which supports a callbacks API, so that when it’s used I have no idea what user code is doing? My point is, ensuring nothing risky happens across all these libraries, when every object is a reference and you don’t know what else references the same object or what threads those references are used in, requires impractical amounts of coordination and developer effort. Language support is important because it enforces guarantees across that whole object graph.
Anyway, I’m looking forward to seeing this materialize further.