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.

Author vitaly
Recipients ezio.melotti, michael.foord, rbcollins, vitaly
Date 2016-05-23.05:31:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1463981514.0.0.691929266875.issue27071@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2016-05-23 05:31:54vitalysetrecipients: + vitaly, rbcollins, ezio.melotti, michael.foord
2016-05-23 05:31:54vitalysetmessageid: <1463981514.0.0.691929266875.issue27071@psf.upfronthosting.co.za>
2016-05-23 05:31:53vitalylinkissue27071 messages
2016-05-23 05:31:52vitalycreate