On 1/29/2018 1:55 AM, Yury Selivanov wrote:
On Mon, Jan 29, 2018 at 1:36 AM Nick Coghlan <ncogh...@gmail.com
<mailto:ncogh...@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.
_______________________________________________
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
