On 2/22/18 9:43 PM, Nick Coghlan wrote:
On 22 February 2018 at 20:55, Eric V. Smith <e...@trueblade.com> wrote:
A related issue is that dataclasses derived from frozen dataclasses are
automatically "promoted" to being frozen.

... class A:
...     i: int
... 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
    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.

Python-Dev mailing list

Reply via email to