[issue22001] containers "same" does not always mean "__eq__".
New submission from Jim Jewett: https://docs.python.org/3.5/reference/expressions.html#not-in Containers are permitted to (and generally do) read "same as" as "is or __eq__), which can be confusing -- particularly in the section defining __eq__. Several suggested changes: """ The values float('NaN') and Decimal('NaN') are special. The are identical to themselves, x is x but are not equal to themselves, x != x. Additionally, comparing any value to a not-a-number value will return False. For example, both 3 < float('NaN') and float('NaN') < 3 will return False. """ --> ("the" -> "they"; add a comma; add a final sentence) --> """ The values float('NaN') and Decimal('NaN') are special. They are identical to themselves, x is x, but are not equal to themselves, x != x. Additionally, comparing any value to a not-a-number value will return False. For example, both 3 < float('NaN') and float('NaN') < 3 will return False. Note, however, that containers will normally implement item equality as "a is b or a==b", so that [f]==[f] and f in [f] may be true even when f!=f. """ also: """ Tuples and lists are compared lexicographically using comparison of corresponding elements. This means that to compare equal, each element must compare equal and the two sequences must be of the same type and have the same length. """ --> (re-order; add the NaN workaround) --> """ Tuples and lists are compared lexicographically using comparison of corresponding elements. This means that to compare equal, two sequences must be of the same type and have the same length, and each pair of corresponding elements must be identical or compare equal. (Sequences can assume that identical elements are equal, despite odd cases like float('NaN').) """ I *think* it is OK to leave that caveat out of the mapping case, because "have the same (key, value) pairs" would now refer to the above. ---------- assignee: docs@python components: Documentation messages: 223362 nosy: Jim.Jewett, docs@python priority: normal severity: normal status: open title: containers "same" does not always mean "__eq__". type: enhancement _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue22001> _______________________________________
Steven D'Aprano added the comment: On Thu, Jul 17, 2014 at 07:39:21PM +0000, Jim Jewett wrote:
Note, however, that containers will normally implement item equality as "a is b or a==b"
We can't say "will normally", since we don't know about the infinite number of possible container types that people might create. The most we can say is that *builtin* container types will [assuming that this is the intent] or that general containers *may*. ---------- nosy: +steven.daprano _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue22001> _______________________________________
Changes by Raymond Hettinger <raymond.hettinger@gmail.com>: ---------- assignee: docs@python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue22001> _______________________________________
R. David Murray added the comment: "must be identical" sounds like "identical twins". I think what you mean is "must be references to the same object or to objects that compare equal". If you don't want to get into the concept of 'references' here, I suppose it could read "must be the same object or objects that compare equal". What I'm saying is that "same object" is stronger than "identical"..."identical" is much closer to "equal" in English. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue22001> _______________________________________
Jim Jewett added the comment: Ah... "be the same object or compare equal" sounds much better. I don't want "same" to sound like an informal wording for equal, because getting rid of the confusion over NaN and similar objects is the whole point of the revision. On the other hand, I don't want the language spec to imply that a more careful custom container is non-conforming. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue22001> _______________________________________
Changes by Ezio Melotti <ezio.melotti@gmail.com>: ---------- nosy: +ezio.melotti _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue22001> _______________________________________
Raymond Hettinger added the comment:
Ah... "be the same object or compare equal" sounds much better.
Yes, the plain language is clear and reads nicely.
We can't say "will normally", since we don't know about the infinite number of possible container types that people might create. The most we can say is that *builtin* container types will [assuming that this is the intent] or that general containers *may*.
"general containers may" is most accurate.
Several suggested changes:
Jim, can you propose a much more minimal edit? As you pointed-out, the underlying logic is "containers are permitted to (and generally do) read "same as" as "is or __eq__". I don't think we should say much more than that in the section on expressions. Any notes on NaNs should probably be in a section talking about the float type. The weirdness of NaNs is a feature of the NaNs, not a feature of the entire language. We definitely don't want a NaN note added to the documentation of every container. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue22001> _______________________________________
Martin Panter added the comment: Issue 12067 has a large patch in progress that would conflict with the changes suggested here. However most of the concerns here may already be addressed there, if the patch ever goes ahead. ---------- nosy: +vadmium _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue22001> _______________________________________
Andy Maier added the comment: I reviewed the issues discussed here and believe that the patch for #Issue 12067 adresses all of them (and yes, it is large, unfortunately). It became large because I think that more needed to be fixed. May I suggest to review that patch. Andy ---------- nosy: +andymaier _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue22001> _______________________________________
Change by Raymond Hettinger <raymond.hettinger@gmail.com>: ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue22001> _______________________________________
participants (7)
-
Andy Maier -
Ezio Melotti -
Jim Jewett -
Martin Panter -
R. David Murray -
Raymond Hettinger -
Steven D'Aprano