Re: [Python-ideas] a sorting protocol dunder method?

On Sun, Dec 03, 2017 at 06:46:45PM -0500, Nathan Schneider wrote:

On Sun, Dec 3, 2017 at 6:06 PM, Chris Barker 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-454368f06fd635b1e06c9bb6d6...

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