As a Bear of Relatively Little Brain, I've grown up understanding, and teaching, that mutable things aren't to be used as dict keys. I'm aware that immutability isn't strictly the required condition, but it for most people, that's the primary reason for using frozen sets and tuples, for example, and immutability serves as a practical and comprehensible first approximation. So I'm at a loss to understand why I am being offered a feature that (especially during maintenance by a different developer) might be prone to bizarre errors caused by a change in hash.
I realise that this won't happen very often, but the difficulty of the debug task should surely merit at least some warning for us bears - you know, the ones that take your work and use it to do mundane things with. On a slightly tangential note, us bears are very glad that such questions are taken seriously and discussed in such depth. Thank you all. Steve Holden On Sat, Feb 3, 2018 at 6:44 AM, Guido van Rossum <gu...@python.org> wrote: > It appears Eric and I are the only ones in favor of keeping the current > behavior. But I still am not convinced by all the worries about "attractive > nuisances" and all the other bad names this feature has been called. We > don't know that any of the doomsday scenarios will happen. In my > experience, usually once something is rolled out the set of issues that are > *actually* raised is entirely different from the things its designers were > worried about. > > Please don't commit a change to roll this back without checking in with > me; I have some misgivings about the problem being raised here that I still > need to think through more carefully. In the meantime, please try to use > dataclasses with 3.7b1! > > On Fri, Feb 2, 2018 at 10:25 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > >> >> >> On 3 Feb. 2018 1:09 am, "Eric V. Smith" <e...@trueblade.com> wrote: >> >> >> The problem with dropping hash=True is: how would you write __hash__ >> yourself? It seems like a bug magnet if you're adding fields to the class >> and forget to update __hash__, especially in the presence of per-field >> hash=False and eq=False settings. And you'd need to make sure it matches >> the generated __eq__ (if 2 objects are equal, they need to have the same >> hash value). >> >> >> I think anyone that does this needs to think *very* carefully about how >> they do it, and offering both "hash=True" and "frozen=True" is an >> attractive nuisance that means people will write "hash=True" when what they >> wanted was "frozen=True". >> >> In particular, having to work out how write a maintainable "__hash__" >> will encourage folks to separate out the hashed fields as a separate frozen >> subrecord or base class. >> >> If this proves to be an intolerable burden then the short hand spelling >> could be added back in 3.8, but once we ship it we're going to be stuck >> with explaining the interactions indefinitely. >> >> Cheers, >> Nick. >> >
_______________________________________________ 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
