On Friday, February 2, 2018 12:33:04 AM EST Nick Coghlan wrote: > For 3.7, I think we should seriously considered just straight up > disallowing the "hash=True, frozen=False" combination, and instead > require folks to provide their own hash function in that case. > "Accidentally hashable" (whether by identity or field hash) isn't a > thing that data classes should be allowing to happen. > > If we did that, then the public "hash" parameter could potentially > be dropped entirely for the time being - the replacement for > "hash=True" would be a "def __hash__: ..." in the body of the class > definition, and the replacement for "hash=False" would be "__hash__ > = None" in the class body.
I think "frozen=True" should just imply hashability (by fields). You can always do "__hash__ = None" to opt out. I don't see the default hashability of an immutable object as a problem. tuples and frozensets are hashable after all. Elvis _______________________________________________ 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