'-m' option (was RE: [Python-Dev] ConfigParser patches)

Ilya Sandler ilya at bluefir.net
Mon Oct 4 19:33:26 CEST 2004

> To summarise the differences between the two approaches:
> Pros (-m over runpy.py, in order of significance as I see it):
>   - easy to combine with other Python command line options
>   - OS & environment independent
>   - easier to use with a non-installed interpreter
>   - no work for Python packaging folks
>   - more concise to invoke
>   - no namespace issues with naming a script
>   - C API for those embedding python

There is one more small pro: easier to version: e.g if there are multiple
installed versions of python on your machine, you could could invoke a
module from a particular python version:

python2.4 -m pydoc

with a wrapper script you will need a wrapper per version...(Or some way
to find/invoke the right version of python from the wrapper)


> Cons:
>   - YACLO (Yet Another Command Line Option)
>   - CPython specific (other interpreters could choose to reimplement)
> With YACLO seeming to be Guido's main reason for being -0 on the idea.
> It looks like the script option would require input from those with better
> knowledge than me of the packaging set up for Windows, *nix and Mac as to how it
> could be made to work 'nicely' in each environment.
> And the issue of combining it with other command line options would remain. It's
> all very well to have "runpy.py" as an executable script, but providing extra
> options to the interpreter would require:
> 1. Locate runpy.py (e.g. /usr/bin/local/runpy.py, /usr/bin/runpy.py)
> 2. Invoke python <options> <dir>/runpy.py <module>
> Which means we're back to having to find out where at least part of the Python
> installation lives on each machine (only once per machine, which is an
> improvement over the status quo, but still not as tidy as a single command line
> option).
> I find that persuasive enough that I think it's worthwhile to finish the '-m'
> patch, and add a documentation patch.
> Regards,
> Nick.
> --
> Nick Coghlan
> Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ilya%40bluefir.net

More information about the Python-Dev mailing list