[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Issue 38240 was closed as a duplicate of this.  After reconsidering, I agree 
with leaving the name alone.  Changing test assertXXX method names is a big 
nuisance, which we have done enough of.

If one is using IDLE,
>>> unittest.TestCase.assertCountEqual(
displays a boxed calltip with the signature and the two line summary that seems 
clear enough to me.  Good names are good; so are good docstring summaries.

|(self, first, second, msg=None)   |
|Asserts that two iterables have the same elements, the same number of |
|times, without regard to order.   |


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> 1. It seems that the 'list' call should be irrelevant.

It is relevant. Counter({1: 2}) != Counter(list({1: 2})).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I like using 'multiset', but I think 'assertMultisetEqual', proposed by Martin 
Panter in msg266207, is better than assertMultiSetEqual, as it does not imply 
the existence of a class 'MultiSet'.

Raymond's comment "distinct but equal values may appear on both sides, so it 
isn't really a permutation" turns on the ambiguity of 'same element' in the 
assertCoultEqual definition.  The doc never says explicitly that it means same 
by equality ('==') regardless of class, rather than same by equality within a 
class, which one might assume for 'permutation of values', or same by identity 
('is'), which would be needed for 'permutation of objects'.  I think it should 
what same means here.

Gregory Smith msg266208 objects to a name containing 'set' because "this is 
most notably an api having nothing to do with sets".  However, the short 
definition of the assertion, "a and b have the same elements in the same 
number, regardless of their order" *is* a definition of multiset equality.  The 
assertion looks at both collections as multisets.

Unlike R. David Murray msg266153, I see a difference between 'count' and 
'counts'.  The former can only mean comparing one count for each collection, 
the number of items.  The latter could mean the same, but could also mean 
comparing multiple counts for each collection, as is the case.

RDM goes on to claim that 'count' is correct because the function's doc defines 
it in terms of itertools.count.  It actually defines it in terms of 
collections.Counter, which would suggest, using the same logic, 
'assertCounterEqual' or assertCountersEqual.  Since Counter implements the 
mathematical idea of 'multiset' and "is similar to bags or multisets in other 
languages", we get to 'assertMultisetEqual' as the less Python-specific name.

[I am puzzled about a couple of things.  The doc says "Equivalent to: 
assertEqual(Counter(list(first)), Counter(list(second)))
but works with sequences of unhashable objects as well."  That expression *is* 
the current implementation.

1. It seems that the 'list' call should be irrelevant.
2. Counter calls fail  with iterables of unhashable objects.  Why not the 
overall expression?]

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Thomas Grainger]

Thomas Grainger  added the comment:

While it may not appear to be a permutation, python already considers it one:

graingert@onomastic:~$ cat test_assert_permutation.py 
import itertools
import unittest
from decimal import Decimal
from fractions import Fraction


class TestAssertPermutation(unittest.TestCase):
def assertPermutation(self, a, b):
return self.assertIn(tuple(a), itertools.permutations(b))

def test_do_not_look_like_permutations(self):
self.assertPermutation(
[Decimal(3), 5, Fraction(12, 4)], [3.0, 3, Fraction(15, 3)]
)


if __name__ == "__main__":
unittest.main()
graingert@onomastic:~$ python3 test_assert_permutation.py -v
test_do_not_look_like_permutations (__main__.TestAssertPermutation) ... ok

--
Ran 1 test in 0.000s

OK

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Raymond Hettinger]

Raymond Hettinger  added the comment:

FWIW "assertMultiSetEqual" may be better than "assertPermutation".  The issue 
with the latter is that distinct but equal values may appear on both sides, so 
it isn't really a permutation.

   # These don't look like permutations at all
   # but they are equivalent multisets
   assertPermutation([Decimal(3), 5, Fraction(12, 4)], [3.0, 3, Fraction(15, 
3)])

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Terry J. Reedy]

Terry J. Reedy  added the comment:

In msg266115, Robert Collins suggested  "add a different name and deprecate 
assertCountEqual".

In msg266184, Gregory Smith said "not against adding a new name if it makes 
glorious sense, but we should not remove the old names from unittest as that 
causes unnecessary pain (based on past experience)."

