On 11/26/2017 3:35 AM, Eric V. Smith wrote: > On 11/26/2017 12:23 AM, Carl Meyer wrote: >> A couple minor >> questions: >> >>> If compare is True, then eq is ignored, and __eq__ and __ne__ will be >> automatically generated. >> >> IMO it's generally preferable to make nonsensical parameter combinations >> an immediate error, rather than silently ignore one of them. Is there a >> strong reason for letting nonsense pass silently here? >> >> (I reviewed the previous thread; there was a lot of discussion about >> enums/flags vs two boolean params, but I didn't see explicit discussion >> of this issue; the only passing references I noticed said the invalid >> combo should be "disallowed", e.g. Guido in [1], which to me implies "an >> error.") > > I think you're right here. I'll change it to a ValueError. While creating an issue for this (https://github.com/ericvsmith/dataclasses/issues/88), it occurs to me that the class-level parameter really should be "order" or "orderable", not "compare". It made more sense when it was called "cmp", but "compare" now seems wrong. Because "eq" says "can I compare two instances", and what's currently called "compare" is "can I order two instances". Nick had a similar suggestion before the PEP was written (https://mail.python.org/pipermail/python-ideas/2017-May/045740.html). The field-level parameter should stay "compare", because it's used for both __gt__ and friends, as well as __eq__ and __ne__. It's saying "is this field used in all of the comparison methods". 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