Pandas version checks

  • [X] I have checked that this issue has not already been reported.

  • [X] I have confirmed this bug exists on the latest version of pandas.

  • [X] I have confirmed this bug exists on the master branch of pandas.

Reproducible Example

import pytest

with pytest.warns(FutureWarning):
    from pandas.core.indexes.numeric import Int64Index

Issue Description

Int64Index is deprecated and should warn when imported from its actual location, not just from the top level.

Expected Behavior

Warn with FutureWarning

Installed Versions

1.4.0.dev0+1044.g0769386a23

Comment From: bashtage

It also doesn't warn when instantized. I suspect the same is true of Float64Index

Comment From: phofl

We declare pandas.core as private in the docs

https://pandas.pydata.org/docs/reference/index.html

So I think this is fine?

Comment From: bashtage

I guess so. I was not aware of that.

I still wonder if an instantiation warning should be given though? I've found the move from the nearly canonical Int64Index to the general-purpose NumericIndex to be pretty large in a number of projects.

Comment From: jreback

we would have to make a private version in order to remove even this reference so maybe not worth it -

maybe what we should do is to finally do the move to make core actually private with depreciation

Comment From: phofl

@jreback should we do this for 1.5? Otherwise would be stuck till 3.0

Comment From: rhshadrach

How do we deprecate either the indices (e.g. pandas.core.indexes.numeric.Int64Index) or pandas.core?

For Int64Index we can rename to _Int64Index throughout pandas' usage of it and then implement __getattr__ in the numeric module, but this seems like a lot of refactoring and then we'd need to hijack the class name (_Int64Index.__name__ = "Int64Index"). We could avoid having to rename usage throughout pandas via stack inspection on import (similar to find_stack_level).

For pandas.core, the only way I can see deprecating is to inspect the stack for every submodule to see who is importing. For example, as far as I know from pandas.core.groupby import generic will never trigger a __getattr__ call in pandas.__init__.

If there are efficient / low effort / low churn ways to implement these, I'm supportive, but otherwise it we properly document pandas.core as being private and this seems to be common practice (e.g. NumPy does the same).

Comment From: phofl

Scipy did something similar recently (see https://docs.scipy.org/doc/scipy/release.1.8.0.html#clear-split-between-public-and-private-api)

The way to go would be to rename core to _core and show deprecation warnings if core is used as long as the deprecation is not enforced

Comment From: rhshadrach

Thanks @phofl - this seems less burdensome than I originally thought.

and show deprecation warnings if core is used as long as the deprecation is not enforced

Just to make sure I'm following... To not break from pandas.core.groupby import generic and the like, after renaming to _core, we'd need to have pandas.core with essentially a skeleton of submodules with __init__.py that import * from the corresponding _core submodule. There would only need to be a warning in pandas.core.__init__ since this will be imported anytime any submodules further down are used.

Comment From: phofl

This is what I would have done, yes.

Comment From: phofl

Closing here, we have a coupler of other issues where we discuss deprecating core