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 <rep...@bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to