[Python-Dev] Is static typing still optional? (original) (raw)

Ethan Furman ethan at stoneleaf.us
Mon Jan 29 04:12:21 EST 2018

On 01/29/2018 12:57 AM, Eric V. Smith wrote:

On 1/29/2018 3:42 AM, Ethan Furman wrote:

On 01/28/2018 07:45 AM, Eric V. Smith wrote:

I think the hashing logic explained in https://bugs.python.org/issue32513#msg310830 is correct. It uses hash=None as the default, so that frozen=True objects are hashable

In a class, _hash_ = None means the instances are not hashable... but in a dataclass decorator, hash=None means they are? It means "don't add a hash attribute, and rely on the base class value". But maybe it should mean "is not hashable". But in that case, how would we specify the "don't add hash" case?

I thought hash=False means don't add a hash method..

Note that "repr=False" means "don't add a repr", not "is not repr-able". And "init=False" means "don't add a init", not "is not init-able".

Yeah, like that.

I get that the default for all (or at least most) of the boring stuff should be "just do it", but I don't think None is the proper place-holder for that. Why not make an _default = object() sentinel and use that for the default? At least for hash. Then we have:

hash=False -> don't add one

hash=None -> add __hash__ = None (is not hashable)

hash=True -> add one (the default...

Okay, after writing that down, why don't we have the default value for anything automatically added be True? With True meaning the dataclass should have a custom whatever, and if the programmer did not provide one the decorator will -- it can even be a self-check: if the parameters in the decorator are at odds with the actual class contents (hash=None, but the class has a hash method) then an exception could be raised.

-- Ethan

More information about the Python-Dev mailing list