Interesting. Did you look at the code? It is here (that's the `==` operator you're complaining about):

The code does already analyze the length of the sequence

You are right that (or its ancestors other than object) does not implement `__eq__`, so it would seem that the `==` operator would have to be replaced with a simple loop:
for x, y in zip(seq1, seq2):
    if x is not y and x != y:
    return  # They are all equal
Making that change would probably slow things down. (Note that the odd check "x is not y and x != y" is needed to keep the previous behavior regarding NaN and other objects that aren't equal to themselves.)

One could also argue that the docstring warns about this issue:
For the purposes of this function, a valid ordered sequence type is one
which can be indexed, has a length, and has an equality operator.
IOW, I think this ship has actually sailed.

On Tue, Dec 22, 2020 at 10:56 AM Alan G. Isaac <> wrote:
The following test fails because because `seq1 == seq2` returns a (boolean) NumPy array
whenever either seq is a NumPy array.

     import unittest
     import numpy as np
     unittest.TestCase().assertSequenceEqual([1.,2.,3.], np.array([1.,2.,3.]))

I expected `unittest` to rely only on features of a ``,
which based on,
I believe are satisfied by a NumPy array. Specifically, I see no requirement
that a sequence implement __eq__ at all much less in any particular way.

In short: a test named `assertSequenceEqual` should, I would think,
work for any sequence and therefore (based on the available documentation)
should not depend on the class-specific implementation of __eq__.

Is that wrong?

Thank you, Alan Isaac
Python-Dev mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct:

--Guido van Rossum (
Pronouns: he/him (why is my pronoun here?)