On Fri, Feb 2, 2018 at 10:51 AM, Paul Moore <p.f.mo...@gmail.com> wrote: [..] > To put it another way, using your words above, "The moment you want to > use a dataclass a a dict key, or put it in a set, you need it to be > *immutable*" (not hashable, unless you really know what you're doing).
Can someone clarify what is the actual use case of someone *knowingly* making a mutable collection hashable? Why can't that advanced user write their own __hash__ implementation? It's easy to do so. For what it's worth I think this argument is being blindly used to justify the current questionable design of "dataclass(hash=True)" being the same as "dataclass(hash=True, frozen=False) case. At least a few other core developers are concerned with this, but all I see is "attrs does the same thing". Eric, in my opinion we shouldn't copy attrs. It was designed as an external package with its own backwards-compatibility story. At some point it was realized that "attrs(hash=True, frozen=False)" is an anti-pattern, but it couldn't be removed at that point. Hence the warning in the documentation. We can do better. We are designing a new API that is going to be hugely popular. Why can't we ship it with dangerous options prohibited in 3.7 (it's easy to do that!) and then enable them in 3.8 when there's an actual clear use case? Yury _______________________________________________ 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
