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 r.david.murray
Recipients ezio.melotti, michael.foord, r.david.murray, rbcollins, vitaly
Date 2016-05-23.14:49:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1464014943.92.0.839578487375.issue27071@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2016-05-23 14:49:03r.david.murraysetrecipients: + r.david.murray, rbcollins, ezio.melotti, michael.foord, vitaly
2016-05-23 14:49:03r.david.murraysetmessageid: <1464014943.92.0.839578487375.issue27071@psf.upfronthosting.co.za>
2016-05-23 14:49:03r.david.murraylinkissue27071 messages
2016-05-23 14:49:03r.david.murraycreate