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 brett.cannon
Recipients Arfrever, asvetlov, barry, brett.cannon, chris.jerdonek, cvrebert, eric.snow, ezio.melotti, gvanrossum, pitrou, python-dev, serhiy.storchaka
Date 2013-07-01.16:54:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Obviously no worries for opening this up again; if something isn't clear better to get it sorted out now rather than after 3.4 is out that door.

So I see two questions: why isn't ImportError being raised in the ``import re.bogus`` case and why the subtle difference in exception messages.

Let's deal with the latter first since it's the easiest: it's because that's how it was in Python 3.3::

> python3.3                                                                                  ~
Python 3.3.2 (default, Jun 19 2013, 13:30:51) 
[GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import bogus
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named 'bogus'

>>> from re import bogus
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name bogus

>>> import re.bogus
Traceback (most recent call last):
  File "<frozen importlib._bootstrap>", line 1521, in _find_and_load_unlocked
AttributeError: 'module' object has no attribute '__path__'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named 're.bogus'; re is not a package

All I did for ModuleNotFoundError is change what exception is raised. I didn't muck with any messages in adding this exception to keep the change minimal (at least to start with). It also doesn't help that in your case [2] (the ``from re import bogus`` case) is actually not handled by importlib but ceval.c. I really hate the semantics of ``from ... import`` and __import__ in this specific instance. Hopefully it can be something I can clean up in Python 4. Anyway, it can be updated to match:

As for the ``import re.bogus`` case not raising ModuleNotFoundError, I'm fine with changing it. I don't have a clear recollection as to why I chose to leave it as-is, but I also can't come up with a good reason to not change it.

And to explain why the ``from ... import`` case raises ModuleNotFoundError even when re is a module and obviously not a package is that while that might be true now, that does not necessarily hold in the future. If you have been using something like an object to hold attributes but then decide to switch to a module, this instance would break. Plus ``from ... import`` has never directly distinguished between a missing attribute and a missing module. Once again, something I would like to change in Python 4.
Date User Action Args
2013-07-01 16:54:57brett.cannonsetrecipients: + brett.cannon, gvanrossum, barry, pitrou, ezio.melotti, Arfrever, cvrebert, asvetlov, chris.jerdonek, python-dev, eric.snow, serhiy.storchaka
2013-07-01 16:54:57brett.cannonsetmessageid: <>
2013-07-01 16:54:57brett.cannonlinkissue15767 messages
2013-07-01 16:54:56brett.cannoncreate