[Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Paul Moore]

On 28 May 2015 at 18:04, Brian Curtin <brian at python.org> wrote:
> Donald mentioned one earlier: command line utilities. I want a single
> CLI I can deploy to my customers that doesn't make them have to
> install Python or even know it's Python at all.

Yep, that's the killer for me as well.

I know it's unrealistic in some sense, but my benchmark is what does a
"Hello, world" program look like? In C, it's a 38K executable with no
external dependencies. What does it look like in Python? (I'm not too
worried if it's a bit bigger, but if it's a *lot* bigger that starts
to be noticeable - "Python generates bloated exes").

What I'd like to be able to do is to write Python ports of a range of
core Unix utilities (comm, cut, join, od, seq, tr, ...) and have them
be viable alternatives to my current C builds (a series of single-file
100-200k static exes).

On 28 May 2015 at 18:15, Chris Angelico <rosuav at gmail.com> wrote:
> Unix-like systems have this courtesy of the shebang, so as long as
> there's some sort of Python installed, people don't need to know or
> care that /usr/local/bin/mailmail is implemented in Python. Maybe the
> solution is to push for Windows to always include a Python
> interpreter, which would allow a tiny stub to go and call on that?

Unfortunately (and believe me, I've been down this road many times) on
Windows *only* the exe format is a "first-class" executable.
Executable scripts and shebangs are very useful, but there are always
corner cases where they don't work *quite* like an exe. On Windows,
you have to be prepared to ship an exe if you want to compete with
languages that generate exes.

Having said that, the trick of appending a zipfile to an exe (or
similar) is already common practice in the Python world, and works
really well. Vinay Sanjip's pyzzer is a good example of this approach.

On 28 May 2015 at 16:45, Steve Dower <Steve.Dower at microsoft.com> wrote:
> Agreed, but the minimally functioning Python is barely under 5MB. That will be
> considered bloated and won't help us compete with Go, so we should find a better
> way to fix Python application distribution and stop getting so hung up on putting
> everything into a single executable file.

There's a perception issue here. You can compile C# code into small
exes (that's how people think) and "all" you need is the .net runtime
installed. If we shipped a "pyc" compiler that "compiled" Python code
into small exes that "just needed the Python runtime installed" would
that feel the same to people? Would they be happy to view that as
comparable to go compiled executables? (I assume go *doesn't* rely on
a separate runtime, though).

Nevertheless, I would like to understand how Unix can manage to have a
Python 3.4.3 binary at 4kb. Does that *really* have no external
dependencies (other than the C library)? Are we really comparing like
with like here?

Paul