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

[Guido van Rossum]

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 consistent_order 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/)