I mean, if you quote the smallest parts of what I’m saying without reading the full context of them, I think you’re doing the discussion a disservice. Presumably, when someone type hints that A is an int, that’s an actual invariant of the program, and something later on depends on that. Types are currently partially encodable within the type system, and are one part of communicating invariants of the program to each type checkers, users, and tooling built on it.
The expansion of ReadOnly would be extending what invariants can be encoded into the type system, something I am in favor of where it remains theory sound and reasonable to do so, such as here.
I’m not asking for runtime enforcement of typehints at all here, runtime immutability should be designed without a thought for the type system, and instead focus on how it will benefit those who would use the runtime enforcement, such as with preventing concurrency issues. The type system can figure out how to describe that independent of gaining runtime capabilities.
Objects that have an immutable python api can still have mutable internal state such as reference counts, garbage collection links, cached hash values (strings for example), weak reference lists, …
Another issue is that immutable containers can still have references to mutable objects so they aren’t a static as they first appear. Consider a tuple of two lists for example: t = ([], []). The tuple is immutable but its contents can be updated with t[0].append('hello').
Sorry, I didn’t mean to misrepresent what you are saying.
To me there seems to be such a wide gulf between what is permitted by the type system and what is permitted by the runtime that it seems odd to insist that the typing system cannot express immutability unless the runtime can enforce it. I am not saying that that is your position but it seemed to be the consensus here when I stumbled upon this thread.
Ah, okay. I can see how that would be the case. I think a lot has changed in the 3ish months since this thread was revived because the specific way ReadOnly is being proposed for expansion actually has pretty broad support, and has even shifted my view slightly since before that major gap in posts seeing a concrete proposal for it.
I think there’s a few different perspectives, and then some room in between each of those in the typing ecosystem right now, and none of them fully agree. I’m of the opinion that the type system should always accurately reflect runtime when describing runtime constraints, but it’s reasonable to place further conditions beyond what is enforced at runtime in communicating program invariants within the type system. I think actual immutable fields are preferable here because there can be runtime improvements to programs to come with it, but the additional information about dataclass_transform might have led to an unintentionally misleading perspective. It was offered as additional context for some of the reasons that decorator has special treatment, not to suggest that you shouldn’t be able to spell what you need here (which is unfortunately the case unless you “cheat” with type ignores/stub files until either HKTs or the proposal with ReadOnly)