[Python-Dev] Dataclasses and correct hashability
Guido van Rossum
guido at python.org
Tue Feb 6 15:24:54 EST 2018
On Tue, Feb 6, 2018 at 11:40 AM, Ethan Furman <ethan at stoneleaf.us> wrote:
> It sounds like `unsafe_hash=True` indicates a truly unsafe hash (that is,
> mutable data is involved in the hash calculation), but there still seems to
> be one possibility for an "unsafe_hash" to actually be safe -- that is, if
> only immutable fields are used in __eq__, then dataclass could safely
> generate a hash for us.
>
> Do we have a way to know if the equality fields are hashable? I suppose
> we could check each one for a for a non-None __hash__. Then we could
> modify that first condition from
>
> - frozen=True
>
> to
>
> - frozen=True or all(getattr(eq_fld, '__hash__', None) is not None for
> eq_field in equality_fields)
>
There seems to be a misunderstanding underlying these questions. Even if
all fields have an immutable type (e.g. all ints, supporting __eq__ and
__hash__), if the containing class isn't frozen, they can be assigned to.
E.g.
@dataclass()
class Point:
x: int
y: int
p = Point(1, 1)
p.x = 2 # This is legal
The only way to make that assignment to p.x illegal is to make the *class*
frozen (using @dataclass(frozen=True)) -- nothing we can do about the
*field* will change this.
Of course if you use @dataclass(frozen=True, unsafe_hash=True) you may
still get a safe hash. :-)
--
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180206/3b1133a7/attachment.html>
More information about the Python-Dev
mailing list