> On 3 Dec 2017, at 03:58, Nick Coghlan wrote:
>
> On 2 December 2017 at 01:12, Ronald Oussoren wrote:
>> On 1 Dec 2017, at 12:29, Nick Coghlan wrote:
>>> 2. Define it as a class method, but have the convention be for the
>>> *caller* to worry about walking the MRO, and hence advise class
>>>
On 3 December 2017 at 21:36, Ronald Oussoren wrote:
>
>
>> On 3 Dec 2017, at 03:58, Nick Coghlan wrote:
>>
>> On 2 December 2017 at 01:12, Ronald Oussoren wrote:
>>> On 1 Dec 2017, at 12:29, Nick Coghlan wrote:
2. Define it as a class method, but have the convention be for the
*caller
I can't believe this hasn't been brought up before, but searching the web,
and python-ideas, and all the PEPs has found nothing (could be my lame
google-fu), so here goes:
Recent python has moved toward a "key" function for customized sorting:
list.sort(key=key_fun)
key is also used (according t
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
On Sun, Dec 03, 2017 at 03:06:02PM -0800, Chris Barker wrote:
> Recent python has moved toward a "key" function for customized sorting:
>
> list.sort(key=key_fun)
>
> key is also used (according to
> https://docs.python.org/3.6/library/functools.html#functools.cmp_to_key) in:
>
> min(), max(),
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 compar
On Sun, Dec 3, 2017 at 3:06 PM, Chris Barker wrote:
>
> However, if you are writing a custom class ...
>
> But what if there was a sort key magic method:
>
> __key__ or __sort_key__ (or whatever)
>
> that would be called by the sorting functions
>
> It seems this would provide a easy way to ma
I'm not sure I understand the motivation to make elements *sortable* but
not comparable. If an arbitrary order is still useful, I'd think you'd want
to be able to tell how two particular elements *would* sort by asking a wrote:
>
> On Sun, Dec 3, 2017 at 3:06 PM, Chris Barker
> wrote:
>
>>
>> Ho
And if this is a method on a custom *collection*, it can do whatever it
wants in MyCollection.sort() already.
On Dec 3, 2017 7:14 PM, "David Mertz" wrote:
> I'm not sure I understand the motivation to make elements *sortable* but
> not comparable. If an arbitrary order is still useful, I'd think
04.12.17 01:06, Chris Barker пише:
So: has this already been brought up and rejected?
https://bugs.python.org/issue20632
Am I imagining the performance benefits?
This will add an additional overhead. This will be even slower than
passing the key function, since you will need to look up the
I think this is an interesting idea, and I don't believe that either
performance or "sortable vs comparable" are very relevant. I doubt there
is much performance to gain here, and I think the default sort order for
a class must continue to match its comparison behavior.
I think the case in favor o
11 matches
Mail list logo
