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

Nick Coghlan ncoghlan at email.com
Mon Oct 4 13:43:30 CEST 2004

Quoting Raymond Hettinger <python at rcn.com>:

> The combination of batch file and run.py isn't as good as the -m option,
> but it works and mostly meets my needs.  The batch file is rather dumb,
> doesn't work with other python command line options, and won't work
> pipes.

Hmm, that point about command line options is a good one. I know I'd find it
handy to be able to throw in a '-i' when I wanted one.

Then again for commands with minor variations, I tend to rely on command line
history rather than using a batch file (that is, I'll type out a long invocation
sequence once a session, then edit it as needed)

> Could Nick's idea be done without an -m option?

To be fair to Ilya - his idea, my implementation :)

>  If a user types,
> "python abc.py" and "abc.py" is not found, before aborting, try looking
> for it on sys.path.

That's do-able, but the command line option seems cleaner if the interpreter is
going to provide C-level support for this. I interpreted Guido's last message as
saying he's prepared to tolerate the command line option if there's sufficient
support for it.

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

  - 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

I find that persuasive enough that I think it's worthwhile to finish the '-m'
patch, and add a documentation patch.


Nick Coghlan
Brisbane, Australia

More information about the Python-Dev mailing list