[Python-3000] sort vs order (was: What should the focus for 2.6 be?) (original) (raw)

Guido van Rossum guido at python.org
Thu Aug 24 18:44:48 CEST 2006

For doctestst etc., it's easy to create a consistent order:

sorted(X, key=lambda x: (str(type(x)), x))

This sorts by the name of the type first, then by value within each type. This is assuming the type itself is sortable -- in 3.0, many types won't be sortable, e.g. dicts. (Even in 2.x, sets implement < so differently that a list of sets is likely to cause problems when sorting.)

--Guido

On 8/24/06, Jim Jewett <jimjjewett at gmail.com> wrote:

On 8/24/06, Guido van Rossum <guido at python.org> wrote: > Another change that is unlikely to be available in 2.x is the > rationalization of comparisons. In 3.0, "1 < 'abc'" will raise a_ _> TypeError; there's just no way to backport this behavior, since again > it requires pervasive changes to the implementation.

I still believe that this breaks an important current use case for sorting, but maybe the right answer is a different (but similar) API. Given an arbitrary collection of objects, I want to be able to order them in a consistent manner, at least within a single interpreter session. (Consistency across sessions/machines/persistence/etc would be even better, but isn't essential.) The current sort method works pretty well; the new one wouldn't. It would be enough (and arguably an improvement, because of broken objects) if there were a consistentorder equivalent that just caught the TypeError and then tried a fallback for you until it found an answer. -jJ

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list