[Python-Dev] Cleaning-up the new unittest API (original) (raw)

Stephen J. Turnbull stephen at xemacs.org
Tue Nov 2 09:28:43 CET 2010

C. Titus Brown writes:

p.s. Seriously? I can accept that there's a rational minimalist argument for this "feature",

It is a feature, even if you aren't gonna need it. I want it.

Many programmers do know that sets are partially ordered by inclusion, preordered by size, and (in Python) totally ordered by memory address. There's nothing wrong with not knowing that -- these are rather abstract mathematical concepts. But it's very useful that sorted() or .sort() use <=, and it's very useful that Python so often obeys simple consistent rules, and it would be quite confusing to those who do understand that "in Python the set type is partially ordered by inclusion" if sorted() used some other relation to order collections of sets.

It's not so hard to change this:

class SizedSet (set): def lt(a, b): return length(a) < length(b) def __le__(a, b): return length(a) <= length(b) def __gt__(a, b): return length(a) > length(b) def ge(a, b): return length(a) >= length(b) # These two are arguable, which makes size comparison not so # great as a candidate for the OOWTDI of set.lt(). def eq(a, b): return length(a) == length(b) def ne(a, b): return length(a) != length(b)

If there were an obvious way to compare sets for use in sorting, that way would very likely be the most useful definition for <=, too. But there isn't, really (it's pretty obvious that comparing memory addresses is implausible, but otherwise, there are lots of candidates that are at least sometimes useful). Do you think otherwise? If so, what do you propose for the OOWTDI of sorting a collection of sets?

but arguing that it's somehow the responsibility of a programmer to expect this seems kind of whack.

I don't quite agree that everyone should "expect exactly the implemented behavior", but I do think it's a Python programmer's responsibility to refrain from expecting something else in this case.

More information about the Python-Dev mailing list