-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
Remove Internal Imports from Top Level Pandas Module #25923
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
we should always be using the Note we generally also should/mostly are using So option 1 lgtm (though could be option 2 as well, not a big deal) |
Great thanks for the direction Jeff.
Yea this issue was mostly spurred by existing places in the code base where we are already importing DataFrame. Good to have this as a standard when we need to add typing to modules where that isn't already explicitly imported though |
Alternately solved by #26019 |
Ah, that seems as the better solution in the end! |
Mostly driven by MyPy (which has it's own import mechanism) we get 67 failures as of now on master for imports coming from the top level pandas namespace:
Specifically with MyPy doing explicit imports of these versus current wildcard helps, as does importing directly from the modules where these are defined.
With MyPy if we wanted to we could always ignore these imports, but at the same time I was wondering if we really should be importing from the top level within the code base as it theoretically makes our import machinery more convoluted than it needs to be.
I spoke with @jorisvandenbossche on Gitter yesterday about this and there were two things we discussed:
from pandas.core.frame import DataFrame
pandas.core
you would still dofrom pandas.core.frame import DataFrame
, but outside of core you would dofrom pandas.core.api import DataFrame
FWIW I think option 2 is kind of nice, because it abstracts where within sub packages we choose to place particular items and allows things like
from pandas.core.api import DataFrame, Series
instead of having two separate importsCurious if anyone has any thoughts or objections to either of the options presented above versus current allowance of imports from top level
The text was updated successfully, but these errors were encountered: