I hope that his hasn’t been discussed to death in the past but I quite often encounter cases where developers have unwittingly created a file or directory that has a name clash with either a system import or a pip installed library import. This can be very confusing to new users! And, of course, as the number of core libraries and the installable ecosystem grow this potential problem is growing all of the time.

One issue I didn’t think of at first: Sometimes you deliberately create a module with the same name as a stdlib module _deliberately_. And we want to be careful not to gratuitously break any legit uses of that.

Usually, packages that exist in Python 3.x but are on PyPI for 3.(x-1) and earlier have different names (statistics vs. stats, enum34 vs. enum, etc.), so the user code has to explicitly try one and except import the fallback. But when the fallback is inside your own application, sometimes you just use be same name and inject it into the sys.path if needed. I don’t think the most obvious ways of solving or problem would break things (and if brand-new code starts using try from std import except from local import instead of screwing with sys.path, that’s not a problem, it’s a good thing). But it’s something to keep in mind.