On Wed, Aug 14, 2013 at 10:33 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
If you prepend the shebang line, you get a ".pya" file (Note: I suggested to Daniel that the extension be changed to "pya" for "Python application", but the PEP hasn't been updated yet), if you prepend the executable, you get an actual Windows executable.
The shebang line, or some equivalent is still needed, even if you're prepending an .exe. (It does need to be able to find Python, after all.) The wrappers, I think, should also be updated to support the .deleteme protocol I described earlier, so that if, upon exiting, the program finds it is named .deleteme, it should respawn Python with a -c scriptlet to delete the .deleteme file, and immediately exit without waiting for the result. That way, pip and other installation tools can update their own .exe files, without leaving any garbage behind. With this overall approach, .exe's can remain the default choice of script wrapping, with .pya's available as an option for those who want them. PyLauncher should include the .pya association and PATHEXT, and people who want to write or edit scripts by hand can use that extension. (Of course, using .pya won't work with subprocess.call and other CreateProcess-y things, which incidentally reminds me that I've had some royal pains in the past trying to get other applications to invoke Python scripts or indeed *any* language scripts. For example the Calibre Windows app's "Open With..." plugin requires an .exe... and it's *written* in Python, for heaven's sakes! So .exe headers and extensions for .pya files really ought to be the default option on Windows, for the sake of users' sanity. Plain-text .pya files are a developer/quick-and-dirty feature that you don't use for scripts on Windows that are invoked by anything besides other scripts.)
That would also let us avoid the need for a separate ".pyaw" extension - you would just prepend a Windows GUI executable to handle that case, with .pya only handling console applications.
Shouldn't naming the file .pyw already work today for that case? Certainly, the .pyw extension is already suitable for manually creating GUI scripts in a text editor. Unless there's something special about how the 'pythonw' executable processes the command line, it should work just as well for a zipped archive. So, probably no need to have a separate extension in either case. (But maybe somebody should verify that 2.6+ on Windows does indeed run .zip files named with .pyw and double-clicked on.)