2009/7/21 Brett Cannon <brett@python.org>:
Taking Paul's follow-up email to this into account, I think we should definitely encourage people support runpy, but that doesn't do away with the usefulness of scripts. Ignoring the convenience factor of having short script names (``hg tip`` is much shorter than ``python2.6 -m mercurial -- tip``), there is also having to remember which interpreter you installed a tool under. Did I install hg under my Python 2.3, 2.4, 2.5 or 2.6 interpreter? I actually had to check the hg script to find that out. And there is also the situation where people are not targeting multiple operating systems and thus have a use for the features a script gives. If I am writing some Linux app in Python I might have some need to run something under bash. So while I totally support pushing people to start using runpy now that __main__.py support exists for packages, I don't think we can just fluff off script support.
Just to clarify - my personal view ("tainted" by Windows experience, certainly) is that *applications* (such as Mercurial) should be built as isolated, standalone executables, bundled with something like py2exe. I fully appreciate that this is the precise opposite of common practice on Linux (see below for some uninformed speculation on that). I see runpy as being appropriate for the types of small "supporting" scripts that come with general-use packages - things like Twisted's twistd, Nose's nosetests, etc. Essentially, where the package is the key thing, and the command is a related utility. When the command is the main focus, I see that as an "application". I don't know the right answer for "applications" under Linux, but I don't see any reason why a wrapper shell script wouldn't work - it's no less portable than a py2exe built executable. Installing a wrapper is then the responsibility of the packaging system, rather than Python. But as I say, my expertise is basically zero here. Paul.