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 <1372898696.46.0.320373589634.issue15767@psf.upfronthosting.co.za>
In-reply-to
Content
> 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:

  try:
      from _collections import OrderedDict
  except ModuleNotFoundError:
      pass

than this:

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

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

  try:
      from _collections import OrderedDict
  except ImportError:
      pass
History
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: <1372898696.46.0.320373589634.issue15767@psf.upfronthosting.co.za>
2013-07-04 00:44:56eric.snowlinkissue15767 messages
2013-07-04 00:44:55eric.snowcreate