To add a counter-example that I'm painfully familiar with: the old Thrift for Python makes its (mutable) structures hashable. This is "useful" because you can memoize functions that take Thrift structures as arguments. You can key dictionaries with them. And so on.
Unfortunately, more often then not this same structure is passed around and inevitably gets mutated in place. Everything breaks. What should be memoized isn't (and in pathological cases, what shouldn't be memoized is), dictionary access *using the same object* raises unexpected key errors but iterating on the dictionary reveals the key. It's clearly clowntown and in hindsight we shouldn't have enabled this behavior. But we can't go back since too much code relies on hashability now and it's "mostly" fine. As a solution, the new asyncio-only Thrift implementation for Python uses C-level structures to make sure they are truly immutable in Python. We hash them and cache them like there's no tomorrow. - Ł > On Feb 5, 2018, at 11:54 PM, Ivan Levkivskyi <levkivs...@gmail.com> wrote: > > Just wanted to add my 5 cents here. I am a bit surprised how people are > scared by adding `__hash__` to mutable classes. > From my experience it is quite normal, I was always thinking about `hash()` > as hashing a _value_, > and never as hashing _identity_, if I would need the latter, there is a > different function for this, `id()`. > Moreover, I often did this in situations where dataclasses would be useful: a > class with several fields, > necessary dunders, and few other methods (record-like classes). > My motivation was mostly speed-up by memorization. > To be fair my use cases were mostly about some tree-like strictures, but this > is probably a coincidence. > > FWIW it is not a super-safe practice, but neither super-dangerous. > > -- > Ivan > > > > On 5 February 2018 at 22:56, Nick Coghlan <ncogh...@gmail.com > <mailto:ncogh...@gmail.com>> wrote: > On 6 February 2018 at 03:47, Guido van Rossum <gu...@python.org > <mailto:gu...@python.org>> wrote: > > If there's going to be an API for it, it should be in the class, not > > something that mutates the class afterwards. > > Something I realised after posting the __class__ setting idea is that > you can actually use a comparable trick to inject an unsafe hash from > the frozen version into the mutable version: > > >>> from dataclasses import dataclass > >>> @dataclass > ... class Example: > ... a: int > ... b: int > ... > >>> c = Example(1, 2) > >>> hash(c) > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > TypeError: unhashable type: 'Example' > > >>> @dataclass(frozen=True) > ... class LockedExample(Example): > ... pass > ... > >>> Example.__hash__ = LockedExample.__hash__ > >>> hash(c) > 3713081631934410656 > > So "unsafe_hash=True" would just be a shorthand spelling of that which > skips creating the full frozen version of the class (and with the > explicit parameter, we can better document the risks of making > something hashable without also freezing it post-creation). > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com <mailto:ncogh...@gmail.com> | > Brisbane, Australia > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org <mailto:Python-Dev@python.org> > https://mail.python.org/mailman/listinfo/python-dev > <https://mail.python.org/mailman/listinfo/python-dev> > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/levkivskyi%40gmail.com > <https://mail.python.org/mailman/options/python-dev/levkivskyi%40gmail.com> > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org <mailto:Python-Dev@python.org> > https://mail.python.org/mailman/listinfo/python-dev > <https://mail.python.org/mailman/listinfo/python-dev> > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/lukasz%40langa.pl > <https://mail.python.org/mailman/options/python-dev/lukasz%40langa.pl>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ 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
