On Tue, Jul 3, 2018 at 8:24 AM, Steven D'Aprano email@example.com 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 algebra of the module.
hmm -- that seems to be a pretty pedantic approach -- practicality beats purity, after all :-)
I think we should first decide if a grouping() function is a useful addition to the standard library (after all: "not every two line function needs to in the stdlib"), and f so, then we can find a home for it.
personally, I'm wondering if a "dicttools" or something module would make sense -- I imagine there are all sorts of other handy utilities for working with dicts that could go there. (though, yeah, we'd want to actually have a handful of these before creating a new module :-) )
That said, it's easy to fix... and I believe independently useful. Just
make grouping() a generator function rather than a plain function. This lets us get an incremental grouping of an iterable.
We already have something which lazily groups an iterable, returning groups as they are seen: groupby.
What makes grouping() different from groupby() is that it accumulates ALL of the subgroups rather than just consecutive subgroupings.
well, yeah, but it wont actually get you those until you exhaust the iterator -- so while it's different than itertools.groupby, it is different than itertools.groupby(sorted(iterable))?
In short, this wouldn't really solve the problems that itertools.groupby has for this sort of task -- so what's the point?
As for where it belongs, perhaps the collections module is the least
That depends some on whether we go with a simple function, in which case collections is a pretty bad fit (but maybe still the least worse).
Personally I still like the idea of having this be special type of dict, rather than "just a function" -- and then it's really obvious where to put it :-)