builtins.__import__() raises ValueError (as it did in Python 2.7) while importlib.__import__() raises ImportError (which makes more sense to me).

Found by Ben Lewis.

Importllib code raising the exception is https://github.com/python/cpython/blob/f9f8e3ce709ceb15c8db8c8dde940daf1febf13d/Lib/importlib/_bootstrap.py#L874-L876 .

I think this should be an ImportError and so that means builtins.__import__() is wrong. Anyone want to argue for the other side?

import.c code raising the exception: https://github.com/python/cpython/blob/f9f8e3ce709ceb15c8db8c8dde940daf1febf13d/Python/import.c#L1675-L1677

ImportError sounds right to me.

We already raise that just above this for the "no dots at all" case, so also raising it for the "not enough dots" case makes more sense than leaving them different.

> I think this should be an ImportError 

I also think ImportError is what people would expect when an import fails.

New changeset c5fa44944ee0a31a12b9a70776c7cb56c4dc39a2 by Miss Islington (bot) (Ngalim Siregar) in branch 'master':
bpo-37444: Update differing exception between builtins and importlib (GH-14869)
https://github.com/python/cpython/commit/c5fa44944ee0a31a12b9a70776c7cb56c4dc39a2

While raising ImportError certainly makes much more sense in this case, this change is backwards incompatible and there was no DeprecationWarning. I don't consider that fair.

As a certain compromise, we could maybe raise a custom ImportError+ValueError offspring (e.g. BeyondToplevelImportError)?

If feeling fancy, we could rise a DeprecationWarning when issublcass(BeyondToplevelImportError, ValueError) is used?

There's no deprecation warning because how do you warn about that? You raise DeprecationWarning about an exception you have yet to raise?

And I personally think calling this unfair is a bit harsh.

I know that raising a DeprecationWarning here is most likely not possible or too black-magical to do. My intention was not to be harsh, sorry about that. I just wanted to point out that a backwards incompatible behavior like this without a (possible) deprecation warning might not counterweigh the gain of raising the logical exception type. As a compromise, I proposed to raise a hybrid that inherits from both.

The problem with the hybrid exception is that importlib would then still raise a different exception from import itself, so the discrepancy would persist. And if you updated import you could then break people in another way where they were catching ValueError and ImportError separately for different cases and now they would potentially catch the wrong exception for that ValueError case.

Basically changing what exceptions get raised sucks as someone is almost inevitably broken. But since import and importlib strive to mirror each other as much as possible and be drop-in replacements, the consistency for the next 30 years of Python's life is more important I think than the case of:

1. Someone using importlib.import_module()
2. Who is specifically worried about relative imports going too far and no other import-related import and thus only catching ValueError and not ImportError
3. And are supporting older versions of Python
4. And will have a difficult time updating their `except` clause to now also capture ImportError

For the record, looking at https://docs.python.org/3.9/whatsnew/3.9.html I had an impression that this also affects regular imports, as described in https://bugzilla.redhat.com/show_bug.cgi?id=1791769#c2 -- if that's not that case, I'm sorry.

Anyway, I get your point of "next 30 years of Python".

Sorry, you're right; I forgot importlib got it "right" while import got it "wrong". :)