assertSequenceEqual should be fired when comparing sequence subclasses

[florentx]

BPO	15810
Nosy	@gpshead, @ezio-melotti, @bitdancer, @voidspace, @florentx

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2012-08-31.17:53:37.668>
created_at = <Date 2012-08-29.13:18:18.815>
labels = ['tests', 'type-bug', 'library']
title = 'assertSequenceEqual should be fired when comparing sequence subclasses'
updated_at = <Date 2012-08-31.17:53:37.655>
user = 'https://github.com/florentx'

bugs.python.org fields:

activity = <Date 2012-08-31.17:53:37.655>
actor = 'gregory.p.smith'
assignee = 'none'
closed = True
closed_date = <Date 2012-08-31.17:53:37.668>
closer = 'gregory.p.smith'
components = ['Library (Lib)', 'Tests']
creation = <Date 2012-08-29.13:18:18.815>
creator = 'flox'
dependencies = []
files = []
hgrepos = []
issue_num = 15810
keywords = []
message_count = 6.0
messages = ['169372', '169374', '169379', '169380', '169382', '169572']
nosy_count = 5.0
nosy_names = ['gregory.p.smith', 'ezio.melotti', 'r.david.murray', 'michael.foord', 'flox']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue15810'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3']

[florentx]

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.

[bitdancer]

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.

[florentx]

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.

[bitdancer]

That sounds like a bug.

[ezio-melotti]

The assertSequenceEqual docs0 say:
"""
This method is not called directly by assertEqual(), but it’s used to implement assertListEqual() and assertTupleEqual().
"""

The asserEqual docs1 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).
"""

assertEqual2 calls _getAssertEqualityFunc3 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.

[gpshead]

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]
False

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.