PEP 338: Executing modules inside packages with '-m'

[Nick Coghlan]

Fredrik Lundh wrote:
> I'd say that for a typical user,
> 
>     $ python -m foo.bar arg
> 
> is a marginal improvement over
> 
>     $ python -c "import foo.bar" arg

This doesn't work. Any code protected by "if __name__ == '__main__':" won't run 
in this context (since 'foo.bar' is being imported as a module, not run as a 
script).

Even 'python -c "from foo.bar import _main; _main()" arg' isn't quite right, 
since sys.argv[0] will be wrong (it will say '-c', instead of giving the 
module's filename). There's also the problem that there is no standard idiom for 
_main() functions.

> compared to
> 
>     $ bar arg

This is true, but it has its own problems, mainly in the area of namespace 
conflicts on the packaging side:

1. Namespace conflicts between different Python versions
2. Namespace conflicts between different Python packages
3. Namespace conflicts between Python packages and other programs
4. Additional overhead to create an installed module that is usable as a script
   a. Add a shebang line for *nix style systems
   b. Think about how to deal with the previous 3 points
   c. Update the installer to copy the file to the right place with a good name
   d. Realise you're screwed on Windows, since you can't control the file 
associations and the script will always run with the default interpreter.

An extended -m, on the other hand deals with all those problems automatically:

   python -m foo.bar arg     # Default interpreter, foo's bar
   python -m bar.bar arg     # Default interpreter, bar's bar
   python24 -m foo.bar arg   # Force Python 2.4, foo's bar
   python24 -m bar.bar arg   # Force Python 2.4, bar's bar
   bar arg                   # Unrelated application called bar

Points 1, 3 & 4 were the justification for adding the current version of -m to 
Python 2.4 (obviously, point 2 didn't apply, since the current version doesn't 
work for modules insides packages). Specifically, it makes it trivial to get 
hold of the right version of pdb and profile for the interpreter you're working 
with.

For usability, you can hide all of the above behind a menu item or desktop 
shortcut. However, the major target of the feature is Python developers rather 
than the end-users of applications built using Python.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at email.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.skystorm.net