Others suggested status quo.

In msg352556, Michael Ford said "I like assertPermutation", but did not reopen 
the issue.

Coming at this fresh, via the PR that patches idlelib, my first thought was 
that assertCountEqual meant assertEqual(len(a), len(b)).  So the issue seems 
real.  assertPermutation is much better to me and I would like it added.

In unittest/case.py, PR 16228 renames assertCountEqual to assertPermutation and 
adds assertCountEqual as an alias, with no plan for deprecation and removal, as 
eventually done with other duplicates.

However, the PR also immediately renames all instances of assertCountEqual in 
the stdlib.  Perhaps 1/4 of these are in idlelib tests.  Much as I prefer the 
new name, this is unacceptible as it immediately makes backporting test changes 
in these areas (and I plan to make some) a manual process.  So I don't want 
IDLE tests renamed until 3.8 is off maintenance and the name change can be made 
in all maintenance versions at once.

I leave it to the rest of you to decide on the rest of the stdlib.

--
nosy: +terry.reedy
versions: +Python 3.9 -Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Thomas Grainger]

Change by Thomas Grainger :


--
pull_requests: +15826
pull_request: https://github.com/python/cpython/pull/16228

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Michael Foord]

Michael Foord  added the comment:

I like assertPermutation (with or without the Is, slight preference for 
without).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Thomas Grainger]

Thomas Grainger  added the comment:

I think assertPermutation (without the "is") would be the best name

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Thomas Grainger]

Thomas Grainger  added the comment:

How about assertIsPermutation?

https://www.fluentcpp.com/2019/06/25/understanding-the-implementation-of-stdis_permutation/

--
nosy: +graingert

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Robert Collins]

Robert Collins  added the comment:

So, I think we're in a local minima here.

As I said earlier, neither the old nor new names really grab me, and I think 
everyone has aknowledged that the new name is -at best- confusing. We don't 
need *any more discussion* about that. The question is how to fix it without 
yet more rounds of 'well this is confusing so lets change it again'.

I want to suggest some basic criteria for a dramatically better name, just to 
unblock this.

- follow the existing assert naming convention
- be short enough to be comfortably usable
- pass some user testing: do some lightning talks. Or ask on twitter for folk 
to tell you what the proposed name does without any hints.

- follow up here with how you tested and the name you've chosen based on that 
testing.

- we'll then do a straw poll amongst a few committers - me and michael at a 
minimum, and advise on go/nogo.

Once thats done I'll happily review a patch that adds a new, better name as an 
alias, and doesn't deprecate the existing one.

I'm leaving the bug in rejected status, because at this point there is nothing 
any committers seem to have appetite/energy to do: same as per 
https://bugs.python.org/msg266244

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Alden]

Alden  added the comment:

I think we need to re-open this issue.  I have done a poll of a number of 
python developers and every developer I talked to said they initially thought 
this function "assertCountEqual" asserts that the count is equal. Probably 
because that's exactly what the words mean. I think most people in this 
discussion agree that the name is not ideal, but how did we end up picking one 
that explicitly says something completely incorrect?  Not only that but we 
broke backward compatibility for a name that is significantly worse than the 
original.

If you asked any colleague or developer on the street that isn't a python 3 
user what "assert count equal" would do when provided with two lists. I would 
be amazed if anyone said something other than "checks that the two lists store 
the same number of elements".  I have asked everyone I know and no one has said 
anything different.

assertItemsEqual - Most people get this correct, some people think it also 
checks order. This confusion actually isn't that common because people first 
learn the function that DOES check order. (better)

assertFrequencyCountsEqual - Most people aren't sure what this does and would 
be need to look this up. (better)

assertElementCountsEqual - Seems like it checks the count of a list, but leaves 
you with some uncertainty. (not great, but better)

assertCountEqual and assertCountsEqual - Everyone i spoke to thought this 
asserted that number of elements in the collections were equal. Total certainty 
about the wrong functionality.


Explicit is better than implicit.
  * This name is not explicit it implies a completely different behavior.
Readability counts.
  * The words of this function literally mean something else.
