On 1/7/2018 12:25 PM, Guido van Rossum wrote: > On Sun, Jan 7, 2018 at 9:09 AM, Eric V. Smith <eric at trueblade.com > <mailto:eric at trueblade.com>> wrote: > > On 1/3/2018 1:17 PM, Eric V. Smith wrote: > > I’ll open an issue after I have time to read this thread and > comment on it. > > > https://bugs.python.org/issue32513 <https://bugs.python.org/issue32513> > I need to think though how __eq__ and __ne__ work, as well as the > ordering operators. > > My specific concern with __ne__ is that there's one flag to control > their generation, but python will use "not __eq__" if you don't > provide __ne__. I need to think through what happens if the user > only provides __eq__: does dataclasses do nothing, does it add > __ne__, and how does this interact with a base class that does > provide __ne__. > > > Maybe dataclasses should only ever provide __eq__ and always assume > Python's default for __ne__ kicks in? If that's not acceptable (maybe > there are cases where a user did write an explicit __ne__ that needs to > be overridden) I would recommend the following rule: > > - If there's an __eq__, don't do anything (regardless of whether there's > an __ne__) > - If there no __eq__ but there is an __ne__, generate __eq__ but don't > generate __ne__ > - If neither exists, generate both I've added my proposal on issue 32513: https://bugs.python.org/issue32513#msg310392 It's long, so I won't repeat it here. The only really confusing part is __hash__ and its interaction with __eq__. Eric.
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