<div dir="ltr"><div class="gmail_extra">On 12 August 2013 14:01, PJ Eby <span dir="ltr"><<a href="mailto:pje@telecommunity.com" target="_blank">pje@telecommunity.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":3zs" style="overflow:hidden">This means that you can actually write source as a .pyz or .pwz file<br>
on Windows, and it would Just Work -- *without any sys.path<br>
modification*.</div></blockquote><div><br></div><div>Conversely, you can right now rename a zipped file as xxx.py and it will be run happily as a Python standalone zip file. It confuses the heck out of things like text editors and zip file managers, of course :-)</div>
<div><br></div><div>We currently have 2 extensions on Windows - .py and .pyw. These get a default run action of the launcher (py.exe and pyw.exe versions respectively) and both are treated as marking Python modules (I don't know why anyone would create a Python module with a .pyw extension - sounds like an unnecessary attempt to apply "consistency" to me). Having two more that had the launcher as default action but did *not* mark Python modules might make sense. Having further extensions is fundamentally a documentation-only exercise - they will not be treated any differently by any code shipped by Python.</div>
<div><br></div><div>The problem is that documentation (and user expectation) is important - nobody expects a .py file to be a binary zip file (and they'd get a shock if they opened it in a text editor). On the other hand, grabbing a huge host of file extensions (.py, .pyw, .pyo, .pyc, .pyz, .pwz, .pys, .pws) is not very friendly, as well as adding the burden of clearly documenting what all these various extensions *mean*.</div>
<div><br></div><div>My view would be:</div><div><br></div><div>1. We can't touch .py/.pyw behaviour for backward compatibility reasons</div><div>2. A new suffix that is associated with the launcher but which does *not* mark importable modules would be good. (Call it .pys for now).</div>
<div>3. I'd rather not see further extensions added, six is plenty.</div><div><br></div><div>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.</div>
<div><br></div><div>Apologies if I've missed an obvious flaw - I'm way behind on sleep at the moment...</div><div><br></div><div>Paul.</div><div><br></div><div>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.</div>
<div></div></div></div></div>