Isort: Trying to import from local module called "exceptions" is caught

Created on 19 May 2017  路  2Comments  路  Source: PyCQA/isort

Looks like this might be a bit of a bug?

Environment

  • Python 3.6.0
  • isort 4.2.5

Steps to Reproduce

  1. Save the following code to a file called test.py:
from some_local_module import test
from exceptions import TestException

raise TestException
  1. Run isort: $ isort

Saw

isort flagged the import of TestException because it thought it should come before some_local_module.

Expected

There shouldn't be an issue because there is no longer an exceptions module in Python 3. I expected the isort command to pass.

bug enhancement

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 exceptions to explicitly identify that module name as a project level import locally.

Thanks!

~Timothy

All 2 comments

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!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

kevindaum picture kevindaum  路  4Comments

akaihola picture akaihola  路  3Comments

pawamoy picture pawamoy  路  3Comments

jedie picture jedie  路  3Comments

darkclouder picture darkclouder  路  3Comments