On Sun, Dec 03, 2017 at 10:48:18PM -0800, Carl Meyer wrote:
I think this is an interesting idea, and I don't believe that either performance or "sortable vs comparable" are very relevant.
Performance is always relevant -- while performance shouldn't be the sole deciding factor, it should be a factor. And since the entire use-case for this is sorting versus comparison operators, I'm having trouble understanding why you think that sorting versus comparison operators is irrelevant.
I doubt there is much performance to gain here,
I doubt there is any performance gain -- rather a performance hit is far more likely.
and I think the default sort order for a class must continue to match its comparison behavior.
This proposal changes that: if a class defines __key__ but not __lt__, then the default sort behaviour will be different from the comparison behaviour. If it defines both, it isn't clear which will be used for sorting. Should __lt__ take priority, or __key__? Whichever we choose, somebody is going to be upset and confused by the choice.
Most often when I define equality and comparison dunder methods for a custom class, I'm effectively just deferring the comparison to some field or tuple of fields of the object. E.g.
from functools import total_ordering
@total_ordering class BankAccount: def __init__(self, balance): self.balance = balance
[snip example] This example shows exactly the confusion of concepts I'm talking about. Why should bank accounts be sorted by their balance, instead of by their account number, or account name, or date they were opened? Why should BankAccounts sort differently according to their balance, a quantity which can change after every transaction? What happens when somebody decides that bank accounts default sorting should be by their account name rather than the ever-changing balance? I'm not saying that it never makes sense to sort a bunch of accounts according to their balance. I'm saying that functionality is not part of the account themselves. If it belongs anywhere, it belongs in the collection of accounts. And even that is dubious: I believe that where it really belongs is in the report generator that needs to sort the collection of accounts.
It'd be nice to be able to eliminate an import
That's an argument that applies to *literally* everything in the standard library. Should we make everything a built-in? The prerequisites for eliminating the need for an import should be a *lot* higher than just "it would be nice". I disagree with the design of this: it is putting the decision of how to sort uncomparable objects in the wrong place, in the object itself rather than in the report that wants to sort them. -- Steve