A colleague just ran into the issue where they created a "json.py" module in their local directory and broke a previously working program. I picked up on the mistake when I saw the following traceback snippet:

    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/usr/lib/python2.7/site-packages/praw/__init__.py", line 27, in <module>
        import json
      File "json.py", line 1, in <module>
        r = requests.get("http://www.reddit.com/user/spilcm/about/.json")

However, actually making the connection required thinking "Wait, why is the stdlib JSON module calling out to Reddit?" followed immediately by "Oh, that's not the stdlib json module".

That connection would potentially be easier for new Python users to make if there was an inline notification printed after the traceback warning of the stdlib module shadowing. If nothing else, it would give them something specific to search for to lead them to a discussion of name shadowing and the problems that can arise when you name one of your local modules the same as a standard library module.

Offering such a feature would necessarily rely on having a standard way of getting a programmatic list of the standard library modules available to the running interpreter version without actually loading them all, a question which is discussed further in https://stackoverflow.com/questions/6463918/how-can-i-get-a-list-of-all-the-python-standard-library-modules and https://github.com/jackmaney/python-stdlib-list

Since the contents of the standard library for a given release is immutable, and we'd like to keep any such mechanism (if we decide to provide it) very simple so we can easily access it from the low level interpreter traceback machinery, my suggestion would be along the lines of:

1. Update the interpreter build process to emit a flat text file containing a complete list of fully qualified stdlib module names (including submodules), one name per line (this will be generated at build time, so it *won't* contain filenames, just the module names - however, it could theoretically be combined with importlib.util.find_spec to generate a PEP 376 style RECORD file for the non-builtin parts of the standard library at installation time)
2. Rather than exposing the underlying machinery to end users directly, instead expose a function in sysconfig to read that list of modules into memory via a read-only line based iterator. (There may be an internal API to allow access to the content without going through sysconfig)
3. Updating the two main traceback display mechanisms (the builtin traceback display and the traceback module) to check that list for potential conflicts after displaying a traceback

(This idea could benefit from discussion on python-ideas and potentially even escalate into a full PEP, but I don't currently have the personal bandwidth available to pursue that course. Accordingly, I'm just filing the idea here in case someone else finds it intriguing and has more time available to pursue it)