Short review of the superseded bugs.

#870479 — Scripts need platform-dependent handling
A request to remove .py on POSIX and create a .cmd file on Windows.  The .cmd part was quickly shot down (see bug thread for problems), and the discussion moved to the setuptools generation.  Interesting comment by a Windows user:
> In principle I don't have a problem with the automatic generation of an
> EXE (I assume it generates a shell script with no extension on Unix?)
> but it should be done in such a way that the EXE is version-independent.
> This is necessary to ensure that pure-python packages, when made into
> bdist_wininst installers, continue to be version-independent. (At the
> moment, distutils generates version-dependent bdist_wininst packages
> *only* for C extensions. Setuptools generates version-dependent
> installers all the time, which is a pain).
> 
> This may mean that a reimplementation is required, rather than copying
> the setuptools code.

The bug links to a thread on distutils-sig, where we can find one more issue by Robert Kern:
> In the generated script, please use "if __name__ == '__main__':" to
> block out the executable bits. Currently, multiprocessing does not
> work on Windows when the application is started by a console_script.
> Because Windows does not have a true fork, multiprocessing will start
> up clean Python subprocesses that import the __main__ of the parent
> process.
(http://mail.python.org/pipermail/distutils-sig/2009-February/010981.html)


#976869 — Stripping script extensions with distutils
A patch by Fred Drake (distutils hacker) to build_scripts to remove the unneeded .py on POSIX.


#1004696 — translate Windows newlines when installing scripts on POSIX
A request that scripts created with CRLF be installed with LF on POSIX, to make the shebang mechanism work.


#4015 — Make installed scripts executable on windows

A patch to add a .bat file for each script (the .bat runs the .py).  Contains the first discussion about a launcher for Windows (PEP 397), and issues with .exe files.


So, Tarek and Fred have expressed support for the setuptools generation in a handful of bug reports and emails, and a number of users report they like it.  IIUC, setuptools supports using python vs. pythonw on Windows (console vs. GUI), but is not flexible enough about which Python version to use, and does not support installing into bin vs. sbin on UNIX (see http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard to learn more about /bin, /sbin, /usr/bin and /usr/sbin).  The cli.exe and gui.exe files look like they can be reused, but the install_scripts code will require more work.

Another interesting thread that was linked from one of the reports: http://mail.python.org/pipermail/distutils-sig/2004-July/004071.html

Finally, when the script generation is implemented and documented, care should be taken to add some doc about old-style script files compatibility.  Projects can have valid reasons to use files for Python scripts, and need a way to install them.  Issues about shebang edition (the distutils behavior in build_scripts) and newlines translation (#1004696) will need thought.