CLN: Use consistent imports in tests

[h-vetinari]

A while ago, I got the review from @jreback that:

• Replace instances of pd. with direct imports (from review TST/CLN: series.duplicated; parametrisation; fix warning #21899 (comment)):

  don’t import pd, directly import instead

• Replace direct use of assert_..._equal with the tm.assert_..._equal
  (from review TST/CLN: series.duplicated; parametrisation; fix warning #21899 (comment)):

  use tm; don’t import assert_series_equal

I kept applying these rules until #22730, where @jreback then said:

Before we do any more of this
[quote of the above]
I would like a lint rule to see what is what (and basically list the offenders as exclusions for now).
We have been changing things like this for a long time and I think we somtimes change them back (e.g. to use the imports of assert_*, rather than tm., and to use the pd.* rather than the direct imports.

and further:

let's see which way is more common, then have a lint rule to enforce it, rather than ad-hoc conversions (which has been the policy up till now).

Opening this issue for someone to write such a lint rule, because I wouldn't know where to start.

[pambot]

@h-vetinari I'll give this a shot

[h-vetinari]

@pambot Great!

[pambot]

@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 ci/lint.sh (but that's probably just for CI) and a suggestion on StackOverflow to modify a tox.ini file (but it doesn't look like Tox is supported currently)

[h-vetinari]

@pambot
It was not my idea but @jreback's. I opened this issue to record that review feedback for someone else, because I don't know how to tackle setting up custom linting rules...

Any tips for @pambot, @TomAugspurger @datapythonista, maybe?

[TomAugspurger]

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.

[TomAugspurger]

On this issue in particular, I don't have strong preferences.

• I prefer tm.assert* over assert*
• I slightly prefer pd. rather than directly importing top-level things in the test files

[pambot]

Sounds good, I'm cool with waiting.

[h-vetinari]

@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.

[TomAugspurger]

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> .

[jreback]

just to be clea
this is really aimed at the test files
we may extend this to the code itself at a later point