[Python-3000] sort vs order (was: What should the focus for 2.6 be?)
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 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/)
More information about the Python-3000
mailing list