This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eric.snow
Recipients Arfrever, Guido.van.Rossum, asvetlov, barry, brett.cannon, chris.jerdonek, cvrebert, eric.snow, ezio.melotti, gvanrossum, pitrou, python-dev, serhiy.storchaka, theller
Date 2013-07-04.00:44:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> I'm sorry, but this seems like it should be an importlib internal
> affair.  The new exception is too much in everyone's face, because
> the exception name gets printed on every traceback.

That's the crux of the issue.  If there isn't much utility outside importlib to distinguishing between module-not-found and other causes of ImportError, then there isn't much point to a new exception.  It just boils down to what the other potential causes of ImportError are and how much people care about them.

I keep thinking about PEP 3151 (IOError/OSError hierarchy rework) and the lessons we've learned about exception attributes vs. subclasses.  For readability and write-ability, I'd rather write this:

      from _collections import OrderedDict
  except ModuleNotFoundError:

than this:

      from _collections import OrderedDict
  except ImportError as e:
      if e.reason is not importlib.machinery.ImportReason.MODULE_NOT_FOUND:

But the relevant question is, what is the benefit (outside importlib) of either over this:

      from _collections import OrderedDict
  except ImportError:
Date User Action Args
2013-07-04 00:44:56eric.snowsetrecipients: + eric.snow, gvanrossum, barry, brett.cannon, theller, pitrou, ezio.melotti, Arfrever, cvrebert, asvetlov, chris.jerdonek, python-dev, serhiy.storchaka, Guido.van.Rossum
2013-07-04 00:44:56eric.snowsetmessageid: <>
2013-07-04 00:44:56eric.snowlinkissue15767 messages
2013-07-04 00:44:55eric.snowcreate