[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