On Sun, Dec 3, 2017 at 10:48 PM, Carl Meyer wrote:
> It'd be nice to be able to eliminate an import and have the lines of
> code and instead write that as:
>
> class BankAccount:
> def __init__(self, balance):
> self.balance = balance
>
> def __sort_key__(self):
>
On Sun, 3 Dec 2017 15:06:02 -0800
Chris Barker wrote:
> 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 customize
On Mon, 4 Dec 2017 08:45:55 +0200
Serhiy Storchaka
wrote:
> 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
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
On Mon, Dec 04, 2017 at 12:06:38PM +0100, Antoine Pitrou wrote:
> There are definitely advantages. Sorting calls __lt__ for each
> comparison (that is, O(n log n) times) while __key__ would only be
> called once per item at the start (that is, O(n) times).
Passing a key function doesn't magicall
On 4 December 2017 at 11:41, Steven D'Aprano wrote:
> 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 perfor
On Mon, Dec 04, 2017 at 08:45:55AM +0200, Serhiy Storchaka wrote:
> But the idea of the class decorator looks more sane to me.
The purpose of __key__ is to define a key function (not a comparison
operator) for classes that aren't orderable and don't have __lt__.
If you're going to then go ahead
On Mon, 4 Dec 2017 23:16:11 +1100
Steven D'Aprano wrote:
> On Mon, Dec 04, 2017 at 12:06:38PM +0100, Antoine Pitrou wrote:
>
> > There are definitely advantages. Sorting calls __lt__ for each
> > comparison (that is, O(n log n) times) while __key__ would only be
> > called once per item at the s
On Mon, 4 Dec 2017 12:19:07 +
Paul Moore wrote:
> On 4 December 2017 at 11:41, Steven D'Aprano wrote:
> > 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 ve
On Sun, Dec 03, 2017 at 06:53:45PM -0800, Bruce Leban wrote:
> 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.
I never imagined that it would be a re
04.12.17 13:06, Antoine Pitrou пише:
On Mon, 4 Dec 2017 08:45:55 +0200
Serhiy Storchaka
wrote:
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 ove
04.12.17 14:25, Steven D'Aprano пише:
On Mon, Dec 04, 2017 at 08:45:55AM +0200, Serhiy Storchaka wrote:
But the idea of the class decorator looks more sane to me.
The purpose of __key__ is to define a key function (not a comparison
operator) for classes that aren't orderable and don't have __l
On Mon, 4 Dec 2017 15:50:31 +0200
Serhiy Storchaka
wrote:
>
> >> Yes, it is too special-case. I don't see any advantages in comparison
> >> with defining the __lt__ method.
> >
> > There are definitely advantages. Sorting calls __lt__ for each
> > comparison (that is, O(n log n) times) while
On Mon, Dec 04, 2017 at 01:52:19PM +0100, Antoine Pitrou wrote:
> On Mon, 4 Dec 2017 23:16:11 +1100
> Steven D'Aprano wrote:
> > On Mon, Dec 04, 2017 at 12:06:38PM +0100, Antoine Pitrou wrote:
> >
> > > There are definitely advantages. Sorting calls __lt__ for each
> > > comparison (that is, O(n
On Tue, 5 Dec 2017 02:52:44 +1100
Steven D'Aprano wrote:
> On Mon, Dec 04, 2017 at 01:52:19PM +0100, Antoine Pitrou wrote:
> > On Mon, 4 Dec 2017 23:16:11 +1100
> > Steven D'Aprano wrote:
> > > On Mon, Dec 04, 2017 at 12:06:38PM +0100, Antoine Pitrou wrote:
> > >
> > > > There are definitely
I'm +1 on this idea for the most part.
I agree particularly with the idea that it is better OOP for an object to
access it's member variables to create the key than an external container
to do so.
> and then sort like this:
> sorted(list_of_attrdicts, key=AttrDict._id_order)
This is certainly a
On 12/04/2017 10:01 AM, brent bejot wrote:
This is certainly a good pattern to use in the current and older versions, but
I think we can all agree that defining
__key__ and calling "sorted(list_of_attrdicts)" has that syntactic sugar that
is oh-so-sweet-and-tasty.
Actually, no, we do not all
On 04/12/17 18:01, brent bejot wrote:
I'm +1 on this idea for the most part.
I agree particularly with the idea that it is better OOP for an object
to access it's member variables to create the key than an external
container to do so.
> and then sort like this:
> sorted(list_of_attrdicts,
On 04/12/17 18:01, brent bejot wrote:
I'm +1 on this idea for the most part.
I agree particularly with the idea that it is better OOP for an object to
access it's member variables to create the key than an external container
to do so.
This I'm absolutely fine with. Key methods are something t
I wondered what the performance would be and tested the following code:
#!/usr/bin/env python3
import random
import time
random.seed( hash('Testing Keys') )
lt_calls = 0
key_calls = 0
class MyObject:
def __init__( self, value1, value2 ):
self.value1 = value1
self.value2 = va
On Mon, 4 Dec 2017 19:37:02 +
Barry Scott wrote:
> I wondered what the performance would be and tested the following code:
>
[...]
>
> it outputs this for my with python 3.6.0
>
> 1
> key 0.010628s 1 calls
> lt 0.053690s 119886 calls
>
> It seems that providing a key is ~5 times
> On 4 Dec 2017, at 20:12, Antoine Pitrou wrote:
>
> On Mon, 4 Dec 2017 19:37:02 +
> Barry Scott wrote:
>> I wondered what the performance would be and tested the following code:
>>
> [...]
>>
>> it outputs this for my with python 3.6.0
>>
>> 1
>> key 0.010628s 1 calls
>> lt 0.
On Tue, Dec 5, 2017 at 8:22 AM, Barry wrote:
>
>
>> On 4 Dec 2017, at 20:12, Antoine Pitrou wrote:
>>
>> On Mon, 4 Dec 2017 19:37:02 +
>> Barry Scott wrote:
>>> I wondered what the performance would be and tested the following code:
>>>
>> [...]
>>>
>>> it outputs this for my with python 3.6
Le 04/12/2017 à 14:16, Steven D'Aprano a écrit :
We're taking something which belongs in the report generator or
collection, the knowledge of how to sort a collection of unordered
values, and baking it into the values themselves. (Effectively making
them ordered!)
It is also possible to use this
On Tue, Dec 5, 2017 at 8:54 AM, Julien Salort wrote:
> Le 04/12/2017 à 14:16, Steven D'Aprano a écrit :
>
>> We're taking something which belongs in the report generator or
>> collection, the knowledge of how to sort a collection of unordered
>> values, and baking it into the values themselves. (E
I thought this might be interesting input for the discussions about "data
classes" in Python:
https://kotlinlang.org/docs/reference/data-classes.html
I think that the use of "data class" as syntax is kind of cool, but what
really matters is the semantics they chose for Kotlin.
--
Juancarlo *Añe
wow! a few time zones (and a day job) really make a difference to taking
part in a discussion :-)
Thanks for all the feedback. From what I can tell, we don't have a
consensus, though It's looking pretty unlikely that this is going to be
adopted (though maybe the decorator idea). But I'm going to g
On 12/04/2017 10:01 AM, brent bejot wrote:
I think we can all agree that defining
__key__ and calling "sorted(list_of_attrdicts)" has that syntactic
sugar that is oh-so-sweet-and-tasty.
Just remember that too much syntactic sugar can give
you cancer of the semicolon.
--
Greg
___
28 matches
Mail list logo
