[Distutils] small improvement of the script functionality under win32

[Paul Moore]

On Apr 4, 2005 10:55 PM, Trent Mick <trentm at activestate.com> wrote:
> I don't know if adding something like exemaker would be feasible or even
> desirable:
> - might cause other headaches
> - people might not want a launcher file separate from the script
>   file itself

To be honest, I think that personal preference issues are a big
problem here. I find the "Do you want to terminate the batch file"
message annoying, but I have no problem with a .py extension. I have
.py registered in PATHEXT and all the necessary places to make .py
files "executable" - not all of the necessary things are done by the
Python installer, though (for reasons which I accept) and so this
isn't a universally acceptable solution either.

> One benefit of a separate launcher file over a
> script-in-batchfile-clothing approach: we might be able to take
> advantage of python's "-m" option such that a Python script that can
> also operate as a module (e.g. timeit.py, pydoc.py) could stay in the
> Lib dir and the launch could be put in the bindir.

To be honest, the -m option (once support for packages appears, which
I believe is scheduled for 2.5) probably makes script files 99%
unnecessary. For people who absolutely insist on a "command", a
1-liner .bat file

   @pathtopython -m module %1 %2 %3 %4 %5 %6 %7 %8 %9

(avoid %* for command.com compatibility) should be adequate. With
distutils support, a suitable platform-specific script like this could
even be generated automatically, if needed.

This is mainly a social change, though - persuading package
maintainers to write their code such that -m can be used.

Maybe a documentation change is the best approach. Add some text to
section 2.4 (Installing Scripts) of "Distributing Python Modules" to
say something like:

"""
By their nature, script files are inherently platform dependent -
certain platforms require particular file extensions, or other
conventions. Since Python 2.4, the Python executable has supported a
command-line option -m (reference to the docs here) which allows
modules to contain an executable section (see, for example, the timeit
or compileall library modules). Where possible, writing modules which
support the use of -m will be more portable than distributing
standalone scripts.
"""

Paul.