ENH: NDFrame.axis_ops

[jbrockmendel]

Refactor out NDFrame methods that operate only on axes into an obj.axis_ops namespace. I'd want to do this in conjunction with a deprecation of the methods themselves xref #52110

[jbrockmendel]

@phofl updated to include more underscores

[mroeschke]

Shouldn't these example show the new usage of df.axis_ops.foo?

[mroeschke]

Does axis_ops render in the API reference docs?

[mroeschke]

Could you just change this to use axis_ops.swaplevel?

[jbrockmendel]

i dont think we'd want to change this in the old doc

[mroeschke]

Okay could we use code block instead?

[mroeschke]

Could you also ensure the API reference page advertises e.g. DataFrame.axis_ops.foo instead of DataFrame.foo?

[jbrockmendel]

Could you also ensure the API reference page advertises e.g. DataFrame.axis_ops.foo instead of DataFrame.foo?

I'm not clear on how that works. For e.g. swaplevel would I remove the entry for Series.swaplevel in source/reference/series.rst? I could add Series.axis_ops in the same place but will adding Series.axis_ops.swap_level render?

[mroeschke]

I could add Series.axis_ops in the same place but will adding Series.axis_ops.swap_level render?

I think so. I think we have an autosummary template that renders our accessors (like Series.str.foo)

[jbrockmendel]

An alternative: just deprecate tz_localize, tz_convert, to_timestamp, to_period and leave the others as-is

[mroeschke]

Yeah actually that's a good point. if there's an index.foo() alternative might as well deprecate the DataFrame.foo() behavior

[jbrockmendel]

Closing for lack of interest, will do individual deprecations in the subset of cases where that is feasible

[jbrockmendel]

Reopening, will merge main and push shortly.

[jorisvandenbossche]

FWIW, while I understand the reason for adding something like this, I would not be very enthusiastic about an axis_ops accessor (from a user design point of view, it feels rather awkward)