Use case:

Alexanders-MacBook-Pro:pypy alex_gaynor$ python3.3
Python 3.3.2 (default, May 29 2013, 14:03:57)
[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 datetime.datetime
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 'datetime.datetime'; datetime is not a package
>>>



Showing the user the original "module has no attribute __path__" error is just confusing, we should hide it.

Fix is simple:

--- a/Lib/importlib/_bootstrap.py
+++ b/Lib/importlib/_bootstrap.py
@@ -1519,7 +1519,7 @@ def _find_and_load_unlocked(name, import
             path = parent_module.__path__
         except AttributeError:
             msg = (_ERR_MSG + '; {} is not a package').format(name, parent)
-            raise ImportError(msg, name=name)
+            raise ImportError(msg, name=name) from None

Manual testing confirms the fix.  Is a unit test needed?  Should this wait for 3.5?

> --- a/Lib/importlib/_bootstrap.py
> +++ b/Lib/importlib/_bootstrap.py

Eric, please attach the patch as a file to the issue, so it can be easily reviewed on Rietveld.

I figured it would take less time for someone to go to the file and make the edit than download and apply a patch file, but as you wish :)

"I figured it would take less time for someone to go to the file and make the edit than download and apply a patch file, but as you wish :)"

It's not to apply the patch, but to review it. The Rietveld tool helps to review a patch online, it displays more context (lines before/after) ;-)

Is it confusing though? If you only had the latter exception all you would know is Python doesn't consider datetime a package but you wouldn't know why that is unless you knew the exact definition (the __path__ attribute exists). Having the former exception helps make that a bit more obvious if you didn't already know it.

> If you only had the latter exception all you would know is Python
> doesn't consider datetime a package but you wouldn't know why that is
Well, I’d be satisfied with that.  Looking at the doc or importing just datetime would let me know it’s a module, not a package.

> unless you knew the exact definition (the __path__ attribute exists).
To me that’s an implementation detail.  The real definition in my mental model is that modules are files and packages are directories.  __path__ is advanced stuff.

That's only true if you are dealing with files and directories though.  The import system can deal with much more than that, in which case the absence __path__ could be an important bit of debugging information.

Actually, it could be important even if you are dealing with files and directories (or I'm confused and __path__ is always about same :), since you could be dealing with an alternate loader.

Our policy is not to hide the chained traceback unless *all* of the information in the chain has been expressed in the replacement traceback error message.

That makes a lot of sense.  I guess this is Brett’s call.

> If you only had the latter exception all you would know is Python
> doesn't consider datetime a package but you wouldn't know why that is 
> unless you knew the exact definition (the __path__ attribute exists). 
> Having the former exception helps make that a bit more obvious if you 
> didn't already know it.

I don't think someone who doesn't know about __path__ would be very enlightened by the error message. Also, I don't think error messages have a role in teaching about the implementation details of features, so I'd vote for removing the __context__ here.

Antoine: down that path lies Microsoft's "An error has occurred" error messages.  The point of the extra information is not to inform the end user, it is to make it possible for an expert to solve the problem, and for it to be findable in a web search.

Now, whether or not there are enough different things that the second error could be chained off of to make that worthwhile in this case is something Brett or Eric will have to answer.  My guess is that there *potentially* are, even though this one is the most common, but that's just a guess since I haven't studied importlib.

> Antoine: down that path lies Microsoft's "An error has occurred" error
> messages.  The point of the extra information is not to inform the end
> user, it is to make it possible for an expert to solve the problem,
> and for it to be findable in a web search.

I don't know how that's related. Here the error is trying to import from
a package while the module isn't a package. The solution is either to
change the import to something else, or to turn the non-package into a
package. None of these involve doing anything explicitly with __path__,
so the original error is a distraction.

I'm going to make a call and say the chained exception should stay. If people want to start the discussion again they can.