Practicality beats purity.
  * Users not in the Python ivory tower immediately recognize this function 
name as something else. 
In the face of ambiguity, refuse the temptation to guess.
  * This name is not just ambiguous it is misleading and makes users guess and 
guess incorrectly.
If the implementation is hard to explain, it's a bad idea.
  * If we can't name this function correctly, maybe it's a bad idea?
Now is better than never.
  * This was a mistake and its better to correct it now than let it live on for 
another two years.

--
nosy: +aldencolerain

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[R. David Murray]

R. David Murray added the comment:

Agreed.  Time to close the issue.  If someone wants to do actual testing as 
Raymond suggests, and finds a name that actually works, they can either reopen 
this with a report or open a new issue.

--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Raymond Hettinger]

Raymond Hettinger added the comment:

Further churning of the names will cause more harm than good.  I recommend 
closing this (to end the bike-shedding and the stream of superlatives from the 
OP).  This ship has sailed and users are already relying on the published API.

Foord: "In the absence of a *dramatically* better name leave it alone."
Storchaka: "I vote for status quo."
Murray:  "I say leave well enough alone unless someone comes up with a simply 
brilliant better name."
Smith: "I'm not against adding a new name if it makes glorious sense, but we 
should not remove the old names from unittest as that causes unnecessary pain 
(based on past experience)."

FWIW, most of the suggestions in this issue would not help with a "never read 
the docs, just reading the code" kind of user.  Without biasing the result,  
ask other Python user's to guess what "assertItemsEqual" or 
"assertElementsEqual" do, and see whether they correctly deduce that it tests 
the equality of two unordered multisets formed from two input iterables.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

assertSequenceEqualUnordered is not a good fit, because it doesn't follow the 
de facto naming convention, whereby "Equal" should be the suffix.

Also assertSequenceEqualUnordered would be considered an oxymoron, since the 
word "Sequence" implies ordered, while "Unordered" is the opposite. It's like 
saying "ordered unordered collection".

My vote (if I had one) is still with assertUnorderedEqual. I think that from 
the word "Unordered" it's a reasonable leap that it refers to an unordered 
collection of elements, and it would be easy to remember.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Gregory P. Smith]

Gregory P. Smith added the comment:

assertSequenceEqualUnordered also works R. David.  I was going to suggest that 
as well but edited it out to keep my suggestion simpler. :)

I don't like the assertMultisetEqual suggestion as this is most notably an api 
having nothing to do with sets.

#bikeshed

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Martin Panter]

Martin Panter added the comment:

assertMultisetEqual?

--
nosy: +martin.panter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[R. David Murray]

R. David Murray added the comment:

how about assertSequenceEqualUnordered

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Gregory P. Smith]

Gregory P. Smith added the comment:

assertUnorderedSequenceEqual would make more sense to me given the natural 
relation to assertSequenceEqual.

We aren't dealing with sets (though sets are valid sequences) as this method 
specifically does not require sequence items to be hashable.  Explicitly 
putting the word sequence in the name makes that more clear.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

I think that assertUnorderedEqual would contrast nicely with assertSequenceEqual

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

With missing last line, this time:

==
FAIL: test_equal_count_of_different_elements (__main__.Test)
--
Traceback (most recent call last):
  File "", line 5, in test_equal_count_of_different_elements
AssertionError: Element counts were not equal:
First has 1, Second has 0:  3
First has 0, Second has 1:  4

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

Same results on Python.org's Python 3.5.1 shell:
>>> class Test(u.TestCase):
... def test_equal_count_of_same_elements(self):
... self.assertCountEqual(set([1,2,3]), set([1,2,3]))
... def test_equal_count_of_different_elements(self):
... self.assertCountEqual(set([1,2,3]), set([1,2,4]))
... def test_different_count(self):
... self.assertCountEqual(set([1,2,3]), set([1,2,3,4]))
... 
>>> u.main()
FF.
==
FAIL: test_different_count (__main__.Test)
--
Traceback (most recent call last):
  File "", line 7, in test_different_count
AssertionError: Element counts were not equal:
First has 0, Second has 1:  4

