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 barry
Recipients barry
Date 2017-02-13.16:30:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I haven't really thought about this deeply but I've observed that there are lots of cases where a user will report getting an ImportError trying to import a name from a module, where it turns out that the problem is that the module is coming from an unexpected location.  Examples include pip installed packages overriding system packages, or unexpected vendorized wheels.

The standard first response is typically, "can you please run this to tell us where the foo library is coming from?"  E.g.

^^ this is indicative of an old version of urllib3. Can you please double 
check whether you have an old urllib3 installed e.g. in /usr/local or ~/.


$ python3 -c 'import urllib3; print(urllib3.__file__)'

should return:


and might tell you where else a locally installed urllib3 is to be found if it 
doesn't return that value.

It would be kind of useful if the original ImportError showed you where the module came from (i.e. its __file__), if such information can be discerned.  E.g.:

>>> import requests; requests.__version__.split('.')  
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/usr/lib/python2.7/dist-packages/requests/", line 
61, in <module>
     from .packages.urllib3.exceptions import DependencyWarning
ImportError: cannot import name DependencyWarning from requests.packages.urllib3.exceptions (/usr/local/lib/python3.5/site-packages/requests/packages/

If you saw that in a bug report, you'd almost immediately know that the user has some local override that's potentially causing the problem.
Date User Action Args
2017-02-13 16:30:11barrysetrecipients: + barry
2017-02-13 16:30:11barrysetmessageid: <>
2017-02-13 16:30:11barrylinkissue29546 messages
2017-02-13 16:30:10barrycreate