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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list
