RFC: Make pyclass immutable by default

[mejrs]

In #1979 (review) we discussed that we'd like to have #[pyclass(mutable)], making pyclasses immutable by default and mutability opt-in.

Currently we have #[pyclass(frozen)] where this is the other way around; they are mutable by default.

[davidhewitt]

What's the pathway to getting where we'd like to be? I was actually thinking I'm quite happy with #[pyclass(frozen)] and could have #[pyclass(frozen = false)] be the opt-out.

I think we also haven't yet worked out the exact semantics of the pyclass borrow tracking under the freethreaded Python builds. It might inform some further changes we want to make in this area.

[Stargateur]

I would also add that frozen is not very self-describing about what it does. (At least it wasn't for me, maybe a python thing to call const thing frozen ?)

[JonathanPlasse]

I would also add that frozen is not very self-describing about what it does. (At least it wasn't for me, maybe a python thing to call const thing frozen ?)

Yes, e.g. frozenset and dataclasses.dataclass's frozen parameter.

[gabriel4k2]

Hey I think this will be useful as well to "unblock" (it is not actually blocked but the user will need to have knowledge of such nuances) the usage of the vector call protocol for >=3.12.
I elaborated a little here but I'll summarize and include additional infos:
Basically from 3.12 onwards it is not possible anymore to use the vector call for mutable heap types

Changed in version 3.12: Before version 3.12, it was not recommended for mutable heap types to implement the vectorcall protocol. When a user sets call in Python code, only tp_call is updated, likely making it inconsistent with the vectorcall function. Since 3.12, setting call will disable vectorcall optimization by clearing the Py_TPFLAGS_HAVE_VECTORCALL flag.

For this reason the "Py_TPFLAGS_IMMUTABLE" was proposed.
python/cpython#88074 (comment)

Indeed, you can see in the original issue (88074) that several libraries that were using the vector protocol have been made immutable.

[gabriel4k2]

I can take this issue

[davidhewitt]

@gabriel4k2 this is for immutable class instances, not immutable types, but both are closely related I guess.

For immutable types, I think I'm coming around to the idea that the correct default is to leave classes mutable. It is not uncommon for there to be monkey patching etc and although I don't love it, it is a pattern in Python which has use cases (especially in testing). I'll comment more on #2349.

For instances, I think we need to make a decision what we want the semantics of mutable objects with the free threading build. I will try to think and make a proposal in the coming weeks.