Description
The following is not standardized in a PEP but is generally agreed on by multiple type checkers and is mentioned in the scope of stub files in PEP484. See pytorch/pytorch#47027 (comment) for more pointers. Pytorch (in init.py) and numpy (in init.pyi) are two of the projects that already try to use redundant imports.
Is your feature request related to a problem?
When pandas becomes a py.typed library (#28142), static type checks need to know what is part of the public API and what isn't. PEP 484 outlines that imported modules are only part of the public API, if they follow the pattern of "import X as X" (for stub files). Pyright implemented this not only for stub files but also for "normal" python code (see https://github.com/microsoft/pyright/blob/main/docs/typed-libraries.md#library-interface).
Edit: mypy also complains about that when implicit_reexport=false
Describe the solution you'd like
Use redundant imports to signal what is part of the public API.
While this is not standardized for normal python code, pandas has/will have many .pyi files for its cython code (which is subject to PEP 484). It is probably more consistent to use redundant imports in the entire codebase, not only in .pyi files.
API breaking implications
Until pandas is a py.typed library, it would be good to have a clear statement what takes precedence to define the public API (in case there are mismatches between the documentation, import statements, or type annotations).
Additional context
When creating an empty py.typed file in the pandas directory and using pyright to validate the following code:
import pandas as pd
pd.DataFrame()error: "DataFrame" is not exported from module "pandas" (reportPrivateImportUsage)