Author ezio.melotti
Recipients eric.araujo, ezio.melotti, flox, gregory.p.smith, michael.foord
Date 2010-03-09.00:35:28
SpamBayes Score 4.78506e-14
Marked as misclassified No
Message-id <>
To summarize, the possible behaviors are:
1) check  order, check  duplicates (i.e. assertSequenceEqual);
2) check  order, ignore duplicates (probably useless);
3) ignore order, check  duplicates (useful but missing);
4) ignore order, ignore duplicates (i.e. assertSameElements now);

The possible solutions are:
a) change assertSameElements to match behavior 3 (see Florent patch):
   pros: implements 3 (i.e. the expected behavior); 4 can be replaced easily *; shorter function call for common use;
   cons: breaks compatibility; the name is still kind of confusing;
b) add check_order to assertSequenceEqual, leave assertSameElements unchanged:
   pros: covers 1, 3 and 4; backward compatible;
   cons: assertSameElements is still confusing;
c) add check_order to assertSequenceEqual, deprecate and then remove assertSameElements:
   pros: covers 1 and 3; removes a confusing function; 4 can be replaced easily *;
   cons: deprecates a quite new function;
d) add check_duplicates to assertSameElements:
   pros: covers 1, 3 and 4; backward compatible (with default == False);
   cons: assertSameElements would be even more confusing;

* assertSameElements can be replaced by assert[Set]Equal(set(a), set(b)), but this doesn't work with unhashable elements (they worked with assertSameElements).

I like c) because it removes a confusing function, and simplifies the API of unittest that IMHO it's already growing too complex (even if it would be handy to have a function that does 3 directly without having to write check_order=False).
Date User Action Args
2010-03-09 00:35:30ezio.melottisetrecipients: + ezio.melotti, gregory.p.smith, eric.araujo, michael.foord, flox
2010-03-09 00:35:30ezio.melottisetmessageid: <>
2010-03-09 00:35:28ezio.melottilinkissue7832 messages
2010-03-09 00:35:28ezio.melotticreate