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.