-
-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
CLN: Use consistent imports in tests #23018
Comments
@h-vetinari I'll give this a shot |
@pambot Great! |
@jreback Pinging you because it was your idea to add the linting rule - I'm happy to do it, but what's the best way to get get started? I looked around, and all I can find is |
@pambot Any tips for @pambot, @TomAugspurger @datapythonista, maybe? |
You may want to wait till #22854 and #22863 are in before working on this too much, since those are changing up the linters. I would also wait for some consensus on what we want these import rules to look like. Finally, I think @alimcmaster1 has some plans for a larger import order refactor using isort. That will be a large change that'll cause conflicts in a lot of outstanding PRs. Depending on the size of the changes for this issue, it may be good to do those two PRs close together, so that people only have to fix conflicts once. |
On this issue in particular, I don't have strong preferences.
|
Sounds good, I'm cool with waiting. |
Thanks for the infos/feedback. Re:
there might be good reasons for having different rules between |
Correct. Inside pandas (not tests) we'll often use direct imports if only
to avoid circular imports.
…On Mon, Oct 8, 2018 at 1:20 PM h-vetinari ***@***.***> wrote:
@TomAugspurger <https://github.com/TomAugspurger>
Thanks for the infos/feedback.
Re:
I slightly prefer pd. rather than directly importing top-level things in
the test files
there might be good reasons for having different rules between pandas/core
and pandas/tests, but in the former, it's almost exclusively(?) direct
imports.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#23018 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABQHIr6v8d_Vj0cCX2J1IPXLyYSSlD-uks5ui5eCgaJpZM4XLcIc>
.
|
just to be clea |
I just had a quick look at this. Using the following search_text = For the test utils, the In the Wdyt? |
i would be +1 in applying those as lint rules (have to fix the current first of course) prefer
|
The more I've been reading up on it I would prefer Guido himself recommends against using |
That may be true for the top level modules, but it is not true anymore when submodules are targeted directly, i.e. the following are not equivalent:
Number 1. cannot be used in any code that defines something that is itself exposed through the toplevel module. Number 2. can be imported even there (except within For this reason, it makes sense to stick with option 2. IMO, because it can be used consistently in more situations (and especially within the core itself). |
I don't believe that is true. read_json for instance is exposed in the top level and imports from there as well. Even
I didn't realize this was one of the options, but I am -1 on that. Tests should generally be importing objects from the same locations that an end user would |
Interesting. That goes against my experience but python may have gotten smarter about this with doing some lazy importing. For example,
There's probably a misunderstanding here. For tests, both styles are fine. But since you were specifically aiming at "a better standard throughout code base", I responded that the core has different restrictions. And if a uniform standard is desired, then tests should import |
Ah OK - sorry yea I think we misunderstood each other on the last post. I was specifically talking about tests. Expanding on other areas in the code base though, # categorical.py
import dtype as dt
class Categorical:
pass
# dtype.py
import categorical as cat
#from categorical import Categorical
class Dtype:
def __init__(self):
self.known_types = [cat.Categorical]
if __name__ == "__main__":
print("Hello world") If you uncomment and try to do FWIW I'm not an expert here so maybe simple I'm overlooking, but generally just prefer to go with what Guido suggests on language elements :-) |
That's kind of what left me confused with your original comment - first you say you'd prefer |
There was a typo in my original comment that I've since fixed, but may have confused us both. Quoting directly from the article:
|
I think @WillAyd's reasoning is sound and convinced me. It seems like using As there's no clear prefered version in the current test suite I'd rather convert everything to If no one has further objections, I'd already start writing a follow-up ticket for the |
let's hold off on this one use the |
Looks like #33203 is the more up to date discussion on this topic. Closing favor of that thread |
A while ago, I got the review from @jreback that:
assert_..._equal
with thetm.assert_..._equal
(from review TST/CLN: series.duplicated; parametrisation; fix warning #21899 (comment)):
I kept applying these rules until #22730, where @jreback then said:
and further:
Opening this issue for someone to write such a lint rule, because I wouldn't know where to start.
The text was updated successfully, but these errors were encountered: