If there's going to be an API for it, it should be in the class, not something that mutates the class afterwards.
On Mon, Feb 5, 2018 at 1:59 AM, Kirill Balunov <kirillbalu...@gmail.com> wrote: > 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/ > guido%40python.org > > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ 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
