[Python-Dev] Second post: PEP 557, Data Classes (original) (raw)
Eric V. Smith eric at trueblade.com
Sun Nov 26 03:48:01 EST 2017
- Previous message (by thread): [Python-Dev] Second post: PEP 557, Data Classes
- Next message (by thread): [Python-Dev] Second post: PEP 557, Data Classes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message (by thread): [Python-Dev] Second post: PEP 557, Data Classes
- Next message (by thread): [Python-Dev] Second post: PEP 557, Data Classes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]