(Adding the other import system maintainers to the nosy list, along with Ned as the release manager for 3.6 and 3.7)

Summarizing my current thoughts on this:

I think the fact that "-m" currently adds the empty directory as sys.path[0] instead of the fully resolved cwd is definitely worth changing for 3.8, and is at least arguably a bugfix that should be applied to 3.7 prior to release. (It's probably too late in 3.6's lifecycle to be worth backporting that far, even if we do reclassify this part as a bugfix instead of an enhancement)

The above is what I consider to be in scope for *this* particular issue.

(The details of the current behaviour probably arose from my borrowing an existing code path originally designed for "-c" rather than from a deliberate design decision)



As a separate question, I'd personally be open to the idea of:

1. Deprecating the implicit addition of the current working directory to sys.path (and have that emit a deprecation warning in 3.8)

2. Add support for an explicit leading dot on "-m" arguments to say "Run this from the current directory" (the -m switch was added in 2.4, while the explicit relative import syntax wasn't chosen until 2.5, so this wasn't an available option for the original feature design). Note: given implicit namespace packages, it may make sense to allow additional leading dots in order to add a parent directory to sys.path instead of the current directory.

3. Add a "--basepath <dir>" argument to have "-m" resolve explicit relative imports against a directory other than the current one (this would be a different potential spelling for https://bugs.python.org/issue13475 )

4. Once the current directory is no longer added implicitly (in 3.9 at the earliest), if runpy fails to find the main module, then check the current directory and ask "Did you mean '.name'?" in the error message.

However, that second part is the part I consider out of scope for this issue, and think would require a PEP due to the backwards compatibility challenges.