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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4