Deprecate getting the name from MultiIndex.levels

[TomAugspurger]

Follow up to #27242.

#27242 (comment)

[TomAugspurger]

FWIW, I'm probably OK with not deprecating .levels[i].name. I think it's a pretty common pattern, and it would be a large deprecation. The only downside is that you can get in a state where setting the name of a level is silently not reflected in the MI. But I can live with that.

In [6]: idx = pd.MultiIndex.from_product([['a'], [1, 2]], names=['a', 'b'])

In [7]: idx.levels[0].name = 'c'

In [8]: idx
Out[8]:
MultiIndex([('a', 1),
            ('a', 2)],
           names=['a', 'b'])

[topper-123]

So, where are we wrt to renaming to categories?

IMO the name categories (or a different name than levels) would actually be better, because levels also refers to the "columns" in a MultiIndex, e.g. in df.groupby(..., level='x').

[TomAugspurger]

I think deprecating .levels in favor of something else (.categories) is a big change, much bigger than .codes was. My initial reaction is that the benefits to renaming aren't there yet, but happy to be convinced otherwise.

cc @jorisvandenbossche.

[jorisvandenbossche]

I am personally also not fully convinced that renaming levels is worth it.
It's true that "levels" is used for somewhat different things (in keyword arguments it refers to the full level of a multi-index, while the attribute only gives the unique values for that level). But it's been like that, and we also have get_level_values for the other.

[TomAugspurger]

Any more thoughts here?

I'm probably OK with the behavior on master

1. Getting the level name with .levels[i].name continues to work
2. Setting .levels[i].name will silently do nothing.

If we go with that, we'll need to thoroughly document this behavior.

Regardless of what we do, the release notes in https://dev.pandas.io/docs/whatsnew/v1.0.0.html#multiindex-levels-do-not-hold-level-names-any-longer will need to be updated.

[jreback]

would be great if we could show a warning for 2 (but still do nothing)