On Mon, Aug 12, 2013 at 10:32 AM, Paul Moore <[email protected]> wrote: > On 12 August 2013 14:01, PJ Eby <[email protected]> wrote: > > As far as zipped Python applications are concerned (pyz), these can be > created by just using a pys file containing a #! line prepended to the zip > file. Certainly, it's a binary file with a filename that would normally > indicate a text file format, but is that any less true on Unix when users > create these files? I don't know what the user experience with zipped Python > applications on Unix is like - I doubt it's *that* much better than on > Windows. Probably the reality is that nobody uses zipped applications > anyway, so the problems haven't been identified yet. Maybe the pyz PEP would > bet better rewritten to propose providing tools to create and manage zipped > Python applications, but *not* to require new extensions, merely to reuse > existing ones (pys on Windows, no extension on Unix) with binary (zipped) > content.
Seems reasonable... but then somebody will need to write another PEP for the file extension(s) issue. I think the issue of "too many extensions" vs. "source/binary confusion" is going to boil down to a BDFL judgment call, whether it's by Nick, Guido, or some more Windows-specific BDFL For One PEP. If we go with One Extension To Rule Them All, I would actually suggest '.pyl' (for PyLauncher), since really all that extension does is say, "hey, run this as a console app via PyLauncher", not that it's a "script" (which would be assumed to be text). And that all you can be sure of is that a .pyl files will start with a #! line, and launch whatever other program is specified there, on the contents of the file -- which may actually be a zipfile. > PS Either the ref file marker approach, or a new Python command line > argument with appropriate behaviour, could avoid the need for even the > pys/pws extension, if people prefer to reduce the number of extensions > claimed still further. But those would only be available for future Python versions. A file extension would solve the problem upon installing PyLauncher and PATHEXT, at least for those OSes and shells that recognize PATHEXT. Hm, here's a side thought: what if PyLauncher added the ability to serve as a script wrapper, just like setuptools' existing wrappers? Then setuptools could just copy py.exe or pyw.exe alongside a .pyl or .pyw, and presto! No PATHEXT compatibility needed, but users could still opt out of using the .exe wrappers if they're sure their shell works right without it. (The wrapper facility would be implemented by simply checking for an adjacent file of matching filename and extension (.pyl for py.exe, .pyw for pyw.exe), and if found, insert that filename as argv[1] before proceeding with the normal launch process. For efficiency, the file check could be skipped if the executable has its original name, at the minor cost of it not being possible to name a console script 'py' or a windows app 'pyw'. But that's an optional tweak.) _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
