> > On Sun, Feb 4, 2018, 9:50 PM Guido van Rossum <guido at python.org > <https://mail.python.org/mailman/listinfo/python-dev>> wrote: > > Looks like this is turning into a major flamewar regardless of what I say. > :-( > I really don't want to lose the ability to add a hash function to a > mutable dataclass by flipping a flag in the decorator. I'll explain below. > But I am fine if this flag has a name that clearly signals it's an unsafe > thing to do. > > I propose to replace the existing (as of 3.7.0b1) hash= keyword for the > @dataclass decorator with a simpler flag named unsafe_hash=. This would be > a simple bool (not a tri-state flag like the current hash=None|False|True). > The default would be False, and the behavior then would be to add a hash > function automatically only if it's safe (using the same rules as for > hash=None currently). With unsafe_hash=True, a hash function would always > be generated that takes all fields into account except those declared using > field(hash=False). If there's already a `def __hash__` in the function I > don't care what it does, maybe it should raise rather than quietly doing > nothing or quietly overwriting it. > > Here's my use case. > > May be it is better to provide a special purpose function `make_unsafe_hash` in dataclass module which will patch a dataclass, instead of to clutter @dataclass API with arguments which are rather special case.
This `unsafe_hash` argument will constantly raise questions among ordinary users like me, and will be possibly considered as a non-obvious design - there is a public API but it is somehow unsafe. On the other hand, with a function, when the user asks how to make a `frozen=False` dataclass hashable, you can suggest to use this `make_unsafe_hash` function with all its cautions in its docs or to try to implement __hash__ by yourself. Also taking into account the Python approach for backward compatibility it is better to stick with function and if it will be usefull to add a `unsafe_hash` argument in Python 3.8. It is easier to add later than to deprecate in the future. With kind regards, -gdg
_______________________________________________ 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