Message100685
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:30 | ezio.melotti | set | recipients:
+ ezio.melotti, gregory.p.smith, eric.araujo, michael.foord, flox |
2010-03-09 00:35:30 | ezio.melotti | set | messageid: <1268094930.06.0.0569409620633.issue7832@psf.upfronthosting.co.za> |
2010-03-09 00:35:28 | ezio.melotti | link | issue7832 messages |
2010-03-09 00:35:28 | ezio.melotti | create | |
|