[Python-Dev] Cleaning-up the new unittest API

[exarkun at twistedmatrix.com]

On 04:29 pm, fuzzyman at voidspace.org.uk wrote:
>On 02/11/2010 16:23, Terry Reedy wrote:
>>On 11/2/2010 10:05 AM, C. Titus Brown wrote:
>>>...but, as someone who has to figure out how to teach stuff to CSE 
>>>undergrads
>>>(and biology grads) I hate the statement "...any programmer should
>>>expect this..."
>>
>>And indeed I (intentionally) did not say that. People who are ignorant 
>>and inexperienced about something should avoid making expectations in 
>>any direction until they have read the doc and experimented a bit.
>Expectations come from consistent behaviour. sorted behaves 
>consistently for *most* of the built-in types and will also work for 
>custom types that provide a 'standard' (total ordering) implementation 
>of __lt__.
>
>It is very easy to *not realise* that a consequence of sets (and 
>frozensets) providing partial ordering through operator overloading is 
>that sorting is undefined for them.

Perhaps.  The documentation for sets says this, though:

  Since sets only define partial ordering (subset relationships), the 
output of the list.sort() method is undefined for lists of sets.
>Particularly as it still works for other mutable collections. Worth 
>being aware that custom implementations of standard operators will 
>break expectations of users who aren't intimately aware of the problem 
>domains that the specific type may be created for.

I can't help thinking that most of this confusion is caused by using < 
for determining subsets.  If < were not defined for sets and people had 
to use "set.issubset" (which exists already), then sorting a list with 
sets would raise an exception, a much more understandable failure mode 
than getting back a list in arbitrary order.

Jean-Paul