On Fri, Feb 2, 2018 at 7:38 AM, Elvis Pranskevichus <elprans at gmail.com> wrote: > On Friday, February 2, 2018 10:08:43 AM EST Eric V. Smith wrote: > > However, I don't feel very strongly about this. As I've said, I expect > > the use cases for hash=True to be very, very rare. > > Why do you think that the requirement to make a dataclass hashable is a > "very, very rare" requirement? I think what's rare is wanting hashability without it being frozen. > Just put yourself in the shoes of an average Python developer. You try > to put a dataclass in a set, you get a TypeError. Your immediate > reaction is to add "hash=True". Things appear to work. agreed, the easy and obvious way should be to make it frozen -- if it's hard to make it hashable and not frozen, then that's good. But it is nice to have the __hash__ generated more you.... so maybe a flag for "unfrozen_hashable" -- really klunky, but if that is a rare need, then there you go. Or maybe: If either hash or frozen is specified, it become both frozen and hashable. If both are specified, then it does what the user is asking for. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180202/3c338706/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4