On 04:29 pm, fuzzy...@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
_______________________________________________
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
