Accessor Recipe - Style Question

[jbrockmendel]

Following up on discussion in #14781 , I am unifying the code that creates the str, cat, and dt accessors, and making/documenting a recipe for creating custom accessors. Two questions before I push forward, both revolving around methods like DataFrame._add_series_or_dataframe_operations (slightly different case, but close enough) that are called immediately after the class definitions, then never needed again.

1. Are these needed in the user-facing namespace for some reason? If not, can we wedge them into _dir_deletions? I know the leading underscore makes it private, but dir(pd.DataFrame) and dir(pd.Series) have 444 and 441 members respectively. This gets pretty imposing.

2. In many cases these methods are called immediately after the class definition, but others like ops.add_special_arithmetic_methods will be easy to miss if you don't know to look for it. One alternative that I am considering for the Accessors is applying a decorator to a class. Effectively replace

class Foo:
[...]

Foo._setup_methods(["bar", baz"])

with

@_setup_methods(["bar", "baz"])
class Foo:
[...]

The question being: is there a convention against using the latter approach?

[jreback]

1. Are these needed in the user-facing namespace for some reason? If not, can we wedge them into _dir_deletions? I know the leading underscore makes it private, but dir(pd.DataFrame) and dir(pd.Series) have 444 and 441 members respectively. This gets pretty imposing.

not sure what you are mean here. accessor are by-definition namespaces that make the discovery easier and much more geared to the dtype.

2. In many cases these methods are called immediately after the class definition, but others like ops.add_special_arithmetic_methods will be easy to miss if you don't know to look for it. One alternative that I am considering for the Accessors is applying a decorator to a class. Effectively replace

Why is this a problem? There are methods that are generically implemented which belong only to Series, only to DataFrame, to both (and possibly include Panels). So these are layered inclusion methods. You can certainly refactoror, not sure if the decorator syntax is better here. Pls make sweeping changes in separate PR's

[jreback]

closing this. You can comment on the other issues is prob easier.

[shoyer]

The question being: is there a convention against using the latter approach?

I think switching to decorators would be a welcome cleanup (but indeed, please save it for a separate PR).