msg188045 - (view) |
Author: Ronald Oussoren (ronaldoussoren) *  |
Date: 2013-04-29 08:01 |
assertItemsEqual was added to unittest.TestCase in Python 2.7 (according to the documentation), but is not present in Python 3.3.
I'd expect it to be present in 3.3 as well, or for it to be mentioned in documentation as not being present (either in the 2.7 documentation or the Misc/NEWS file for py3k)
|
msg188046 - (view) |
Author: Ezio Melotti (ezio.melotti) *  |
Date: 2013-04-29 08:15 |
I don't remember how it went exactly, but there were a few similar methods (assertItemsEqual, assertSameElements, assertCountEqual). In 3.x we eventually decide to remove the first 2 because it wasn't clear what they were doing, and only assertCountEqual survived. In 2.7 this wasn't possible, so assertItemsEqual survived.
assertDictContainsSubset is another method that was in 2.7 but is not in 3.x anymore.
Do you think the docs for 2.x should mention this?
|
msg188047 - (view) |
Author: Ronald Oussoren (ronaldoussoren) *  |
Date: 2013-04-29 08:33 |
I do think this should be mentioned in the 2.7 docs, assertDictContainsSubset is mentioned as "deprecated since 3.2" in the 2.7 docs. The only problem with that is that there doesn't seem to be a "versionremoved" directive in sphinx, the best alternative seems to be deprecated-removed.
I'm not to happy about the removal though, assertCountEqual is not in 2.7 which means it is unnecessarily hard to port tests from 2.7 to 3.3. I also don't quite understand the difference between assertCountEqual and assetItemsEqual, the documentation for the two (in the 3.3 and 2.7 docs) appears to indicate they have the same behavior (both assert that two sequence have the same contents when the order of items is ignored).
|
msg188049 - (view) |
Author: Ezio Melotti (ezio.melotti) *  |
Date: 2013-04-29 08:40 |
I think they might actually be the same (i.e. the name changed but not the implementation). See #10242.
If this is true the new name could be mentioned in 2.7.
|
msg188051 - (view) |
Author: Ronald Oussoren (ronaldoussoren) *  |
Date: 2013-04-29 08:59 |
You're right, according to #10242 the method was renamed in 3.2.
Something like the attached patch?
I'm somewhat flabbergasted that #10242 came to the conclusion that it would be a good idea to rename this method, given the folks that contributed the discussion. It not that the new name is very good, I've seen it in the 3.3 docs and didn't notice that it was relevant for what I was trying to do until you mentioned the method and I actually read the description. When I first saw the method I thought it was related to list.count.
|
msg188052 - (view) |
Author: Ezio Melotti (ezio.melotti) *  |
Date: 2013-04-29 09:08 |
Apparently assertItemsEqual was added to 2.7 and 3.2 and, after the release of 2.7 but before the release of 3.2, assertItemsEqual has been renamed assertCountEqual (596239da3db7) and initially the assertItemsEqual was available too. However, since the method was new in 3.2 the old alias got removed shortly after (bdd57841f5e2). Eventually 3.2 was released with only assertCountEqual.
|
msg188053 - (view) |
Author: Ezio Melotti (ezio.melotti) *  |
Date: 2013-04-29 09:19 |
Looks like we wrote a similar patch at the same time :)
We don't usually use versionchanged in the 2.x docs for things that changed in 3.x. Using "named" instead of "renamed" is better, since in 3.x the name was assertCountEqual since the beginning, however saying "In Python 3.2" might be confusing (people might think that it's different for 3.3+). I suggest to replace it with simply "Python 3", or perhaps "Python 3.2+".
|
msg188054 - (view) |
Author: Ronald Oussoren (ronaldoussoren) *  |
Date: 2013-04-29 09:22 |
Your patch looks good.
|
msg188055 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2013-04-29 09:26 |
New changeset d9921cb6e3cd by Ezio Melotti in branch '2.7':
#17866: mention that in Python 3, assertItemsEqual is named assertCountEqual.
http://hg.python.org/cpython/rev/d9921cb6e3cd
|
msg188056 - (view) |
Author: Ezio Melotti (ezio.melotti) *  |
Date: 2013-04-29 09:27 |
Applied.
|
msg265888 - (view) |
Author: Vitaly (vitaly) |
Date: 2016-05-19 20:02 |
Python 2.7 documentation is VERY misleading about the functionality of assertItemsEqual. It actually claims to compare not only the counts, but the actual sorted elements themselves. This documentation mislead my group to use this method for comparing the elements. See https://hg.python.org/cpython/file/d9921cb6e3cd/Doc/library/unittest.rst:
.. method:: assertItemsEqual(actual, expected, msg=None)
Test that sequence *expected* contains the same elements as *actual*,
regardless of their order. When they don't, an error message listing the
differences between the sequences will be generated.
Duplicate elements are *not* ignored when comparing *actual* and
*expected*. It verifies if each element has the same count in both
sequences. It is the equivalent of ``assertEqual(sorted(expected),
sorted(actual))`` but it works with sequences of unhashable objects as
well.
|
msg265890 - (view) |
Author: Vitaly (vitaly) |
Date: 2016-05-19 20:10 |
I opened http://bugs.python.org/issue27060 regarding the erroneous documentation of assertItemsEqual in python 2.7.
|
msg265979 - (view) |
Author: Vitaly (vitaly) |
Date: 2016-05-20 23:50 |
Folks, assertCountEqual sounds like a really bad name. It misleads users into thinking that it only compares the number of elements in each sequence, whereas it actually asserts that equivalent items are present in both sequences, regardless of order. The original name from 2.7 assertItemsEqual was so much better and more meaningful.
|
msg266143 - (view) |
Author: R. David Murray (r.david.murray) *  |
Date: 2016-05-23 13:11 |
At the time I wanted it to be named assertCountsEqual, which is better (IMO) than either assertItemsEqual or assertCountEqual. I lost that naming contest, though :(. On the third hand, I don't think there exists a good two word name for what the function does.
|
|
Date |
User |
Action |
Args |
2022-04-11 14:57:45 | admin | set | github: 62066 |
2016-05-23 13:11:38 | r.david.murray | set | nosy:
+ r.david.murray messages:
+ msg266143
|
2016-05-20 23:50:16 | vitaly | set | messages:
+ msg265979 |
2016-05-19 20:10:34 | vitaly | set | messages:
+ msg265890 |
2016-05-19 20:02:32 | vitaly | set | nosy:
+ vitaly messages:
+ msg265888
|
2013-04-29 09:27:15 | ezio.melotti | set | status: open -> closed
assignee: docs@python -> ezio.melotti components:
- Library (Lib) versions:
+ Python 2.7, - Python 3.3, Python 3.4 resolution: fixed messages:
+ msg188056 stage: resolved |
2013-04-29 09:26:13 | python-dev | set | nosy:
+ python-dev messages:
+ msg188055
|
2013-04-29 09:22:46 | ronaldoussoren | set | messages:
+ msg188054 |
2013-04-29 09:19:46 | ezio.melotti | set | files:
+ issue17866-2.diff
messages:
+ msg188053 |
2013-04-29 09:08:55 | ezio.melotti | set | files:
+ issue17866.diff keywords:
+ patch messages:
+ msg188052
|
2013-04-29 08:59:55 | ronaldoussoren | set | files:
+ issue17866.txt
messages:
+ msg188051 |
2013-04-29 08:40:28 | ezio.melotti | set | messages:
+ msg188049 |
2013-04-29 08:37:01 | flox | set | nosy:
+ flox
|
2013-04-29 08:33:18 | ronaldoussoren | set | messages:
+ msg188047 |
2013-04-29 08:15:18 | ezio.melotti | set | nosy:
+ docs@python, ezio.melotti messages:
+ msg188046
assignee: docs@python components:
+ Documentation type: enhancement |
2013-04-29 08:01:28 | ronaldoussoren | create | |