These are good points. I think the proposal is trying too hard to make an object truly immutable when for all practical purposes it is wholly unnecessary.
In almost all legitimate real-world use cases I can think of, barring instance registries and caches, classes and module globals are altered only during initialization. Once they start spawning instances ready for concurrency, modifying classes and modules would be considered monkey-patching and a bad practice.
In other words, I think we should limit the scope of the proposal such that freezing an instance does not freeze its class, freezing a class does not freeze its bases, and freezing a function does not freeze its globals and builtins, at least by default.
To quote dataclasses’s documentation on so-called Frozen Instances:
It is not possible to create truly immutable Python objects. However, by passing
frozen=Trueto the@dataclassdecorator you can emulate immutability. In that case, dataclasses will add__setattr__()and__delattr__()methods to the class. These methods will raise aFrozenInstanceErrorwhen invoked.
So by the philosophy of a consenting adult we should leave it up to the developer to ensure that best practice is followed, that no monkey-patching business is going on.
I hope this pragmatic approach would make it easier for this proposal to move forward.