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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4