-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
CLN: update imports in tests #29275
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
Merged
Merged
CLN: update imports in tests #29275
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think doing this will conflict with what @SaturnFromTitan is or will be doing in other PRs. I think better to keep as
pd.Period
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We didn't agree on a solution for this yet - so I don't mind. For now, I'm only focussing on imports from
pandas.util.testing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As long as Period is already in the namespace, I think this is a strict improvement. If later this gets reverted to only-pd.Period I'm mostly fine with that too.
One reason I like the not-
pd
pattern is that I can look at imports and get an idea of what is tested in this module.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well i am +1 on not using the pd namespace except in a very few cases in tests (eg when we are actually testing the ls namespace)
we should simply use the
from pandas import Series...
pattern it is immediately obvious what is and what is not imported
and there is no confusion about what to use
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is getting into personal development preferences but as a counter argument I sometimes find these imports very annoying. When debugging the pd namespace is almost always available, yet when copy pasting blocks of code that use this import machinery you then have to go up and see what is imported from top of the module.
But that aside... the bigger point is that (beyond tests, where this probably doesn’t matter) the from ... imports cause circular references and we will never be able to enforce those consistently. We end up in a weird state like #29133 where there isn’t a good rhyme or reason to where we place imports except for the fact that we tried it at one point and it caused a circular ref, so when then moved it somewhere else.
Ultimately I hope we don’t have to think about imports or circular references at all
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it’s not personal preference but just like we avoid * imports
having a global space is a bad idea
explicit is always better than implicit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1. Fortunately that's not an issue for most of the tests.