On Fri, May 29, 2015 at 1:28 AM, Chris Barker <chris.barker@noaa.gov> wrote:
On Thu, May 28, 2015 at 9:23 AM, Chris Barker <chris.barker@noaa.gov> wrote:
Barry Warsaw wrote:
>> I do think single-file executables are an important piece to Python's long-term competitiveness.

Really? It seems to me that desktop development is dying. What are the critical use-cases for a single file executable?

oops, sorry -- I see this was addressed in another thread. Though I guess I still don't see why "single file" is critical, over "single thing to install" -- like a OS-X app bundle that can just be dragged into the Applications folder.

It is much simpler to deploy in an automated, recoverable way (and also much faster), because you can't have parts of the artefact "unsynchronized" with another part of the program. Note also that moving a python installation in your fs is actually quite unlikely to work in interesting usecases on unix because of the relocatability issue.

Another advantage: it makes it impossible for users to tamper an application's content and be surprised things don't work anymore (a very common source of issues, familiar to anybody deploying complex python applications in the "enterprise world").

I recently started using some services written in go, and the single file approach is definitely a big +. It makes *using* applications written in it so much easier than python, even though I am complete newbie in go and relatively comfortable with python.

One should keep in mind that go has some inherent advantages over python in those contexts even if python were to gain single file distribution tomorrow. Most of go stdlib is written in go now I believe, and it is much more portable across linux systems on a given CPU arch compared to python. IOW, it is more robust against ABI variability.