==
FAIL: test_equal_count_of_different_elements (__main__.Test)
--
Traceback (most recent call last):
  File "", line 5, in test_equal_count_of_different_elements
AssertionError: Element counts were not equal:
First has 1, Second has 0:  3

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

The preceding results are via Python 2.7.10

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

$ python assert_items_equal_test.py 
FF.
==
FAIL: test_different_count (__main__.Test)
--
Traceback (most recent call last):
  File "assert_items_equal_test.py", line 12, in test_different_count
self.assertItemsEqual(set([1,2,3]), set([1,2,3,4]))
AssertionError: Element counts were not equal:
First has 0, Second has 1:  4

==
FAIL: test_equal_count_of_different_elements (__main__.Test)
--
Traceback (most recent call last):
  File "assert_items_equal_test.py", line 8, in 
test_equal_count_of_different_elements
self.assertItemsEqual(set([1,2,3]), set([1,2,4]))
AssertionError: Element counts were not equal:
First has 1, Second has 0:  3
First has 0, Second has 1:  4

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

Why do you say that "we aren't dealing with python sets"? Try:

import unittest as u
class Test(u.TestCase):
def test_equal_count_of_same_elements(self):
self.assertItemsEqual(set([1,2,3]), set([1,2,3]))


def test_equal_count_of_different_elements(self):
self.assertItemsEqual(set([1,2,3]), set([1,2,4]))


def test_different_count(self):
self.assertItemsEqual(set([1,2,3]), set([1,2,3,4]))
u.main()

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[R. David Murray]

R. David Murray added the comment:

And it suffers the same problem as 'unordered', or even more so, as it implies 
sets, but we aren't dealing with python sets.

See why this is so tough? :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[R. David Murray]

R. David Murray added the comment:

Heh.  We could call it 'assertQuotientSetEqual', but most people would have to 
look that up (I did, to find it). 'assertEquivalenceClassesEqual' is a bit 
better, but probably still not clear without looking it up (or being a 
mathematician).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

When I read "Unordered", it makes me think of collections, including sequences 
and sets.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Gregory P. Smith]

Gregory P. Smith added the comment:

I'm not against adding a new name if it makes glorious sense, but we should not 
remove the old names from unittest as that causes unnecessary pain (based on 
past experience).

assertCountEqual does make sense in terms of the "equivalent to" context from 
the docs.  Thought I agree with you, its meaning is generally not obvious and 
must be looked up to be understood. 
https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertCountEqual

assertUnorderedEqual is a reasonable name, but I don't find significantly 
better than assertCountEqual from a "never read the docs, just reading the 
code" understandability point of view.  It makes me wonder "unordered what?"

that's a vote of -0 for the status quo.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +georg.brandl, gregory.p.smith, rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

By leaps and bounds, I like assertUnorderedEqual versus assertCountEqual, which 
is terribly misleading. The first, and simplest, thing that comes to my mind 
from the word Count by itself is the count of all elements in a sequence (i.e., 
its length), certainly not frequency count.

I am also happy with the status quo of assertItemsEqual, but I have to agree 
that assertUnorderedEqual removes any ambiguity that assertItemsEqual 
purportedly suffers from. Thank you for suggesting assertUnorderedEqual.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

My first expectation for this function was assertUnorderedEqual, but I want to 
avoid problems with renaming (and coexisting of three names of for the same 
function), and I vote for status quo.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[R. David Murray]

R. David Murray added the comment:

Vitaly: if you can come up with a name we agree is more descriptive than the 
current one by a non-trivial margin, we will be happy to listen.  
assertFrequencyCountsEqual is not sufficiently better.  (Personally, I would 
not know what that function did by reading the name.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

Gentlemen, the point is that the name of a function should be all that is 
necessary to unambiguously understand what this method does without having to 
know that it's implemented in terms of collections.Counter or any other 
internal detail like that. That's not a good strategy for picking names in 
computer programming. The name of a function should certainly not be tied to an 
internal implementation detail (use Counter to implement, so let's name it 
"Count"?). Something that asserts the equality of two collections of elements 
is not rocket science and does not deserve an ambiguous name. "Count" is simply 
too ambiguous in this case.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Michael Foord]

