In issue 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.

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.

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.

I meant to include this link for convenience:

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

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.

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

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.

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).

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).

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.

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.

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.

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.

+1 on just getting it done with ModuleNotFoundError.  FWIW, I'd be glad to do it.  I'm taking a self-imposed break from the nearly finished C-OrderedDict!

from foo import bar

Here bar can be not module, but an attribute of foo (for example, os.path). What error will be raised in this case? Module or attribute - this is an implementation detail; why do we distinguish between these cases?

Eric: knock yourself out. =)

Serhiy: What exception is raised in that situation is controlled by the eval loop, not importlib so that would be a separate change. But regardless, there is no way to infer whether you expected an attribute or module to be there, just that you were after something that didn't exist. But I would argue most people import at the module level and not the attribute level, and so raising an ModuleNotFoundError would be acceptable.

I've lost track of why this new exception was needed. Could someone provide a summary? Thanks :-)

TL;DR for Antoine: when using a fromlist, import failures from that list are silently ignored. Because ImportError is overloaded in terms of what it means (e.g. bag magic number, module not found) there needs to be a clean way to tell the import failed because the module wasn't found so other ImportError reasons can properly propagate.

>> from foo import bar
>> Here bar can be not module, but an attribute of foo (for example, os.path).
> Serhiy: What exception is raised in that situation is controlled by the eval loop, not importlib so that would be a separate change.

Just to clarify from this exchange, is there a chance we will use this same exception type (perhaps in a later change) in cases where bar is not found?  If so, I think it's worth considering something like "NotFoundImportError" or "ImportNotFoundError" that doesn't single out module.  Importing classes, etc. is quite a common pattern (e.g. examples appear in PEP 8).

The original need was for internal importlib usage, but upon reflection it could also be used by the eval loop for that (http://hg.python.org/cpython/file/83d70dd58fef/Python/ceval.c#l4560), so I'm fine with changing the name to ImportNotFoundError.

> The original need was for internal importlib usage, but upon
> reflection it could also be used by the eval loop for that
> (http://hg.python.org/cpython/file/83d70dd58fef/Python/ceval.c#l4560),
> so I'm fine with changing the name to ImportNotFoundError.

I don't understand what ImportNotFoundError means: an import was
not found? ModuleNotFoundError was obvious.

Technically it should be ModuleOrSomeObjectNotFoundBecauseFromListIsTheBaneOfMyExistenceError, but we might be starting to mix paints for paints a shed shortly.

Fine, that's 1 to 1 for ModuleNotFoundError vs. ImportNotFoundError.

If we can promise not to use it in the from-import case :) I'm okay with the more specific name (in fact it is preferable).  From Brett's response, it sounds like we have flexibility there and don't need it to be the same?  For from-import I would prefer the generic ImportError or adding a new type between ImportError and ModuleNotFoundError (like ImportNotFoundError) over using a name that is not entirely correct.

Can this be the same ImportError but with special flag?

On Feb 19, 2013, at 07:24 PM, Serhiy Storchaka wrote:

>Can this be the same ImportError but with special flag?

Like an attribute on the exception?  +1

> >Can this be the same ImportError but with special flag?
> 
> Like an attribute on the exception?  +1

ImportError.has_different_meaning_but_too_lazy_to_create_a_distinct_exception_class_for_it ?

(or perhaps you would prefer the camelCase version :-))

Chris: Having a more generic name for import-from at the eval loop level on top of NoModuleFoundError is breaking the "practicality over purity" rule. ImportSearchFailed might be the closest we can come to a generic name for what occurred.

Serihy & Barry: no. We do that now and it's already a nasty little hack. It would be better to let people catch an exception signaling that an import didn't happen because some module is missing than require introspection on a caught ImportError to tell what is going on (there's a reason why Antoine went to all of that trouble to add new exceptions so we don't have to look at the errno attribute on OSError). Exceptions are structured to work off of inheritance hierarchies (says the man who co-wrote the PEP to make all PEPs inherit from BaseException).

On Feb 19, 2013, at 07:49 PM, Brett Cannon wrote:

>Serihy & Barry: no. We do that now and it's already a nasty little hack. It
>would be better to let people catch an exception signaling that an import
>didn't happen because some module is missing than require introspection on a
>caught ImportError to tell what is going on (there's a reason why Antoine
>went to all of that trouble to add new exceptions so we don't have to look at
>the errno attribute on OSError). Exceptions are structured to work off of
>inheritance hierarchies (says the man who co-wrote the PEP to make all PEPs
>inherit from BaseException).

The difference being that checking errno on OSError/IOError is essentially
required to do anything useful with it, while this one seems like a rare
corner case (we've been doing pretty well without it so far).

The common case for catching ImportError is exactly what ModuleNotFoundError represents.  If people are already going to change their code to handle just this special case, I'd think having the subclass would be the better route.  I find it simpler (both to update existing code and to read:

    try:
        from _thread import _local as local
    except ModuleNotFoundError:
        from _threading_local import local

vs.

    try:
        from _thread import _local as local
    except ImportError as e:
        if e.not_found:
            from _threading_local import local
        else:
            raise

And for the broader case:

    try:
        import breakfast
    except ModuleNotFoundError:
        class breakfast:
            spam = 0
            eggs = 1
            ham = 2
    except ImportError as e:
        log_some_message("uh oh: {}".format(e))
        raise

vs.

    try:
        import breakfast
    except ImportError as e:
        if e.not_found:
            class breakfast:
                spam = 0
                eggs = 1
                ham = 2
        else:
            log_some_message("uh oh: {}".format(e))
            raise

Why not just

    try:
        from _thread import _local as local
    except ImportError:
        from _threading_local import local

?

Right.  Sorry I wasn't more clear.  Existing code will continue to work either way.  The point is in exposing the distinct module/name-not-found case, which I consider to be the common case for catching ImportError.  My examples cover the case where you want to handle the module-not-found case specifically.