This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jaraco
Recipients Arfrever, brett.cannon, eric.araujo, eric.snow, jaraco, ncoghlan, serhiy.storchaka, vinay.sajip
Date 2017-10-20.16:07:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1508515679.21.0.213398074469.issue16737@psf.upfronthosting.co.za>
In-reply-to
Content
> All of the differences in semantics make total sense when you realize `-m pkg` is really conceptually shorthand for `import pkg.__main__` (w/ the appropriate __name__ flourishes).
> So instead of selling `-m` as a way to run a module/package as a script, I say we change the message/documentation to say it does an import with __name__ changed and make specifying a script as the weird reading-a-file-directly thing.

I agree the explanation makes sense. But is that the design we want?

In my opinion, the most meaningful purpose of `-m` is its ability to run a module/package as a script. I've rarely seen it used as a convenience for executing a Python file, but I've seen it used extensively for providing entry to the canonical behavior for a library:

- pip: python -m pip
- pytest: python -m pytest
- setuptools: python -m easy_install
- virtualenv: python -m virtualenv

[rwt](https://pypi.org/project/rwt) takes advantage of this mechanism as the primary way to invoke a module (because scripts don't provide an API at the Python interpreter level):

    $ rwt -q paver -- -m paver --version
    Paver 1.2.4 

I began using this functionality extensively when on Windows using pylauncher, as it was the only reliable mechanism to invoke behavior with a desired Python interpreter:

    PS> py -3.3 -m pip

If the semantics of -m are by design and need to be retained, it seems to me there's a strong argument for a new parameter, one which works much as -m, but which has the semantics of launching a script (as much as possible). Consider "python -r module" (for Run). Alternatively, Python could distribute a new runner executable whose purpose is specifically for running modules. Consider "pyrun module".

I don't think it will be sufficient to simply add a --nopath0 option, as that would impose that usage on the user... and `python -m modulename` is just at the limit of what syntax I think I can reasonably expect my users to bear for launching a script.

My preference would be to alter the semantics of `-m` with the explicit intention to align it with script launch behavior, or to provide a new concise mechanism for achieving this goal.

Thoughts?
History
Date User Action Args
2017-10-20 16:07:59jaracosetrecipients: + jaraco, brett.cannon, vinay.sajip, ncoghlan, eric.araujo, Arfrever, eric.snow, serhiy.storchaka
2017-10-20 16:07:59jaracosetmessageid: <1508515679.21.0.213398074469.issue16737@psf.upfronthosting.co.za>
2017-10-20 16:07:59jaracolinkissue16737 messages
2017-10-20 16:07:59jaracocreate