API: Add pandas.api.aux

Revision 2:

Currently many intermediate classes can only be found in pandas.core, for example DataFrameGroupBy and SeriesGroupBy. These classes should not be instantiated directly, but may be necessary to access for users who use type-hinting. I think we should add these classes to a new API submodule, pandas.api.aux as they are auxiliary classes. Users shouldn’t need to know e.g. they are defined in pandas.core.groupby.generic.

Somewhat related: #6944, #19302

cc @pandas-dev/pandas-core @pandas-dev/pandas-triage for feedback.

Original

Currently one cannot run `from pandas import DataFrameGroupBy, SeriesGroupBy`. We should add these classes to the top level as they are particularly important for type-hinting in user code. Users shouldn't need to know they are defined in `pandas.core.groupby.generic`.

Revision 1

Currently one cannot run `from pandas import DataFrameGroupBy, SeriesGroupBy`. We should add these classes to a new API submodule, `pandas.api.trying` as they are particularly important for type-hinting in user code. Users shouldn't need to know they are defined in `pandas.core.groupby.generic`.

[topper-123]

+1 on somewhere in pd.api, I don’t have a very strong preference on pd.api.types or pd.api.typing. Maybe just make update the PR with your preferred solution (pd.api.typing?), remove the draft marker and see the response?

There are probably a few other classes that could be exposed publicly, e…g. Resampler is one I can think of, but there are probably others also.

[Dr-Irv]

In this sense, both numpy.typing and pandas.api.typing would contain classes for the user to add type hints to their code, regardless of if that user is going to use static type-checking.

I see your point. As long as we document it that way, I won’t stand in the way of calling it pandas.api.typing .