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.

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*.

"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.

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.

> 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.

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.

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