2018-07-03 14:58 GMT+02:00 David Mertz firstname.lastname@example.org:
On Tue, Jul 3, 2018 at 2:52 AM Chris Barker via Python-ideas <pytho email@example.com
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 that if your API were used, this would be a common pitfall.
I think this argues against your API and for Michael's that simply deals with "sequences of groupable things." That's much more like what one deals with in SQL, and is familiar that way. If the things grouped are compound object such as dictionaries, objects with common attributes, named tuples, etc. then the list of things in a group usually *does not* want the grouping attribute removed.
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 if it is really big, use itertools.groupby who is designed exactly for that) For example grouping(((len(word), word) for word in words)) can be written grouping([len(word), word for word in words])
which is less "bracket issue prone". The main advantage of having this syntax is that it gives a definition very close to the one of a dict comprehension, which is nice considering want we obtain is a dict (without that feature I'm not sure I will never attempt to use this function). And that allows us to have the same construction syntax as a dictionary, with an iterable of (key, value) pair ( https://docs.python.org/3.7/library/stdtypes.html#dict).
So that was an interesting exercise -- many of those are a bit clearer
(or more compact) with the key function. But I also notice a pattern -- all those examples fit very well into the key function pattern:
Well those were the examples used to showcase the keyfunction in the PEP. This is as bad as it gets for the "initialization by comprehension" syntax.
I agree still (after all, I proposed it to Michael). But this seems minor, and Guido seems not to like `collections` that much (or at least he commented on not using Counter ... which I personally love to use and to teach).
Actually counter is very very close to grouping (replace the append with starting value  in the for loop by a += with starting value 0 and groupping becomes a counter), so adding it to collections makes the more sense by a long shot.
As far as I'm concerned, CHB semantics and syntax for the groupper object does everything that is needed, and even a little bit too much. It could be called AppendDict and just accept a (key, value) interable in input, and instead of doing dict[key] = value as a dict does, does dict[key] = [value] if key not in dict else dict[key] + [value] (and should be coded in C I guess)