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

[Nick Coghlan]

Quoting Raymond Hettinger <python at rcn.com>:

> > It's so easy to define an alias or use a one-line shell script for
> > invoking Python with a full pathname that I'm really not sure I like
> > the -m idea, 
> 
> My understanding was that it wasn't about a full pathname to python, it
> was about searching sys.path for the darned script so us poor Windows
> guys don't have to change directories a million times a day (no aliases
> or shebangs for us either).

Correct. Ilya's original example was wanting to invoke pdb's script behaviour in
order to debug another script. At the moment, you have to run:

python -c "from inspect import getsourcefile; import pdb; print getsourcefile(pdb)"

or

python -c "from imp import find_module; print find_module("pdb")[1]"

to find out where the file is, and then run python normally with the filename
that gets printed by one of the above scripts. (With a Unix-style shell,
backticks make that easier. Doesn't help on Windows though).

The "-m" option aims to automate this process (using the latter 'find_module'
approach in C code)

> > Supporting it with packages seems insanity.
> 
> No doubt.

I'm starting to lean that way myself. The semantics for a straight module are
easy, but the package version is horrible (Either we have a package getting
imported before "__main__" starts running, or else we don't properly support
package __path__ variables. I don't find either option appealing)

I think I'll simply drop all package support from the patch and allow modules
only. That will still cover the initial use cases (pdb, profile and the like)
Adding support for packages later (in a different patch) would still be possible
if there was interest.

Cheers,
Nick.

-- 
Nick Coghlan
Brisbane, Australia