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

[Nick Coghlan]

Fredrik Lundh wrote:
> 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   |   ncoghlan at email.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.skystorm.net