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~
_______________________________________________
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
