On Sat, Jan 09, 2021 at 07:56:24AM -0500, Alan G. Isaac wrote:
This comment misses the key point, which is: `assertSequenceEqual` should not rely on behavior that is not ensured for typing.Sequence, but it currently does. The failure on a numpy array simply exposes this problem.
You are making that as a definitive statement of fact, but it's not clear to me that this is actually true. There are at least two problems with your position:
(1) The Sequence ABC requires only the *presence* of certain methods, not their semantics. We're entitled to assume the obvious, implicit, sequence-like semantics. If a class implements the methods, but provides unexpected semantics, anything could happen.
(2) Equality is a fundament operation that we are entitled to assume that *all* objects support. See above: we're entitled to assume the standard semantics for equality too. Objects which have unusual semantics for equality, such as float NANs, may behave in unexpected ways.
So I don't think that we are *required* to support unusual sequences like numpy.
On the other hand, I think that we can extend assertSequenceEqual to support numpy arrays quite easily. A quick glance at the source code:
suggests that all we need do is catch a potential ValueError around the sequence equality test, and fall back on the element by element processing:
try: if seq1 == seq1: return except ValueError: # Possibly a numpy array? pass
I don't think that this is a breaking change, and I think it should do what you expect.
I don't believe that we need to accept your reasoning regarding the Sequence ABC to accept this enhancement. One need only accept that although numpy's array equality semantics are non-standard and unhelpful, numpy is an important third-party library, and the cost of supporting sequences like numpy arrays is negligible.