On Mon, Jul 2, 2018 at 9:39 AM, Michael Selik wrote:
> On Mon, Jul 2, 2018 at 2:32 AM Nicolas Rolin
>>> wrote:
>>>
For example the default could be such that grouping unpack tuples (key,
value) from the iterator and do what's expected with it (group value by
key). It is quite reas
On Mon, Jul 2, 2018 at 12:50 AM Michael Selik wrote:
>
> [Guido]
>
>> You'll never get consensus on anything here, but you have my blessing for
>> this without consensus.
>>
>
> That feels like a success, but I'm going to be a bit more ambitious and
> try to persuade you that `grouping` belongs i
>
> On Mon, Jul 2, 2018 at 2:32 AM Nicolas Rolin
>> wrote:
>>
>>> For example the default could be such that grouping unpack tuples (key,
>>> value) from the iterator and do what's expected with it (group value by
>>> key). It is quite reasonable, and you have one example with (key, value) in
>>>
On Fri, Jun 29, 2018 at 11:25 PM, Guido van Rossum wrote:
> Hm, this actually feels heavier to me. But then again I never liked or
> understood the need for Counter --
>
actually, me neither -- and partly because it's too lightweight -- that is,
it's still a regular dict, and you pretty much ha
On Mon, Jul 02, 2018 at 02:52:03AM -0700, Michael Selik wrote:
> Third, some classes might have a rich equality method that allows many
> interesting values to all wind up in the same group even if using the
> default "identity" key-function.
I would expect an identity key function to group by *i
My question would be : does it have to be a key function ? Can't we just
remove the "key" argument ?
Because for pretty much all the given examples, I would find my default as
readable and nearly as short as the "key" syntax :
> grouping(words, key=len)
grouping((len(word), word for word in words)
On Mon, Jul 2, 2018 at 2:52 AM Michael Selik wrote:
> On Mon, Jul 2, 2018 at 2:32 AM Nicolas Rolin
> wrote:
>
>> I think the current default quite weird, as it pretty much account to a
>> count() of each key (which can be useful, but not really what I except from
>> a grouping). I would prefer a
On Mon, Jul 2, 2018 at 2:32 AM Nicolas Rolin wrote:
> I think the current default quite weird, as it pretty much account to a
> count() of each key (which can be useful, but not really what I except from
> a grouping). I would prefer a default that might return an error to a
> default that says o
I think the current default quite weird, as it pretty much account to a
count() of each key (which can be useful, but not really what I except from
a grouping). I would prefer a default that might return an error to a
default that says ok and output something that is not what I might want.
For exam
I made some heavy revisions to the PEP. Linking again for convenience.
https://github.com/selik/peps/blob/master/pep-.rst
Replying to Guido, Nick, David, Chris, and Ivan in 4 sections below.
[Guido]
On Fri, Jun 29, 2018 at 11:25 PM Guido van Rossum wrote:
> On Fri, Jun 29, 2018 at 3:23 PM
On Sun, Jul 1, 2018 at 9:36 PM, Chris Barker wrote:
> hmm, makes we wonder if it would make sense to update my implementation to
> allow mapping types as well for the collection
>
general mapping types don't make sense -- but I added Counter. Which is a
pretty special case, so I think it probabl
11 matches
Mail list logo
