A RetroSearch Logo

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

Search Query:

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

[Python-Dev] unfrozen dataclasses and __hash__ (subsets are OK)

[Python-Dev] unfrozen dataclasses and __hash__ (subsets are OK) [Python-Dev] unfrozen dataclasses and __hash__ (subsets are OK)Jim J. Jewett jimjjewett at gmail.com
Sun Feb 4 23:42:01 EST 2018
I understand auto-generating the __hash__ (and __eq__) for a frozen
container; that is just convenient.

But why is there any desire to autogenerate a __hash__ for something
that isn't frozen?  Like a list or dict, the normal case would be for
it not to have a hash at all, and the author *should* write out any
explicit exceptions.

The objection to that seems to be that someone might forget to add
another field to the hash during later maintenance -- but so what?

__hash__ should reference a subset of the fields used for equality,
and strict subsets are OK.  It *should* ignore some fields if that
will provide the right balance between quick calculation and
sufficient dispersion.  If the record is complicated enough that
forgetting a field is a likely problem, then the hash is probably
already sufficiently complex without those new fields.

 -jJ
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4