[Python-ideas] a sorting protocol dunder method?

[Steven D'Aprano]

On Sun, Dec 03, 2017 at 06:46:45PM -0500, Nathan Schneider wrote:
> On Sun, Dec 3, 2017 at 6:06 PM, Chris Barker <chris.barker at noaa.gov> wrote:
> 
> > In fact, it's striking me that there may well be classes that are defining
> > the comparison magic methods not because they want the objects to "work"
> > with the comparison operators, but because that want them to work with sort
> > and min, and max, and...
> >
> 
> An existence proof: in NLTK, an __lt__ method added purely to facilitate
> consistent sorting (in doctests) of structured data objects for which
> comparison operators do not really make conceptual sense:
> https://github.com/nltk/nltk/pull/1902/files#diff-454368f06fd635b1e06c9bb6d65bd19bR689

This shows the problem with putting the key function into the data type. 
What if I want to sort AttrDicts by their list of keys instead? Or their 
(key, value) pairs? What is so special about sorting by ID (which may 
not even exist!) that it deserves to be part of the AttrDict itself?

The practical answer is that it is a convenience for doctests, but it 
would have been almost as convenient for nltk to provide a convenience 
sorting function to hold that knowledge as to bake it into the AttrDict 
itself. Or a key function that you can pass to sorted.

My solution to this would have been to add a key function to the class:

@staticmethod
def _id_order(item):
    # Convenience function for doctests
    return item['ID']


and then sort like this:

sorted(list_of_attrdicts, key=AttrDict._id_order)

A little less convenient, but conceptually cleaner and more explicit.


-- 
Steve