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.


Python-Dev mailing list

Reply via email to