On 12 August 2013 11:21, PJ Eby <[email protected]> wrote: > 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.
I like this idea. >> 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.) This sounds like a plausible approach, especially if we add the bootstrapping being considered for 3.4+ to PyLauncher for earlier versions. (Donald has a draft PEP for that, he's just making a few tweaks before publishing it for broader comment) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
