Refactor groupby to use classes

[mjpieters]

The implementation is closely modelled on the cpython C implementation of the groupby iterator. This should be easier to reason about by humans and code scanners alike.

Closes #96

[maxfischer2781]

Very nice work! Indeed this is easier to reason about.

There's one thing missing that's needed for the async world but not the regular groupby: an aclose method on GroupBy and _Grouper. The generator implementation got them for free (though I'm not entirely sure whether the group.aclose behaviour was actually correct...).

As far as I can tell, _Grouper.aclose should just set state.current_group to None. GroupBy.aclose should close the current group as well as the iterator.

[mjpieters]

Are you sure? The GroupBy class is not an async generator, it's an async iterator; aclose() is there for automatic finalizing on loop exit for async generators, where the interpreter automatically registers aclose() and a first-iteration hook whenever one is created.

What will call aclose() on these? Unless you are proposing we also create a first-iteration hook and call sys.set_asyncgen_hooks(...)?

[mjpieters]

Okay, I just re-familiarised myself with the asyncstdlib iterator scoping document. I may not yet fully understand what code takes responsibility for calling aclose(), but I'm happy to implement these.

[mjpieters]

Implementations added; GroupBy delegates this to the _GroupByState instance (as it holds the iterator and the current group).

[maxfischer2781]

Thanks, this looks good to go!

What will call aclose() on these? Unless you are proposing we also create a first-iteration hook and call sys.set_asyncgen_hooks(...)?

The …_asyncgen_hooks and async generator aclose are the safety net if iterators are just dropped. The various explicit aclose methods are there so that people can force prompt cleanup when they need it.