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!
Sent from Mail for Windows 10
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
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 -- email@example.com
To unsubscribe send an email to firstname.lastname@example.org
Message archived at https://email@example.com/message/MQ3BEVNME5KXW4GFGI6K7JWTJCS3Y37P/
Code of Conduct: http://python.org/psf/codeofconduct/