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

[Alex Martelli]

On Sunday 19 October 2003 07:23 pm, Raymond Hettinger wrote:
   ...
> The forces working against introducing an in-line sort are:
> * the time to copy the list (which Alex later showed to be irrelevant),
> * having two list methods with a similar purpose, and
> * the proposed method names are less than sublime

Good summary (including the parts I snipped).


> If someone could come-up with a name more elegant than "copysort", I
> the idea would be much more appetizing.

I still think that having it in some module is a bit better than having it as
a method of lists.  The BDFL has already Pronounced that it's too narrow
in applicability for a builtin (and he's right -- as usual), and that we won't 
have "grab-bag" module of shortcuts that don't fit well anywhere else 
(ditto), and seems very doubtful despite your urgings to reconsider his
stance against adding it as a list method (the two-methods-similar-
purpose issue seems quite relevant).

So, back to what I see as a key issue: a module needs to be "about"
something reasonably specific, such as a data type.  Built-in data types
have no associated module except the builtin one, which is crowded
and needs VERY high threshold for any addition.  So, if I came up with
an otherwise wonderful function that works on sets, arrays, ..., I'd be
in clover -- there's an obvious module to house it)... but if the function 
worked on lists, dicts, files, ..., I'd be hosed.  Note that module string
STILL exists, and still is the ONLY way to call maketrans, an important
function that was deemed inappropriate as a string method; a function
just as important, and just as inappropriate as a method, that worked
on lists, or dicts, or files, or slices, or ... would be "homeless" and might
end up just not entering the standard library.

In a way this risks making built-in types "second-class citizens" when
compared to types offered by other modules in the standard library!

I think we SHOULD have modules corresponding to built-in types,
if there are important functions connected with those types but not
appropriate as methods to populate them.  Perhaps we could use the 
User*.py modules for the purpose, but making new ones seems
better.  Rather than being kept together just by naming conventions,
as the User*.py are, they might be grouped in a package.  Good names
are always a problem, but, say, "tools.lists" might be the modules with
the auxiliary tools dealing with lists, if "tools" was the package name --
"tools.dicts", "tools.files", etc, if needed -- "tools.sequences" for tools
equally well suited to all sequences (not just lists) -- of course, that
would retroactively suggest "tools.iters" for your itertools, oh well, pity,
we sure can't rename it breaking backwards compatibility:-).

If we had module tools.lists (or utils.lists, whatever) then I think
copysort (by whatever name) would live well there.  copyreverse
and copyextend might perhaps also go there and make Barry
happy?-)


Alternatively - we could take a different tack.  copysort is NOT so
much a tool that works on an existing list -- as shown in the code I
posted, thanks to PySequence_List, it's just as easy to make it
work on any sequence (finite iterator or iterable).  So what does it
do?  It BUILDS a new list object (a sorted one) from any sequence.

So -- it's a FACTORY FUNCTION of the list type.  Just like, say,
dict.fromkeys is a factory function of the dict type.  Now, factory
functions are "by nature" classmethods of their type object, no?
So, we should package THIS factory function just like others -- as
a classmethod on list, list.somename, just like dict.fromkeys is
a classmethod on dict.

In this light, we surely don't want "copy" as a part of the name --
a factory method should be thought of as building a new list, not
as copying an old one (particularly because it will work on any
sequence as its argument, of course).

Maybe list.buildsorted if we want to emphasize the "build" part.
Or list.newsorted to emphasize that a new object is returned.
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?-)


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...!-)


Alex