RetroSearch Browse

Fri Feb 2 00:33:04 EST 2018 · https://mail.python.org/pipermail/python-dev/2018-February/152053.html

On 2 February 2018 at 11:49, Elvis Pranskevichus <elprans at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2018-February/152053.html below:

[Python-Dev] Dataclasses and correct hashability