Couldn’t the whole issue potentially be avoided with some meta-modules, e.g.:


from STDLIB import sys

from STDLIB.os import path

from LIBS import pandas as pd

from LOCALS import path # This  should cause an error

from LOCALS import path as mypath # this not


This would leave the current import syntax unchanged but allow users to clarify where they are expecting to import from. There is an underused mechanism for doing the same in C/C++ where #include <something.h> will always be from the system includes but #include “something.h” will not (if your compile includes have a blank path to distinguish).


Might be worth some thinking!


Steve Barnes


Sent from Mail for Windows 10


From: Gustav O
Sent: 22 August 2020 10:41
Subject: [Python-ideas] Re: Improve error message for trying to import itself


I think you have some really valid points in your answer, Steven. To me, it seems like we have two main options to improve the message for shadowing modules. I copied part of your and Random832’s answer here, since they summarize it quite nicely:

1. If a module attempts to directly import a module with the same name, and that import fails for any reason, we include a message about shadowing in addition to the normal exception traceback.

2. Always print a warning [not an error]
when importing a module from the current directory [the first entry in sys.path] that is
also available in any other entry in sys.path

I think both methods would add significant information. The second option would help a lot in the cases where the program still works, but doesn’t throw an error (possibly because the accessed objects exist in both modules).

Either way, giving a hint that a module might be shadowed by the running program would help significantly.

Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct: