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 terry.reedy
Recipients aldencolerain, ezio.melotti, georg.brandl, graingert, gregory.p.smith, martin.panter, michael.foord, r.david.murray, rbcollins, rhettinger, serhiy.storchaka, terry.reedy, vitaly
Date 2019-09-21.20:18:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1569097119.69.0.227080440491.issue27071@roundup.psfhosted.org>
In-reply-to
Content
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?]
History
Date User Action Args
2019-09-21 20:18:39terry.reedysetrecipients: + terry.reedy, georg.brandl, rhettinger, gregory.p.smith, rbcollins, ezio.melotti, r.david.murray, michael.foord, martin.panter, serhiy.storchaka, vitaly, graingert, aldencolerain
2019-09-21 20:18:39terry.reedysetmessageid: <1569097119.69.0.227080440491.issue27071@roundup.psfhosted.org>
2019-09-21 20:18:39terry.reedylinkissue27071 messages
2019-09-21 20:18:39terry.reedycreate