On 2 February 2018 at 11:49, Elvis Pranskevichus <elpr...@gmail.com> wrote: > In my experience this type of breakage is so subtle that people will > happily write code lots of code like this without noticing. My main > objection here is that the dataclass does not go far enough to prevent > obviously wrong behaviour. Or it goes too far with the whole hash/ > frozen distinction.
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. 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