# Adding Deep Immutability

**URL:** <https://discuss.python.org/t/adding-deep-immutability/92011>\
**Category:** Ideas\
**Created:** [May 14, 2025, 9:27pm UTC](https://discuss.python.org/t/adding-deep-immutability/92011 "2025-05-14T21:27:34Z")\
**Posts on this page:** 1\
**Showing post:** 97

<div class="post-metadata">

**Author:** ![blhsing](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/blhsing/32/25812_2.png) [@blhsing](https://discuss.python.org/u/blhsing)\
**Post date:** [May 27, 2025, 9:27am UTC](https://discuss.python.org/t/adding-deep-immutability/92011/97 "2025-05-27T09:27:21Z")

</div>

> [@MegaIng](#):
>
> I don’t think trying to freeze function is ever going to be successful. Here a minimal example that bypasses the frozeness with the current reference implementation:
> 
> ```python
> def counter():
> __import__ # Needed because `import` doesn't work otherwise
> import sys
> sys.counter += 1
> 
> return sys.counter
> 
> ```

> [@oscarbenjamin](#):
>
> Yes, but realistically how far does that go? If you freeze `a` then you need to freeze the globals used by `a` but then those are types from other modules and you need to freeze the globals in those modules and so on. Literally for the particular case of `a` that I showed above, is `a` freezable and what is the full set of things that would need to be frozen as part of `freeze(a)`?

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](https://docs.python.org/3/library/dataclasses.html#frozen-instances):

> **It is not possible to create truly immutable Python objects.** However, by passing `frozen=True` to the [`@dataclass`](https://docs.python.org/3/library/dataclasses.html#dataclasses.dataclass) decorator you can emulate immutability. In that case, dataclasses will add [` __setattr__ ()`](https://docs.python.org/3/reference/datamodel.html#object. __setattr__ ) and [` __delattr__ ()`](https://docs.python.org/3/reference/datamodel.html#object. __delattr__ ) methods to the class. These methods will raise a [`FrozenInstanceError`](https://docs.python.org/3/library/dataclasses.html#dataclasses.FrozenInstanceError) when 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.

---

_[View the full topic](https://discuss.python.org/t/adding-deep-immutability/92011)._