REF: rename _data->_mgr

[jbrockmendel]

We have a long-term goal of reducing the exposed surface of the internals. One difficulty is that it is not trivial to identify all the places that access the internal, in part because grepping for ._data will turn up a ton of non-internals Index and EA attributes. By renaming _data -> _mgr, we'll make it easier to identify places that we can de-internalize.

If this isn't a route we want to go down (in the past when I've pitched this it hasn't caught on), I'll try to keep this up-to-date so we an use the diff as the relevant reference.

[jorisvandenbossche]

Your previous attempt was here: #27254

I am +1 on a rename, it will indeed make checking all cases where the BlockManager is accessed much easier to find.

But, we will need to keep _data as an alias. The BlockManager is enough a fundamental part of pandas that other projects rely on it (eg arrow does)

[jreback]

ok with this, I would add back a ._data property to BlockManager with a DeprecationWarning to get downstream to remove this dep. Also create an issue to remove this at some point.

[jreback]

ping when green (maybe need to rebase at end of day today)

[jbrockmendel]

ok with this, I would add back a ._data property to BlockManager with a DeprecationWarning to get downstream to remove this dep. Also create an issue to remove this at some point.

The property is already there, but not currently with a DeprecationWarning. @jorisvandenbossche are you OK with warning?

[jorisvandenbossche]

Since we are only doing this to make searching in our code base easier, and not because something is broken or it is a wrong name or something else we try to solve, I don't see a reason why we should bother ourselves and downstream packages with a deprecation cycle.

[jbrockmendel]

I don't see a reason why we should bother ourselves and downstream packages with a deprecation cycle.

I think what @jreback is getting at is that we would like to wean downstream packages off of internals, but I agree that this can be considered separately from the renaming.

[jorisvandenbossche]

Well, right now, I suppose most downstream packages would probably just add some compatibility code to use the old/new name depending on the version, as they might have legitimate use cases for getting the blocks.
So since we are not changing anything but the name (eg we don't provide an alternative API to get the blocks), I am not sure what the value is of deprecation.

[jbrockmendel]

So since we are not changing anything but the name (eg we don't provide an alternative API to get the blocks), I am not sure what the value is of deprecation.

Yah, im fine with that. Let's stick a pin into deprecation and just do the renaming.

[jbrockmendel]

i think we have consensus here?

[jorisvandenbossche]

@jreback can you respond here?

[jreback]

ok to merge, though still think we should show a DeprecationWarning (to have any libraries change to use the new code) and its not user visible anyhow (can be done as a followon).

[jorisvandenbossche]

Thanks Brock!

[jorisvandenbossche]

@jreback can you open an issue for that if you want to push for it? (I am still -1 based on my explanation above)

[jreback]

@jreback can you open an issue for that if you want to push for it? (I am still -1 based on my explanation above)

sure