RetroSearch Browse

Mon Oct 20 14:22:22 EDT 2003 · https://mail.python.org/pipermail/python-dev/2003-October/039088.html

> Or maybe, like in dict.fromkeys, we don't want to emphasize
> either the building or the newness, but then I wouldn't know what
> to suggest except the list.sorted that's already drawn catcalls
> (though it drew them when it was proposed as an instance
> methods of lists -- maybe as a classmethod it will look better?-)

list.sorted as a list factory looks fine to me.  Maybe whoever pointed
out the problem with l.sorted() vs. l.sort() for non-native-English
speakers can shed some light on how list.sorted(x) fares compared to
x.sort()?

But the argument that it wastes a copy still stands (even though
that's only O(N) vs. O(N log N) for the sort).

> I want the functionality -- any sensible name that might let the
> functionality into the standard library would be ok by me (so
> would one putting the functionality in as a builtin or as an instance
> method of lists, actually, but I _do_ believe those would not be
> the best places for this functionality, by far).  I hope the "tools
> package" idea and/or the classmethod one find favour...!-)

I'm still unclear why this so important to have in the library when
you can write it yourself in two lines.

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-October/039088.html below:

copysort patch, was RE: [Python-Dev] inline sort option