ENH: add Groupby.attrs namespace to access groupby attributes

[topper-123]

Feature Type

• Adding new functionality to pandas

• Changing existing functionality in pandas

• Removing existing functionality in pandas

Problem Description

The attributes of groupby objects are currently accessible from the groupby directly, but they are hidden, i.e. they don't show up in dir calls:

>>> df = pd.DataFrame({"a": [1, 2, 3], "b": [1, 2, 3]})
>>> dfg = df.groupby("a")
>>> dfg.keys
'a'
>>> "keys" in dir(dfg)
False
>>> dfg._hidden_attrs
frozenset({'as_index',
           'axis',
           'dropna',
           ...,
           'observed',
           'sort'})

I assume this has been done because we want the groupby attributes to be groupby methods / to not make its namespace noisy.

Feature Description

It is beneficial to be able to access the attributes and instead of using hidden attributes I propose a public/non-hidden attrs namespace, so to access an attribute, users can to e.g. dfg.attrs.keys.

This can also form the basis for a groupby repr and the groupby repr could take its data from the groupby attrs.

I'm not sure about the attrs name because we have already DataFrame.attrs, so I'm definitely open to suggestion for better names.

Alternative Solutions

The alternatives are:

1: keep things as they are / keep the attributes hidden
2. make the hidden attributes public

IMO these have disadvantages: For point 1 it is that the attributes are difficult to discover and for point 2 the disadvantage is that the groupby namespace becomes very large and groupby methods and attributes become mixed, making discoverability of groupby methods difficult.

An attrs attribute would avoid both of those disadvantages.

Additional Context

No response

[jreback]

can u show what one would actually do with these?

[topper-123]

can u show what one would actually do with these?

This would help introspecting groupby objects. Concretely, I often pass groupby objects through several functions, and if something unexpected happens I think it's worthwhile to be able to inspect the groupby object to understand what's happening.

[rhshadrach]

Overall I'm +0. I personally don't use groupby objects like this (they are always created / thrown away), but I can see the benefit. If we are going this route, I certainly don't think we should allow setting them (e.g. gb.attr.keys = [1, 2, 3]).

But I'm not sure on mutability - if a user is getting gb.attr.keys or gb.attr.obj, are we returning objects that they can mutate (perhaps accidentally) the internal state of the groupby object and create perhaps hard to understand errors, or are we going to return copies. Currently users can do this via gb.obj and it doesn't seem to cause issues, but maybe users just don't know about it.

I'd be opposed to exposing _obj_with_exclusions or _selected_obj in their current state, but would be more favorable once it gets cleaned up.

[jbrockmendel]

Just to be clear, this wouldn't mean the same thing as DataFrame.attrs? If so, can we give it a distinct name?

[rhshadrach]

I understand the appeal of not polluting dir, but is this something that is commonly done by libraries? From what I've seen, no one attempts to hide protected attributes from appearing. I'd be more positive on prefixing the attributes with an underscore and remove our override of dir.