Michael Foord added the comment:

I agree with David, I don't like the name but it is at least accurate (if you 
already understand what it does). assertItemsEqual was better but misleading. 
In the absence of a *dramatically* better name leave it alone.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[R. David Murray]

R. David Murray added the comment:

Personally I don't see any difference between assertCountsEqual and 
assertFrequencyCountsEqual.  The logic for assertCountsEqual is that it is 
asserting that some counts are equal in this sequence.  What could we be 
counting?  The only obvious thing is the length of the collections of equal 
elements.  'Count' was chosen because it references itertools.count, which it 
can be defined in terms of, as indicated in the docs.  The presence of absence 
of the s doesn't affect that rationale for the name.

The flaw in assertItems(Elements)Equal is that it implies that each pair of 
element is equal, implying that the *orders* are the same, which is exactly the 
opposite of the intent.

This is the kind of bikeshed that can go on for weeks on a mailing list.  I say 
leave well enough alone unless someone comes up with a simply brilliant better 
name.

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

If there really is a good systemic reason why names like assertItemsEqual and 
assertElementsEqual are flawed, then assertFrequencyCountsEqual might be a 
less-ambiguous alternative.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

As far as I can tell, issue #10242 deals with the renaming. I think that the 
arguments for the new name are flawed (sorry to be so blunt, but I don't know 
how else to express it).

Regardless of whether it's Count or Counts, to most people it sounds like it's 
going to compare just the simple counts of the elements (i.e., lengths of the 
sequences). Ask yourself the questions: 1. What is the element count in 
sequence S? Reasonable answer: len(S).  2. What are the element counts of 
sequences Q and S? Reasonable answer len(Q) and len(S). Those are the most 
straightforward, non-nuanced answers you would get from most people IMHO.

With ambiguous names like these, readability of the code is greatly diminished. 
When I review code, a name like assertCountEqual tells me (and likely most 
other reviewers) that it's comparing lengths of the sequences, and I have no 
reason to resort to the documentation. A well-named function should do what its 
name says, and its name should say what it does. assertCountEqual doesn't pass 
that test, unless you read the documentation, and apply the nuanced 
interpretation that is biased by the documentation. assertElementCountsEqual is 
in the same category, I am afraid :) The straightforward interpretation of 
these names is misleading at worst and ambiguous at best.

I think that the authors of the new name assertCountEqual were thinking along 
the lines of "assert frequency counts equal", which might lead to the arguably 
unambiguous name assertFrequencyCountsEqual, but but all that sounds more 
complicated than it needs to be.

Personally, something like assertElementsEqual seems to me to capture the 
spirit of the assertion better and is easier for most people to grasp. It 
doesn't imply order as it emphasizes the elements (vs. assertSequenceEqual, 
which emphasizes sequence), and it doesn't imply uniqueness. I like 
assertElementsEqual more than assertItemsEqual, but then again, 
assertElementsEqual is not sufficiently better than assertItemsEqual to warrant 
a backward-incompatible name change in my opinion.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Robert Collins]

Robert Collins added the comment:

I don't particularly like either name FWIW :) - but sure, we can add a 
different name and deprecate assertCountEqual - but before we do anything lets 
look up the previous issue where the rename was done.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[SilentGhost]

Changes by SilentGhost :


--
nosy: +ezio.melotti, michael.foord, rbcollins
type:  -> behavior
versions:  -Python 3.3, Python 3.4, Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

The new name by itself does not sufficiently reflect the subtlety of 
element-by-element counts, which does a disservice to the readability of test 
code. And it's also an unnecessary incompatibility between 2.7 and 3.x.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

New submission from Vitaly:

Somewhere in 3.x assertItemsEqual was renamed to assertCountEqual.

assertCountEqual sounds like a really inappropriate, misleading name for what 
it does. 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 more meaningful.

--
components: Library (Lib)
messages: 265980
nosy: vitaly
priority: normal
severity: normal
status: open
title: unittest.TestCase.assertCountEqual is a very misleading name
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com