In the past few months, there has been an increase "IDLE fails to start" reports that are apparently due to shadowing of stdlib modules by user modules in the same directly as as user code.  For instance, a beginner creates turtle.py and then writes "import turtle" in the same file or another in the same directory.

Note that only Python-coded modules can be shadowed. Imports of builtin modules that are not accelerators for a .py module are handled internally and do not involve sys.path.  (If turtle were builtin, turtle.py would not interfere with 'import turtle.) In particular, sys is builtin and 'import sys' is guaranteed to work and give access to sys.path.

CPython avoids shadowing of the stdlib in its own imports.  Perhaps it does not add '', standing for the current working directory, to the front of sys.path until after its imports are done.  A self-contained application can avoid the problem by properly naming its own modules.  An application like IDLE that runs user code needs to protect itself from user files.  It does not now.

IDLE normally runs with two processes. I believe shadowing is more a problem for the user process that executes user code, with the working directory set to that of the user code.  (I believe that this is one reason why user code must be saved, to a particular directory, before it is run.)  Since, with one exception, all imports in run.py are done before running user code, I believe a sufficient fix would be temporarily delete '' while run.py does its own imports.

By default, the IDLE gui process should not have a problem.  The working directory is that of python.exe, which initially has no conflicting files.  To guard against user additions, '' could be permanently removed.  However, for option -n single-process mode, it would have to be restored (a reason for wanting to remove that mode).  I am not sure of the effect of all the other options.  At present, I believe, all imports are done at startup.  So the same idea used for the user process might work, at least for the present.

Automated tests would be nice.  I might want to some day 
limit initial imports to the minimum needed to show the initial window (or windows), so IDLE might start faster.  But they are not trivial.  And there is the time factor. A single cold start of IDLE takes as long (about 4 seconds on my machine) as the average test file in the test suite.