Looks like this might be a bit of a bug?
test.py:from some_local_module import test
from exceptions import TestException
raise TestException
$ isortisort flagged the import of TestException because it thought it should come before some_local_module.
There shouldn't be an issue because there is no longer an exceptions module in Python 3. I expected the isort command to pass.
This is... complicated... you could technically call it a bug, but is also acting based on the expected outcome giving the design. It is hard, at times, for isort to correctly identify where stdlib modules are located to correctly automatically determine if an import is part of the stdlib because of the various places within a system they can be located. To get around this, there is a master list of all imports that have ever been known as being part of the stdlib. One of the key design goals of isort is to be able to run on any highly used version of Python, over very large complex code bases all at once, that may contain different pieces that are designed to run on different Python runtimes, without having to run isort on that same Python version. That makes it impossible for isort to even have a mapping of Python version -> stdlib import names - without say requiring a user to set a flag.
As an alternative: You could easily solve your given problem without an upgrade to isort by doing isort --project exceptions to explicitly identify that module name as a project level import locally.
Thanks!
~Timothy
@timothycrosley, makes sense! Thanks for the detailed response!
Most helpful comment
This is... complicated... you could technically call it a bug, but is also acting based on the expected outcome giving the design. It is hard, at times, for isort to correctly identify where stdlib modules are located to correctly automatically determine if an import is part of the stdlib because of the various places within a system they can be located. To get around this, there is a master list of all imports that have ever been known as being part of the stdlib. One of the key design goals of isort is to be able to run on any highly used version of Python, over very large complex code bases all at once, that may contain different pieces that are designed to run on different Python runtimes, without having to run isort on that same Python version. That makes it impossible for isort to even have a mapping of Python version -> stdlib import names - without say requiring a user to set a flag.
As an alternative: You could easily solve your given problem without an upgrade to isort by doing
isort --project exceptionsto explicitly identify that module name as a project level import locally.Thanks!
~Timothy