cc @corona10

FYI CPython 3.7.2, CPython master branch, PyPy 7.1.1 and PyPy3 7.1.1-beta0 all give the same result:

>>> nan=float("nan"); ([nan]*5).count(nan), nan==nan
(5, False)

I don't think this is a good idea, at least not on its own. The behavior is all over the place. For example, off the top of my head, in list.remove() and list.index() too. And set membership testing. And using objects as dict keys. Documenting it only for .count() methods leaves a misleading impression that they're somehow special in this respect.

I don't think this is a good idea, at least not on its own. The behavior is all over the place. For example, off the top of my head, in list.remove() and list.index() too. And set membership testing. And using objects as dict keys. Documenting it only for .count() methods leaves a misleading impression that they're somehow special in this respect.

Can we document it somewhere else in this case?

Can we document it somewhere else in this case?

For all I know, it already is 😉. Sorry, I'm not intimately familiar with the docs anymore.

Because PyObject_RichCompareBool() very deliberately does this, it's intended that "pointer equality implies object equality and not object inequality" be the ordinary behavior. That's why this behavior is "all over the place". It's really x == y and x != y that show oddball behaviors here.

For all I know, it already is wink. Sorry, I'm not intimately familiar with the docs anymore.

If it is, I would not say that it's not well documented :-) For example, it's not mentionnned in the __eq__ documentation:
https://docs.python.org/dev/reference/datamodel.html#object.__eq__

Maybe this method documentation would be a better place to describe CPython quirks?

I suggest taking this to python-dev. It's not at all clear to me that this is just a pile of CPython quirks. For example, whether a NaN can be used as a dict key is something that "should" be defined by the language.

Or if consensus is that this is just a pile of CPython quirks, then they need to be documented as such.

Note that x == y (or, more generally, __eq__ and __ne__) cannot do the same, because "rich comparisons" can return any kind of object at all. It's specific to contexts that call PyObject_RichCompareBool(), which must return True/False. But I don't believe the docs spell out which contexts those are, and there are a lot more than just list.count().