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 <[EMAIL PROTECTED]> wrote: > On 8/24/06, Guido van Rossum <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
