Consider standardizing imports from the standard library

I love isort and probably run it hundreds of times a day. It standardizes all of my imports so I never have to think about them.

One pain point I have is that I would like to standardize the imports from the standard library where there are aliases. Specifically, in Python 3.10, I believe that typing.Collection is equivalent to collections.abc.Collection. It would be nice to just pick one (ideally the latter, I think).

This may be a complicated feature since in earlier versions of Python, these are not equivalent. Probably the simplest implementation is for the user to present a list of pairs to isort for conversion.

[ucodery]

It does have the --py option to specify a version of the standard library to target, but I’m not so sure it is used often and without that knowledge isort is left to guess -

No need to guess. If the target version range isn’t explicitly specified, then no standardization needs to be done.

I think we agree there.

The problem with this one is that import foo.bar will only work if bar is a submodule

That’s why I said that this should be done for submodules only. And that’s why the comments I illustrated point out that this standardization provide an importer guarantee about the type of the imported symbol.

Yes, I think you understand the restrictions of when from foo import bar as baz can be changed to import foo.bar as baz. But my point is that I’m not sure that isort can understand when this is safe - not without a lot of new code - since it currently doesn’t understand types or verify imports after writing them. But this is probably off-topic unless you are asking for both in this ticket.

isort works on files statically, one file at a time, and treats the imports mostly as text. would involve massive growth in the inspection engine of isort for no gain of the primary use of isort.

First of all, the principle suggestion of this issue (standardizing the standard library imports) would not require any change to this textual interpretation or any introspection at all.

I agree that the original ask would probably not require any new introspection, just some lookup tables.

I understand your point about creep, but it has to be balanced against the value of the functionality from the user’s perspective. Checking for unused imports for example, doesn’t need too much in the way of introspection. It’s not more than forty lines of code to iterate over the parse tree looking for names. And the value is enormous.

Perhaps if there were no tools checking for unused imports now, it would be a great new feature. But there are already several other linting tools that check this, and adding it to isort will probably not have the effect of maintainers dropping those other tools as they check for other smells. In my view, if every tool had a strict single responsibility design, unused imports would be under the same tool as unused variable names and uncalled functions, not an import sorter. But are you actually adding this feature ask to the others already brought up?

[NeilGirdhar]

But my point is that I’m not sure that isort can understand when this is safe - not without a lot of new code

Yes, agreed.

But this is probably off-topic unless you are asking for both in this ticket.

Right, I’m not.

Perhaps if there were no tools checking for unused imports now, it would be a great new feature. But there are already several other linting tools that check this,

I’m not asking for a check though. I’m asking for import rewriting, which I currently do with

find . -name "*.py" ! -name "__init__.py" -exec autoflake --in-place --remove-all-unused-imports {} +

So, I disagree that there are “several linting tools that do this”. There is one tool that does this, and it’s not exactly accessible.

I agree that the original ask would probably not require any new introspection, just some lookup tables.

Great, we’re on the same page.

But are you actually adding this feature ask to the others already brought up?

No, I only mentioned these in response to an argument about “single responsibility”.