Clarify documentation for consider-using-from-import

[wshanks]

Description

The consider-using-from-import checker only works on submodule imports, not member imports because, e.g., import pandas.DataFrame is not valid syntax (import <member>). This PR removes "member" from the documentation and changes the example to a submodule import.

By the way, I could not find a justification for this checker in the documentation or in the PR that created it. Is it that the from ... import syntax uses less characters? (Personally, I prefer import a.b as b to from a import b to avoid problems with someone later defining b as a member in a.py and that taking precedence over the submodule import but I didn't know if I was missing another advantage to the from syntax).

Type of Changes

	Type
✓	📜 Docs

[coveralls]

Coverage remained the same at 92.049% when pulling ffbc5ed on wshanks:main into 8d05dcf on PyCQA:main.

[Pierre-Sassoulas]

Thank you for this, it slipped during review.

I prefer import a.b as b to from a import b to avoid problems with someone later defining b as a member in a.py and that taking precedence over the submodule import

Here's the discussion that lead to the implementation of consider-using-from-import: #2309. I did not think this check was opinionated when merging it, do you think it should be optional ? I don't think the order of precedence should be relied upon. If you have to rely on that, something is wrong with the person maintaining the lib you're using 😄

[wshanks]

I did not think this check was opinionated when merging it, do you think it should be optional ?

Hmm, I was a bit thrown off when first seeing this error after updating because I was used to thinking of import ... for modules and from ... import ... for members, but I will get used to using from ... on submodules. So I think it is okay to think of this checker as not opinionated (every checker that produces a warning is probably a little opinionated but this one no more than others). If someone ever does make a change that causes a member to shadow a submodule, it is very likely that pylint will flag some problem from the differences in attributes between the module and the member variable....