On 22 February 2018 at 20:55, Eric V. Smith <[email protected]> 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.