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.

classification
Title: TestCase.assertItemsEqual's description of differences
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.2
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: michael.foord Nosy List: eric.araujo, ezio.melotti, mattheww, michael.foord, terry.reedy
Priority: normal Keywords:

Created on 2010-09-28 20:15 by mattheww, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (4)
msg117545 - (view) Author: Matthew Woodcraft (mattheww) Date: 2010-09-28 20:15
TestCase.assertItemsEqual uses two different techniques to describe the
differences in the inputs that it compares.

If the inputs are sortable, it sorts them and then uses
assertSequenceEqual to describe the difference between them considered
as ordered sequences.

Otherwise, it uses unittest.util.unorderable_list_difference, which
is essentially a multiset comparison.

In practice, I think the output from unorderable_list_difference is
usually more readable, so I wonder if something of that kind should be
made the default.


Example:

a = [('b', (2, 3)), ('w', (3, 4))]
b = [('x', (2, 3)), ('w', (3, 4))]
case.assertItemsEqual(a, b)


unorderable_list_difference gives

Expected, but missing:
    [('b', (2, 3))]
Unexpected, but present:
    [('x', (2, 3))]


while the current assertItemsEqual gives

Sequences differ: [('b', (2, 3)), ('w', (3, 4))] != [('w', (3, 4)), ('x', (2, 3))]

First differing element 0:
('b', (2, 3))
('w', (3, 4))

- [('b', (2, 3)), ('w', (3, 4))]
+ [('w', (3, 4)), ('x', (2, 3))]


In general, I think that the 'first differing element' paragraph that
assertSequenceEqual produces is as likely to be misleading as it is to
be helpful (when we're really comparing unordered sequences).
msg117822 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-10-01 18:39
If I understand correctly, you are requesting that .assertItemsEqual only use the 2nd (multiset comparison) method, so that if one want the first method, one should directly call .assertSequenceEqual(sorted(a), sorted(b)).

This seems reasonable to me, but I do not use the unittest module, and I suspect others want the implicit call.
msg117825 - (view) Author: Matthew Woodcraft (mattheww) Date: 2010-10-01 18:46
Terry J. Reedy wrote:
> If I understand correctly, you are requesting that .assertItemsEqual
> only use the 2nd (multiset comparison) method, so that if one want the
> first method, one should directly call .assertSequenceEqual(sorted(a),
> sorted(b)).

Yes, that would make me happy. So would a new assertXXXEqual method that
always did the multiset comparison.
msg125205 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2011-01-03 17:52
In Python 3.2 assertItemsEqual has been replaced with assertCountEqual that has a completely different implementation and error format. The implementation and error output will be backported to the assertItemsEqual method of 2.7 (and to unittest2).

Error output:

AssertionError: Element counts were not equal:
First has 1, Second has 0:  ('b', (2, 3))
First has 0, Second has 1:  ('x', (2, 3))
History
Date User Action Args
2022-04-11 14:57:07adminsetgithub: 54186
2011-01-03 17:52:54michael.foordsetstatus: open -> closed
nosy: terry.reedy, mattheww, ezio.melotti, eric.araujo, michael.foord
messages: + msg125205

resolution: not a bug
stage: test needed -> resolved
2010-11-01 00:02:10ezio.melottisetnosy: + ezio.melotti
2010-10-01 18:46:48matthewwsetmessages: + msg117825
2010-10-01 18:39:28terry.reedysetnosy: + terry.reedy

messages: + msg117822
stage: test needed
2010-09-30 15:18:06eric.araujosetnosy: + eric.araujo
2010-09-28 21:59:17michael.foordsetassignee: michael.foord
components: + Library (Lib)
versions: + Python 3.2
2010-09-28 20:15:18matthewwcreate