Eli Bendersky added the comment: I agree that the difference in behavior between the two functions is unfortunate, but that's unlikely to change now. The least we can do is make the documentation precise. I'm attaching a proposed patch to Doc/c-api/object.rst Nick/Terry/Georg - if this looks OK I can commit. ---------- keywords: +easy, patch nosy: +eli.bendersky, ncoghlan, terry.reedy -Devin Jeanpierre type: -> behavior Added file: http://bugs.python.org/file20413/issue10912.py3k.1.patch _______________________________________ Python tracker http://bugs.python.org/issue10912 _______________________________________

Eli Bendersky added the comment: Committed the fix to py3k in r88009 ---------- _______________________________________ Python tracker http://bugs.python.org/issue10912 _______________________________________

Nick Coghlan added the comment: For the record, the gory details as to *why* RichCompareBool makes more assumptions as to the meaning of equality than the basic RichCompare function can be found in issue 4296 (I just found that issue myself by looking at Mark's response to the python-list thread). It may be worth explicitly pointing out that use cases where this assumption is unacceptable would be better served by direct invocation RichCompare function. ---------- nosy: +mark.dickinson _______________________________________ Python tracker http://bugs.python.org/issue10912 _______________________________________

Nick Coghlan added the comment: Yeah, to prevent perfectly reasonable "why" questions, it is probably worth providing a little extra justification as an addendum to your new note (which is already an improvement on the complete silence on the topic that existed before). A possible addition: "... This assumption allows invariants such as "x in [x]" to be more easily guaranteed by the interpreter. If the assumption is not valid for a given use case, call PyObject_RichCompare() directly instead of using this function." For 3.3, it *may* make sense to provide a PyObject_RichCompareBoolEx() function which includes an additional "reflexive" parameter. Then the existing PyObject_RichCompareBool() semantics would just be the new function with the reflexive argument set to 1. ---------- _______________________________________ Python tracker http://bugs.python.org/issue10912 _______________________________________

Changes by Raymond Hettinger : ---------- nosy: +rhettinger _______________________________________ Python tracker http://bugs.python.org/issue10912 _______________________________________

Nick Coghlan added the comment: Indeed. I was actually wondering if it would be worth trying to write up a section for the language reference to describe the cases where a Python implementation is *expected* to assume reflexive equality. We (IMO) have a problem at the moment due to situations like:

...

...

class PyContains(list): ... def __contains__(self, obj): ... return any(x==obj for x in self) ... nan = float("nan") nan in [nan] True nan in PyContains([nan]) False

This is a bug in the __contains__ definition (it should use "x is obj or x == obj" rather than just the latter expression) but there isn't anything in the language reference to point that out. Assuming reflexive equality in some places and not in others based on the underlying implementation language is going to be a source of subtle bugs relating to types like float and decimal.Decimal. ---------- _______________________________________ Python tracker http://bugs.python.org/issue10912 _______________________________________

Eli Bendersky added the comment: Raymond, I initially set "easy" on this issue because I considered it a documentation issue, not the place to resolve the harder debate of the semantics of these functions. Perhaps I was wrong? Also, I agree with Nick that the difference must be further clarified in "stronger words". If there's no debate on this issue, I will commit a fix after the freeze is over. ---------- _______________________________________ Python tracker http://bugs.python.org/issue10912 _______________________________________

Nick Coghlan added the comment: Reopening, as a 2.7 backport of this would be a nice thing to have. ---------- assignee: rhettinger -> status: closed -> open versions: +Python 2.7 _______________________________________ Python tracker http://bugs.python.org/issue10912 _______________________________________

Changes by Eli Bendersky : ---------- status: open -> closed _______________________________________ Python tracker http://bugs.python.org/issue10912 _______________________________________