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.
@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
