[Python-ideas] a sorting protocol dunder method?

[Bruce Leban]

On Sun, Dec 3, 2017 at 3:06 PM, Chris Barker <chris.barker at noaa.gov> wrote:

>
> However, if you are writing a custom class ... <snip>
>
> But what if there was a sort key magic method:
>
>  __key__ or __sort_key__ (or whatever)
>
> that would be called by the sorting functions <snip>
>
> It seems this would provide a easy way to make custom classes sortable
> that would be nicer for end users (not writing key functions), and possibly
> more performant in the "usual" case.
>

On Sun, Dec 3, 2017 at 4:57 PM, Steven D'Aprano <steve at pearwood.info> wrote:

>
> 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?


I think you're arguing against this for the wrong reason. Chris was talking
about custom classes having the *option* of making them sortable by
providing a key method in the class definition. This strikes me as useful
and I can imagine having used this if it were available. What you're saying
is that there are classes which probably shouldn't define a __sort_key__
function, which I quite agree with. But I don't think it's a good argument
against this proposal.


On Sun, Dec 3, 2017 at 3:06 PM, Chris Barker <chris.barker at noaa.gov> wrote:

> Am I imagining the performance benefits?
>

Maybe. Looking strictly at O(-) cost, there's no difference between a key
function and comparison operators. Sure it might potentially only make O(n)
calls to the key function and O(n log n) calls to compare the keys vs. O(n
log n) calls to the comparator functions but that might not actually be
faster. There certainly are cases where implementing a key function would
be quite slow.

--- Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171203/44b4d847/attachment.html>