This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: assertSequenceEqual should be fired when comparing sequence subclasses
Type: behavior Stage: resolved
Components: Library (Lib), Tests Versions: Python 3.2, Python 3.3, Python 2.7
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: ezio.melotti, flox, gregory.p.smith, michael.foord, r.david.murray
Priority: normal Keywords:

Created on 2012-08-29 13:18 by flox, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (6)
msg169372 - (view) Author: Florent Xicluna (flox) * (Python committer) Date: 2012-08-29 13:18
When writing unittest, I noticed that I need to uses assertSequenceEqual explicitly when comparing sequences of different kinds.

If I only use the plain assertEqual, it does not generate pretty diffs.

On second thought, I think it could be fixed in unittest to use assertSequenceEqual when isinstance(arg, (tuple, list)) or isinstance(arg, collections.Sequence) is True.
msg169374 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-08-29 13:21
I think it works as it should (you shouldn't be asserting that a sequence and a tuple are equal, after all).  Once you fix your test, you'll get the pretty print if there are still differences.
msg169379 - (view) Author: Florent Xicluna (flox) * (Python committer) Date: 2012-08-29 13:34
you're probably right.
I will continue to use assertSequenceEqual for my use cases.
Actually, what confused me is that these assertions are True:

class T(tuple): pass
class L(list): pass

assertEqual(T('ab'), tuple('ab'))
assertEqual(L('ab'), list('ab'))

And when these tests fail, the output is not pretty formatted.
msg169380 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-08-29 13:45
That sounds like a bug.
msg169382 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2012-08-29 13:57
The assertSequenceEqual docs[0] say:
This method is not called directly by assertEqual(), but it’s used to implement assertListEqual() and assertTupleEqual().

The asserEqual docs[1] say:
In addition, if first and second are the exact same type and one of list, tuple, dict, set, frozenset or str or any type that a subclass registers with addTypeEqualityFunc() the type-specific equality function will be called in order to generate a more useful default error message (see also the list of type-specific methods).

assertEqual[2] calls _getAssertEqualityFunc[3] that checks if type(first) is type(second), so in your case no specific assert function is called, and since you are not comparing objects of the same type, you are not able to use addTypeEqualityFunc() either.

I think in this case using assertSequenceEqual() directly is ok.

msg169572 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2012-08-31 17:53
When we added this functionality to assertEqual we were *intentionally* conservative on when it would auto-promote to nicer equality comparison functions.  It needs to behave exactly as == would in all situations.

>>> (1,2,3) == [1,2,3]

We must maintain that behavior in assertEqual.

Tests should use assertSequenceEqual when they want to compare sequences regardless of type because they are testing for something less than strict equality.
Date User Action Args
2022-04-11 14:57:35adminsetgithub: 60014
2012-08-31 17:53:37gregory.p.smithsetstatus: open -> closed

nosy: + gregory.p.smith
messages: + msg169572

resolution: rejected
stage: resolved
2012-08-29 13:57:01ezio.melottisetnosy: + ezio.melotti
messages: + msg169382
2012-08-29 13:45:01r.david.murraysetmessages: + msg169380
title: assertSequenceEqual should be fired when comparing sequences -> assertSequenceEqual should be fired when comparing sequence subclasses
2012-08-29 13:34:35floxsetmessages: + msg169379
2012-08-29 13:21:08r.david.murraysetnosy: + r.david.murray, michael.foord
messages: + msg169374
2012-08-29 13:18:18floxcreate