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.