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