On Tue, Nov 2, 2010 at 1:33 AM, R. David Murray <rdmurray at bitdance.com> wrote: > Or, to put it another way, *if* there is a bug here it would be in set, > not sorted. Put me in the "it's not a bug, it's a feature" camp. Providing a "elements equal" check that doesn't rely on LT providing a total ordering is a non-trivial exercise. Looking at assertItemsEqual, I'd be inclined to insert a check that falls back to the "unorderable_list_difference" approach in the case where "expected != sorted(reversed(expected))" (only need to check the one, since if the expected values are totally ordered, while the actual values are not, this should show up when comparing the elements). It slows down the fast path a bit, but the updated function should at least handle partial orderings more correctly than it does now. Cheers, Nick. P.S. Late night post, so I may be missing something obvious... -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4