add ModuleNotFoundError

[ericsnowcurrently]

BPO	15767
Nosy	@gvanrossum, @warsaw, @brettcannon, @theller, @jcea, @pitrou, @ned-deily, @ezio-melotti, @asvetlov, @cjerdonek, @ericsnowcurrently, @serhiy-storchaka, @gvanrossum
Dependencies	bpo-18200: Update stdlib to use ModuleNotFoundError

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/ericsnowcurrently'
closed_at = <Date 2016-09-07.23:58:40.759>
created_at = <Date 2012-08-22.19:45:17.750>
labels = ['interpreter-core', 'type-feature']
title = 'add ModuleNotFoundError'
updated_at = <Date 2018-02-27.13:48:13.030>
user = 'https://github.com/ericsnowcurrently'

bugs.python.org fields:

activity = <Date 2018-02-27.13:48:13.030>
actor = 'cwg'
assignee = 'eric.snow'
closed = True
closed_date = <Date 2016-09-07.23:58:40.759>
closer = 'eric.snow'
components = ['Interpreter Core']
creation = <Date 2012-08-22.19:45:17.750>
creator = 'eric.snow'
dependencies = ['18200']
files = []
hgrepos = []
issue_num = 15767
keywords = []
message_count = 64.0
messages = ['168906', '175638', '175650', '175651', '175659', '175660', '175674', '175699', '175703', '181901', '181914', '181919', '181926', '182260', '182263', '182271', '182322', '182332', '182339', '182385', '182396', '182401', '182404', '182409', '182411', '182414', '182415', '182437', '182455', '182459', '182466', '191046', '191054', '191055', '192095', '192139', '192142', '192143', '192161', '192172', '192176', '192189', '192199', '192200', '192201', '192202', '192207', '192209', '192261', '192263', '192318', '219127', '274866', '274921', '312930', '312940', '312949', '312965', '312969', '312971', '312996', '313004', '313006', '313008']
nosy_count = 17.0
nosy_names = ['gvanrossum', 'barry', 'brett.cannon', 'theller', 'jcea', 'pitrou', 'ned.deily', 'ezio.melotti', 'Arfrever', 'cvrebert', 'asvetlov', 'chris.jerdonek', 'python-dev', 'eric.snow', 'serhiy.storchaka', 'Guido.van.Rossum', 'cwg']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue15767'
versions = ['Python 3.6']

[ericsnowcurrently]

In bpo-15316 (msg168896, Brett Cannon):

Create a ModuleNotFoundError exception that subclasses ImportError
and catch that (breaks doctests and introduces a new exception that
people will need to be aware of, plus the question of whether it
should just exist in importlib or be a builtin)

While it's too late to go into 3.3, this is a reasonable addition for 3.4. Perhaps other ImportError subclasses are warranted, but they can be addressed separately.

[brettcannon]

Should it be ModuleNotFoundError or ModuleNotFound? It's not necessarily an error if a module doesn't exist, so failing to find it isn't quite that negative. It also acts somewhat like StopIteration/GeneratorExit which also don't have the common "Error" suffix of exception names.

[cjerdonek]

Since it subclasses ImportError, it seems like we're already considering it to be an error? StopIteration and GeneratorExit don't inherit from an "Error" exception type unlike, say, the OSError exception types.

[cjerdonek]

I meant to include this link for convenience:

http://docs.python.org/dev/library/exceptions.html#exception-hierarchy

[ericsnowcurrently]

I'd say ModuleNotFoundError. You could argue that other exception types aren't really errors in certain circumstances. I'd think that generally this would be an error.

[ericsnowcurrently]

Effectively the exception indicates that the import system had an error.

[ezio-melotti]

I prefer ModuleNotFound. Its meaning is already clear enough, even without the Error suffix.
OTOH we now have FileNotFoundError, but all the other OSError subclasses have that suffix.
In general I think the suffix is necessary when it's not already clear from the name that we are dealing with an exception, otherwise it can be dropped.

[cjerdonek]

To state more explicitly the observation I alluded to in my comment above, we currently follow (without exception -- pun intended :) ) the convention that subclasses of exceptions that end in "Error" also end in "Error". We also do the same with the suffix "Warning".

The latter is another reason to include the suffix "Error" -- to eliminate ambiguity as to whether the exception type inherits from a Warning class (e.g. from ImportWarning).

[ezio-melotti]

That seems indeed to be the case with built-in exceptions. I'm not sure if it's intentional or just a coincidence. I agree that warnings should always have a "Warning" suffix to distinguish them from exceptions, but in the stdlib the "Error" suffix is not used consistently. There are exceptions like: FloatOperation, DivisionByZero, InvalidOperation, TimeoutExpired, BrokenProcessPool, BufferTooShort, ImproperConnectionState, UnknownProtocol, InvalidURL, etc..
Anyway I don't have a strong opinion about this, so if you think the name should be ModuleNotFoundError it's OK with me (i.e. I'm -0).

[warsaw]

For me, it mostly comes down to whether end-users are expected to see such errors generally or not. We see ImportErrors all the time, and they are clearly errors. If we're expected to see and deal with MNF, and if in such cases it's generally considered an error, then MNFError is better. If it's mostly an internal/hidden thing, then MNF doesn't bother me.

[brettcannon]

Right, so what's typical? =) I mean do most people see ImportError for optional modules (e.g. not on support platforms), or do most people see ImportError because they messed up and tried to import something that they expected but actually isn't there for some reason.

[warsaw]

On Feb 11, 2013, at 05:31 PM, Brett Cannon wrote:

Right, so what's typical? =) I mean do most people see ImportError for
optional modules (e.g. not on support platforms), or do most people see
ImportError because they messed up and tried to import something that they
expected but actually isn't there for some reason.

There are a few common use cases (or perhaps anti-use cases) where you see
ImportErrors. I might be missing some, but I'd put these in roughly
descending order of commonness.

• Trying alternative imports for compatibility reasons. You always expect
  ImportErrors in these cases, and you'll always catch them in try/excepts.

• Missing modules, submodules, or attributes in from-imports. These can be
  unexpected if you think you've got the right version of a package, or
  expected for compatibility reasons.

• Trying to conditionally import optional modules. Again, expected, and
  they'll be wrapped in try/except.

I guess the case you're trying to differentiate with MNF is, the from-import
case, i.e. did the error occur because the module was missing or because the
attribute was missing?

It's hard to say which is more likely, which I guess is why you're having a
hard time deciding. :) If I had to vote, I'd go with MNFError 1) because it's
a subclass of ImportError; 2) it'll be more informative in the case where it
really *is* an error; 3) isn't that big of a deal in cases where it's
expected; 4) we're used to seeing ImportError anyway, and probably most code
won't care and will just use ImportError.

[brettcannon]

Screw it, I'll go with ModuleNotFoundError since it is a subclass of ImportError and so it might come off as weird as saying the superclass is an "Error" but the subclass is not.