On 2/1/2018 8:29 PM, Elvis Pranskevichus wrote:
On Thursday, February 1, 2018 8:21:03 PM EST Eric V. Smith wrote:
I should add: This is why you shouldn't override the default
(hash=None) unless you know what the consequences are. Can I ask
why you want to specify hash=True?
hash=None and compare=True leads to the same result, which, I think is
even worse.
Have you actually tried that?
>>> @dataclass(hash=None)
... class A:
... foo: int = field(hash=True, compare=True)
...
>>> hash(A(2))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'A'
I believe the default hash=None on the class decorator does right thing.
Please provide a counter-example.
>> You're allowed to override the parameters to dataclasses.dataclass
>> for cases where you know what you're doing. Consenting adults,
>> and all.
>
> I don't agree with this. You are comparing implicit dataclass
> behavior with an explicit shoot-in-the-foot __hash__() definition.
I don't recommend ever specifying the decorator hash= parameter unless
you have an unusual use case, in which case it's on you to get it right.
There was recently a long python-dev discussion on this issue. I need to
update the PEP to reflect it, but the advice still stands: you almost
always want to use the default hash=None.
Do you have a use case for specifying a hash function on a class with
mutable instances? Maybe you want frozen=True?
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
