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.
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