On Tue, Jul 3, 2018, 6:32 PM Steven D'Aprano wrote:
> On Tue, Jul 03, 2018 at 10:33:55AM -0700, Chris Barker wrote:
> > On Tue, Jul 3, 2018 at 8:33 AM, Steven D'Aprano
> wrote:
> >
> > > but why are we using key values by hand when grouping ought to do it
> for
> > >> us, as Michael Selik's vers
So this ended up a long post, so the TL;DR
* There are types of data well suited to the key function approach, and
other data not so well suited to it. If you want to support the not as well
suited use cases, you should have a value function as well and/or take a
(key, value) pair.
* There are so
On Tue, Jul 03, 2018 at 10:33:55AM -0700, Chris Barker wrote:
> On Tue, Jul 3, 2018 at 8:33 AM, Steven D'Aprano wrote:
>
> > but why are we using key values by hand when grouping ought to do it for
> >> us, as Michael Selik's version does?
> >
> > grouping(words, key=len)
>
>
> because supp
On Wed, Jul 04, 2018 at 10:44:17AM +1200, Greg Ewing wrote:
> Steven D'Aprano wrote:
> >I propose that a better name which indicates the non-lazy nature of this
> >function is *grouped* rather than grouping, like sorted().
>
> +1
>
> >As for where it belongs, perhaps the collections module is th
MRAB wrote:
I think that building an iterable of 2-tuples to pass to 'grouped' is
much like following a decorate-sort-undecorate pattern when sorting, or
something similar when using 'min' or 'max'. Passing an iterable of
items and optionally a key function is simpler, IMHO.
It should certain
On 2018-07-03 23:20, Greg Ewing wrote:
Nicolas Rolin wrote:
grouping(((len(word), word) for word in words))
That actually has one more level of parens than are needed,
you can just write
grouping((len(word), word) for word in words)
FWIW, here's my opinion.
I much prefer something li
Steven D'Aprano wrote:
I propose that a better name which indicates the non-lazy nature of this
function is *grouped* rather than grouping, like sorted().
+1
As for where it belongs, perhaps the collections module is the least
worst fit.
But then there's the equally strong purist argument t
David Mertz wrote:
Just
make grouping() a generator function rather than a plain function. This
lets us get an incremental grouping of an iterable. This can be useful
if the iterable is slow or infinite, but the partial groupings are
useful in themselves.
Do you have any real-world example
Nicolas Rolin wrote:
grouping(((len(word), word) for word in words))
That actually has one more level of parens than are needed,
you can just write
grouping((len(word), word) for word in words)
--
Greg
___
Python-ideas mailing list
Python-ideas@
On Tue, Jul 3, 2018 at 12:01 PM, David Mertz wrote:
> ... but I STILL like a new collections.Grouping (or collections.Grouper)
> the best.
>
me too.
> It might overcome Guido's reluctance... and what goes there is really
> delegated by him, not his own baby.
>
Is collections anyone in particu
I admit a hypothetical itertools.grouping that returned incrementally built
dictionaries doesn't fill any simple need I have often encountered. I can
be hand-wavy about "stateful bucketing of streams" and looking at
windowing/tails, but I don't have a clean and simple example where I need
this. T
It seems a really stupid reason to make this choice, but:
If we make a Grouping class, it has an obvious home in the collections
module
If we make a grouping (or grouped) function, we don't know where to put it
But since I like the Grouping class idea anyway, it's one more reason...
-CHB
On T
On Tue, Jul 3, 2018 at 8:33 AM, Steven D'Aprano wrote:
> but why are we using key values by hand when grouping ought to do it for
>
us, as Michael Selik's version does?
>
> grouping(words, key=len)
because supplying a key function is sometimes cleaner, and sometimes uglier
than building up
On Tue, Jul 3, 2018 at 8:24 AM, Steven D'Aprano wrote:
> On Tue, Jul 03, 2018 at 09:23:07AM -0400, David Mertz wrote:
>
> > My problem with the second idea is that *I* find it very wrong to have
> > something in itertools that does not return an iterator. It wrecks the
> > combinatorial algebr
On Fri, Jun 29, 2018 at 10:53:34AM -0700, Michael Selik wrote:
> Hello,
>
> I've drafted a PEP for an easier way to construct groups of elements from a
> sequence. https://github.com/selik/peps/blob/master/pep-.rst
Seems useful, but I suggest that since it has to process the entire data
set
On Tue, Jul 03, 2018 at 04:12:14PM +0200, Nicolas Rolin wrote:
> I agree the examples have lisp-level of brackets. However by using the fact
> tuples don't need brackets and the fact we can use a list instead of an
> iterable (the grouper will have to stock the whole object in memory anyway,
> and
On Tue, Jul 03, 2018 at 09:23:07AM -0400, David Mertz wrote:
> But before putting it on auto-archive, the BDFL said (1) NO GO on getting a
> new builtin; (2) NO OBJECTION to putting it in itertools.
>
> My problem with the second idea is that *I* find it very wrong to have
> something in itertool
2018-07-03 14:58 GMT+02:00 David Mertz :
> On Tue, Jul 3, 2018 at 2:52 AM Chris Barker via Python-ideas
>
> What you've missed, in *several* examples is the value part of the tuple
> in your API. You've pulled out the key, and forgotten to include anything
> in the actual groups. I have a hunch
I'd prefer to simply write an example for the documentation or clarify the
existing ones, then add good answers to StackOverflow questions.
On Tue, Jul 3, 2018, 6:23 AM David Mertz wrote:
> Guido said he has mooted this discussion, so it's probably not reaching
> him. It took one thousand fewe
On Tue, Jul 3, 2018 at 9:23 AM David Mertz wrote:
> Guido said he has mooted this discussion, so it's probably not reaching
> him.
>
I meant 'muted'. Hopefully he hasn't 'mooted' it.
--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the ha
Guido said he has mooted this discussion, so it's probably not reaching
him. It took one thousand fewer messages for him to stop following this
than with PEP 572, for some reason :-).
But before putting it on auto-archive, the BDFL said (1) NO GO on getting a
new builtin; (2) NO OBJECTION to putt
On Tue, Jul 3, 2018 at 2:52 AM Chris Barker via Python-ideas <
python-ideas@python.org> wrote:
> I'd write:
>>
> map(len, words)
>>
>> But I'd also write
>> [len(fullname) for fullname in contacts]
>>
>
> map(lambda name: name.first_name, all_names)
> vs
> [name.first_name for nam in all n
On Mon, Jul 2, 2018 at 11:50 PM, Chris Barker wrote:
> - keep the key function optional parameter.
> - add a value function optional parameter. -- it really makes any case
> where you don't want to store the whole item a lot easier.
>
> - Have the default key function be itemgetter(0) and the def
23 matches
Mail list logo
