[Python-Dev] Is static typing still optional? (original) (raw)
Eric V. Smith eric at trueblade.com
Mon Jan 29 02:52:41 EST 2018
- Previous message (by thread): [Python-Dev] Is static typing still optional?
- Next message (by thread): [Python-Dev] Is static typing still optional?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message (by thread): [Python-Dev] Is static typing still optional?
- Next message (by thread): [Python-Dev] Is static typing still optional?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]