[Python-Dev] Is static typing still optional?
Eric V. Smith
eric at trueblade.com
Mon Jan 29 02:52:41 EST 2018
On 1/29/2018 1:55 AM, Yury Selivanov wrote:
>
> On Mon, Jan 29, 2018 at 1:36 AM Nick Coghlan <ncoghlan at gmail.com
> <mailto:ncoghlan at gmail.com>> wrote:
>
> [...]
> Currently the answers are:
>
> - A: not hashable
> - B: hashable (by identity) # Wat?
> - C: hashable (by field hash)
> - D: hashable (by identity) # Wat?
> - E: hashable (by field hash)
> - F: hashable (by field hash)
> - G: hashable (by field hash)
> - H: hashable (by field hash)
>
>
> This is very convoluted.
>
> +1 to make hashability an explicit opt-in.
I agree it's complicated.
I think it would be a bad design to have to opt-in to hashability if
using frozen=True. The point of hash=None (the default) is to try and
get the simple cases right with the simplest possible interface.
It's the intersection of "have simple defaults, but ways to override
them" with "if the user provides some dunder methods, don't make them
specify feature=False in order to use them" that complicated things. For
example, maybe we no longer need eq=False now that specifying a __eq__
turns off dataclasses's __eq__ generation. Does dataclasses really need
a way of using object identity for equality?
Eric.
More information about the Python-Dev
mailing list