Ronald: that depends somewhat on how the installation is handled. For example, for entrypoints-style scripts, the entirety of __main__ is auto-generated anyway, and anyone using "./setup.py develop" or "pip install -e ." to add a suitable sys.path entry during development will still be able to do "import helper" regardless of what happens to sys.path by default.

However, Guido has stated he doesn't like the idea of requiring beginners to learn the "from . import helper" construct, so I think that's enough to kill that particular proposed solution to the problem described in my opening message.

Another solution proposed on python-ideas was to move the script directory to the *end* of sys.path rather than having it at the beginning, but the problem with that is that it not only cripples our ability to add new modules to the standard library, but it also greatly increases the odds of additions to site-packages by redistributors breaking end user scripts. As things currently stand, the name shadowing caused by such additions only needs to be resolved by projects that actually want to access the standard library or redistributor provided module. By contrast, if the script directory were added at the end of sys.path, then those scripts would outright break as they'd start getting the newly added module rather than the peer module they were expecting.

Eliminating both of those more general approaches pretty much leaves us with the one more narrowly focused option: when an import candidate matches `__main__.__spec__.origin`, we start ignoring it with a silent-by-default ImportWarning and move on. To avoid breaking imports when using the -m switch we'd likely need to accept PEP 499 as well, but I was generally inclined to do that anyway (I just hadn't gotten around to offering to be BDFL-Delegate for that PEP as the runpy module maintainer yet)