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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
