<div dir="ltr"><div><div><div><div><div><div><div><div><div>We may be in violent agreement.<br><br></div>I propose *not* to add a way to *disable* hashing when the rest of the flags to @dataclass() would indicate that it's safe to add a __hash__ method.<br><br></div>I propose that with @dataclass(unsafe_hash=False) (the default), a __hash__ method is added when the following conditions are true:<br><br></div>- frozen=True (not the default)<br></div>- compare=True (the default)<br></div>- no __hash__ method is defined in the class<br></div></div><br>If we instead use @dataclass(unsafe_hash=True), a __hash__ will be added regardless of the other flags, but if a __hash__ method is present, an exception is raised.<br><br></div>Other values (e.g. unsafe_hash=None) are illegal for this flag.<br><br></div>Note that the the hash= flag to the field() function is unchanged from what's currently in PEP 557 or in the implementation in 3.7.0b1. In particular, the generated __hash__ method will disregard fields declared using field(hash=False). It will also disregard fields declared using field(compare=False, hash=False|None).<br><div><div><div><div><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 6, 2018 at 10:11 AM, Ethan Furman <span dir="ltr"><<a href="mailto:ethan@stoneleaf.us" target="_blank">ethan@stoneleaf.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/06/2018 09:38 AM, Guido van Rossum wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Where do you get the impression that one would have to explicitly request __hash__ if frozen=True is set? To the<br>
contrary, my proposal is for @dataclass to automatically add a __hash__ method when frozen=True is set. This is what the<br>
code currently released as 3.7.0b1 does if hash=None (the default).<br>
</blockquote>
<br></span>
Which is my issue with the naming -- although, really, it's more with the parameter/argument:  in a hand-written class,<br>
<br>
  __hash__ = None<br>
<br>
means the object in is not hashable, but with the decorator:<br>
<br>
  @dataclass(..., hash=None, ...)<br>
<br>
it means something else.<br>
<br>
My preference for "fixing" the issue:<br>
<br>
1) make the default be a custom object (not None), so that `hash=None`<br>
   means disable hashing<br>
<br>
2) change the param name -- maybe to `add_hash` (I agree with D'Aprano<br>
   that `unsafe_hash` can be misleading)<br>
<br>
--<br>
~Ethan~<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/options/python-dev/guido%<wbr>40python.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>