<div dir="ltr">Where do you get the impression that one would have to explicitly request __hash__ if frozen=True is set? To the contrary, my proposal is for @dataclass to automatically add a __hash__ method when frozen=True is set. This is what the code currently released as 3.7.0b1 does if hash=None (the default).<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 6, 2018 at 9:26 AM, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</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 Mon, Feb 05, 2018 at 10:50:21AM -0800, David Mertz wrote:<br>
<br>
> Absolutely I agree. 'unsafe_hash' as a name is clear warning to users.<br>
<br>
</span>(I don't mean to pick on David specifically, I had to reply to some<br>
message in this thread and I just picked his.)<br>
<br>
I'm rather gobsmacked at the attitudes of many people here about hashing<br>
data classes. I thought *I* was the cynical pessimist who didn't have a<br>
high opinion of the quality of the average programmer, but according to<br>
this thread apparently I'm positively Pollyanna-esque for believing that<br>
most people will realise that if an API offers separate switches for<br>
hashable and frozen, you need to set *both* if you want both.<br>
<br>
Greg Smith even says that writing dunders apart from __init__ is a code<br>
smell, and warns people not to write dunders. Seriously? I get that<br>
__hash__ is hard to write correctly, which is why we have a hash=True to<br>
do the hard work for us, but I can't help feeling that at the point<br>
we're saying "don't write dunders, any dunder, you'll only do it wrong"<br>
we have crossed over to the wrong side of the pessimist/optimist line.<br>
<br>
But here we are: talking about naming a perfectly reasonable argument<br>
"unsafe_hash". Why are we trying to frighten people?<br>
<br>
There is nothing unsafe about a DataClass with hash=True, frozen=True,<br>
but this scheme means that even people who know what they're doing will<br>
write unsafe_hash=True, frozen=True, as if hashability was some sort of<br>
hand grenade waiting to go off.<br>
<br>
Perhaps we ought to deprecate __hash__ and start calling it<br>
__danger_danger_hash__ too? No, I don't think so.<br>
<br>
In the past, we've (rightly!) rejected proposals to call things like<br>
eval "unsafe_eval", and that really is dangerously unsafe when used<br>
naively with untrusted, unsanitised data. Hashing mutable objects by<br>
accident might be annoyingly difficult and frustrating to debug, but<br>
code injection attacks can lead to identity theft and worse, serious<br>
consequences for real people.<br>
<br>
I'm 100% in favour of programmer education, but I think this label is<br>
*miseducation*. We're suggesting that hashability is unsafe, regardless<br>
of whether the object is frozen or not.<br>
<br>
I'd far prefer to get a runtime warning:<br>
<br>
"Are you sure you want hash=True without frozen=True?"<br>
<br>
(or words to that extent) rather than burden all uses of the hash<br>
parameter, good and bad, with the unsafe label.<br>
<br>
<br>
--<br>
Steve<br>
<span class="">______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
</span>Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>guido%40python.org</a><br>
</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></div></div>