I think you have seen the justification, which is “threadsafe programming is really hard”. So hard that people have invented new language models to handle it.
You don’t need to be convinced – I’m undecided about it, for whatever my opinion is worth – but I don’t think you’re going to find a much greater depth of explanation here.
Let’s take your example, list.append . I agree with you that anything today which breaks the safety of that code is, itself, fundamentally broken. If you created a list which can’t append, you shouldn’t have made it a list. Convincing isinstance to agree with you is totally facile – today, if it can’t append, it’s not a list.
This proposal changes that. It says that we’re allowed to “deny list” all mutators on an object. That makes it a new and different type for most people’s (and type systems’) purposes, but Python can’t represent it as such. It will have a new “immutable tag” that we can check at runtime.
IANATT[1], but I’m sure the fancy higher order type systems are able to represent this sort of thing.
We can declare that for a codebase which includes freezing, the following snippet is wrong:
if isinstance(l, list):
l.append(1)
It “should be”:
if not isfrozen(l) and isinstance(l, list):
l.append(1)
Code which was correct has been rendered incorrect. That’s to be avoided where possible, but acceptable if there’s a commensurate benefit.
I’m pretty uncertain about how this could all shape up in terms of DX. In the worst case, it becomes difficult for library maintainers because they have no historical contact about immutability and suddenly need to invent one.
How will programmers keep immutable objects from escaping the walled garden in which they were created and meant to be kept? What happens to libraries which assumed they could do things like sorting a list in-place? Their APIs become “not frozen safe”, but what does that look like in reality for under resourced maintainers who won’t even know about this feature until their users file bug reports?
I Am Not A Type Theorist ↩︎