On 5 February 2018 at 08:31, Guido van Rossum <gu...@python.org> wrote: > On Sun, Feb 4, 2018 at 11:59 AM, Chris Barker - NOAA Federal > <chris.bar...@noaa.gov> wrote: >> >> I think the folks that are concerned about this issue are quite right >> — most Python users equate immutable and hashable—so the dataclass API >> should reflect that. > > Since they are *not* equivalent (consider a tuple containing a list) I'm not > at all convinced that any API in the core language should "reflect" this > misconception, depending on how you meant that.
Lists are themselves mutable, and hence inherently unhashable. Tuples are themselves immutable, and hence hashable if their contents are. I interpret Chris's comment as saying that data classes should behave the same way that the builtin container types do: * if the data class itself is mutable (frozen=False, comparable to list, dict, set), then it is *not* hashable (unless you explicitly implement __hash__) * if the data class itself is immutable (frozen=True, comparable to tuple or frozenset), then whether or not it is hashable depends on whether or not the field values are hashable. It's the ability to ask the interpreter to guess what you mean "frozen=False, hash=True" that creates the likelihood of confusion. Whereas if we leave out the "hash=True" option entirely, then the most natural way to obtain a partially-mutable record, which has a fixed comparison key and selectively mutable state, then the recommended way of handling that would be through containment, where the mutable state is moved out to a subrecord that gets excluded from hashes and comparisons. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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