my suggestion was to make sure that the user can type "bar arg" to start a Python program called "bar" with the argument "arg". that's trivial, on all major platforms, despite what Nick says -- and yes, you can start threads from a program named "bar". try it.
The command line switch came out of a pydev discussion regarding making pdb and profile easy to run for developers using multiple versions of Python on the same computer (e.g. someone running a Python 2.3 default installation, a Python 2.4 alpha alternate installation and a Python build from CVS).
Making a *single* version of an end-user application available on a platform is, as you say, quite straightforward. Versioning issues may need to be considered, but they're usually limited to making sure you get the 'right' Python out of any which are available on the machine.
And for an application, especially one not aimed at developers, that's almost certainly the right road to take. You'll have a name already, and presumably a versioning system as well (I believe dist_utils provides something along those lines).
Making a Python-version specific developer tool easily accessible isn't quite as straightforward, since you need to deal with making multiple versions available simultaneously, and each version has a different definition of the 'right' interpreter. As happened in the standard library with pdb and profile, the result is often to just not bother with it - leaving the developer to specify the full path to the particular version they want to run. That is, quite frankly, a pain - the same info is getting specified twice (once in selecting the python version to run, and again in specifying the full path to the associated tool)
One of the options explored in the original pydev discussion that led to '-m' was standalone, executable scripts for pdb and profile. The major issue with that idea was that it didn't scale very well - to use that solution for any other potentially useful scripts in the standard library, we would have had to come up with a decent name for each one, and then apply whatever versioning mechanism we settled on.
Using the Python module namespace to find the script means that all the versioning issues are already taken care of by the Python interpreters own versioning system - whichever version of Python you specify in the command line invocation, you get the correct version of the tool for that version of Python. It has the added bonus of working not only for pdb and profile, but any other scripts which are found to be useful (even those in extension packages, if this PEP is accepted by the BDFL).
Cheers, Nick.
P.S. As you might have guessed from the above, it's not the least bit coincidental that the example scripts I generally use when discussing '-m' are pdb, profile and pychecker.checker. This feature is a convenience for command line junkies - which seems to be a fairly common trait amongst the developers I know :)
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list
