[issue31874] [feature] runpy.run_module should mimic script launch behavior for sys.path

Nick Coghlan added the comment: Good point regarding the heuristic: it would need to take the requested module name into account to be correct. * check if the requested module was found relative to the current directory (can be worked out from __main__.__spec__ and the current working

[issue31874] [feature] runpy.run_module should mimic script launch behavior for sys.path

Jason R. Coombs added the comment: In [setuptools 1453](https://github.com/pypa/setuptools/issues/1453), this issue hit the project hard. Tox 3.2 changed the default invocation of pip from the script-based invocation to the runpy based implementation (python -m pip), which causes pip to be

[issue31874] [feature] runpy.run_module should mimic script launch behavior for sys.path

Change by Jason R. Coombs : -- components: +Library (Lib) ___ Python tracker ___ ___

[issue31874] [feature] runpy.run_module should mimic script launch behavior for sys.path

Change by Jason R. Coombs : -- type: -> enhancement ___ Python tracker ___ ___

[issue31874] [feature] runpy.run_module should mimic script launch behavior for sys.path

Jason R. Coombs added the comment: At first, I didn't understand why one wouldn't simply omit sys.path[0], similar to what scripts do, but then I realized that Nick was aware of a common use-case that I was overlooking - that `python -m` may be used to launch behavior in a

[issue31874] [feature] runpy.run_module should mimic script launch behavior for sys.path

New submission from Jason R. Coombs : In [this comment](https://bugs.python.org/issue16737#msg282872) I describe an issue whereby launching an application via runpy.run_module (aka python -m) produces different and unexpected behavior than running the same app via an entry