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

[Terry Reedy]

On 11/2/2010 1:23 PM, Michael Foord wrote:

> Right, I did quote that exact text earlier in the thread. False
> expectations come when there are exceptions to otherwise-consistent
> behaviour.
>
>>> 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.
>>
> I agree. This is a cost of overloading operators with domain specific
> meanings.

I disagree. In mathematics, total ordering is a special case of partial 
ordering, not the other way around. Set inclusion is a standard example 
of non-total ordering. In everyday life, another example (other than 
action dependencies) are ancestry relationships. In general, acyclic 
directed graphs model sets with partial orders. Totally ordered linear 
chains, as with integers, are a special case.

A Python program, for instance, is usually a non-unique topological sort 
of a set a statements with a non-total dependency order. This is related 
to a topological sort of a set of actions with a non-total dependency 
order. A NameError, if not due to a misspelling, is typically a result 
of violating one of the space or time order constraints.

So I stick with my statement that a programmer should have some 
understanding (at least at a gut level) of non-total orders and 
non-unique sorts. They are a major part of what programming is.

-- 
Terry Jan Reedy