[Python-Dev] Should the dataclass frozen property apply to subclasses?

[Eric V. Smith]

On 2/22/18 9:43 PM, Nick Coghlan wrote:
> On 22 February 2018 at 20:55, Eric V. Smith <eric at trueblade.com> wrote:
>> A related issue is that dataclasses derived from frozen dataclasses are
>> automatically "promoted" to being frozen.
>>
>>>>> @dataclass(frozen=True)
>> ... class A:
>> ...     i: int
>> ...
>>>>> @dataclass
>> ... class B(A):
>> ...     j: int
>> ...
>>>>> b = B(1, 2)
>>>>> b.j = 3
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>>   File "C:\home\eric\local\python\cpython\lib\dataclasses.py", line 452, in
>> _frozen_setattr
>>     raise FrozenInstanceError(f'cannot assign to field {name!r}')
>> dataclasses.FrozenInstanceError: cannot assign to field 'j'
>>
>> Maybe it should be an error to declare B as non-frozen?
>
> It would be nice to avoid that, as a mutable subclass of a frozen base
> class could be a nice way to model hashable-but-mutable types:
>
>     >>> @dataclass(frozen=True) # This is the immutable/hashable bit
>     ... class A:
>     ...     i: int
>     ...
>     >>> @dataclass # This adds the mutable-but-comparable parts
>     ... class B(A):
>     ...     j: int
>     ...     __hash__ = A.__hash__
>
>
> However, disallowing this case for now *would* be a reasonable way to
> postpone making a decision until 3.8 - in the meantime, folks would
> still be able to experiment by overriding __setattr__ and __delattr__
> after the dataclass decorator sets them.

Yes, that's what I was thinking. If we can't come up with a good 
solution for this now, make it an error and think about it for 3.8.

I'm doing some experimenting on this and Raymond's case and I'll post 
some ideas this weekend.

Eric