[Python-ideas] a sorting protocol dunder method?
steve at pearwood.info
Sun Dec 3 19:57:21 EST 2017
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:
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:
# Convenience function for doctests
and then sort like this:
A little less convenient, but conceptually cleaner and more explicit.
More information about the Python-ideas