On Fri, Aug 21, 2020, at 21:52, Steven D'Aprano wrote:
Having said all that, I cannot help but feel that shadowing of modules is such an issue that maybe we need to make a special case of this. Not specifically tkinter, of course, but if a module attempts to directly import a module with the same name, and that import fails for any reason, we should include a message about shadowing in addition to the normal exception traceback.
I don't think a majority of these cases result in the error happening during the import rather than at a subsequent attribute access.
I think there are two possible paths here: either 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, or check for that situation whenever a module attribute access fails, to add more information to the error message at that point.
I do think circular imports are a bit of a red herring - it's often the case, but not always. I've seen this happen as a result of a chaotic project directory whereby one script they'd written - which didn't itself depend on the named system module - shadowed a module that was imported from a different program.
I think the following would be an option: "ImportError: partially initialized module 'tkinter' can't import itself"
That's a regression. In this specific case it doesn't matter because you know that the error actually is shadowing (the user named their own file "tkinter.py") but in the general case we lose the information of what name was being looked up:
AttributeError: partially initialized module 'spam' has no attribute 'egsg' (most likely due to a circular import)
If the error wasn't due to shadowing or a circular import, then knowing that I had misspelled 'eggs' would be very useful.
hmm
what about
AttributeError: module 'spam' from './spam.py' has no attribute