[Distutils] How to handle launcher script importability?
p.f.moore at gmail.com
Mon Aug 12 16:32:43 CEST 2013
On 12 August 2013 14:01, PJ Eby <pje at telecommunity.com> wrote:
> This means that you can actually write source as a .pyz or .pwz file
> on Windows, and it would Just Work -- *without any sys.path
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 :-)
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
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*.
My view would be:
1. We can't touch .py/.pyw behaviour for backward compatibility reasons
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).
3. I'd rather not see further extensions added, six is plenty.
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
Apologies if I've missed an obvious flaw - I'm way behind on sleep at the
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG