ENH: use correct dtype in groupby cython ops when it is known (without try/except)
State: closed

Addresses part of #37494. And xref https://github.com/pandas-dev/pandas/pull/38162/files#r536191377

cc @jorisvandenbossche 

Labels:
name: Refactor
description: Internal refactoring of code
name: Groupby

Comments:
> Is there somewhere a list of all possible values for how in this _cython_operation?

groupby.ops L349
```
    _cython_functions = {
        "aggregate": {
            "add": "group_add",
            "prod": "group_prod",
            "min": "group_min",
            "max": "group_max",
            "mean": "group_mean",
            "median": "group_median",
            "var": "group_var",
            "first": "group_nth",
            "last": "group_last",
            "ohlc": "group_ohlc",
        },
        "transform": {
            "cumprod": "group_cumprod",
            "cumsum": "group_cumsum",
            "cummin": "group_cummin",
            "cummax": "group_cummax",
            "rank": "group_rank",
        },
    }
```
> Do we have sufficient testing for the changes?

Yes.

> so would really like to move this entire wrapping to a method on EA / generic casting. We do this in multiple places (e.g. also on _reduce operatiosn), and this is likely leading to missing functionaility in various places.

Agreed.  While it may not look it, this is a big improvement over what we had a week ago, where casting was being done in like 15 different places, and not at all obvious what we were special-casing.  Now it is down to two and very explicit what we are special-casing (i.e. what we need to improve)
> > Do we have sufficient testing for the changes?
> 
> Yes.
> 
> > so would really like to move this entire wrapping to a method on EA / generic casting. We do this in multiple places (e.g. also on _reduce operatiosn), and this is likely leading to missing functionaility in various places.
> 
> Agreed. While it may not look it, this is a big improvement over what we had a week ago, where casting was being done in like 15 different places, and not at all obvious what we were special-casing. Now it is down to two and very explicit what we are special-casing (i.e. what we need to improve)

ok great. i am fine with merging this tehn.
Thanks for the pointer to the list!
> Do we have sufficient testing for the changes?

We clearly didn't have sufficient testing .. as this apparently broke some cases that worked before (now, not necessarily the fault of this PR! but so good that I added some tests)

So some of the tests are still failing, because before we were using `maybe_cast_result` for integer dtypes, but now you changed that to use a straight ``_from_sequence``, which fails in some of the cases. 
Another part of the failing tests is simply because of not yet assigning the correct dtype in `maybe_cast_result_dtype`, related to my inline comments above.
@jreback I added this to the 1.2 milestone on purpose, as it's partly fixing a regression on master (which might not have been directly clear from the PR)
@jorisvandenbossche the entire point of an rc is that we do not need to keep waiting for the release

thus this was not needed to do in such a hurry for the rc

let's pls try to just release on time and less about trying to get every last PR in