Re: Upgrading Python - why not bundle official 2.7 binaries?

[Ben Rudiak-Gould]

On Wed, Dec 19, 2012 at 1:43 AM, David Kastrup <address@hidden> wrote:
> "address@hidden" <address@hidden> writes:
>> ...it seems like the
>> question is why we don't download the binaries directly and bundle
>> them with LilyPond.
>
> Because then all bets are off concerning comparable results.

Not if you bundled the same release version of the binaries on every
platform. I do understand the problem -- that if the bundled Python
scripts break, people complain to you, not python.org -- but has it
ever actually happened that a problem with a Python script was traced
to a bug in the Python interpreter that couldn't be worked around in
Python and hadn't been fixed in a post-2.4.5 mainline release? If it
does happen you'd be at the mercy of python.org, but those binaries
have a lot more users than LilyPond's. Showstopping bugs are not going
to last long. I don't see how the situation could be worse than it is
now. The current upgrade process is apparently so time-consuming or so
confusing that the internal Python has never even been updated to
2.4.6 (a bugfix release that's 4 years old today) or 2.5.2 (which was
released before 2.4.5). It's a bit worrying that 2.4.6 fixed a long
list of security vulnerabilities, including multiple buffer overflows
that might be exploitable by specially crafted input files. Not that
LilyPond is a high-profile target, but still.

Aside from that, I care because when writing some Python code I hope
to add to LilyPond, I kept having to work around missing things (x if
b else y, decorator syntax, with statements, int.from_bytes, cProfile,
timeit.timeit()...)

> Neither is there anything unusual about LilyPond's use
> of Ghostscript.  Or GUILE.  Or the Bourne shell.  Or about half a dozen
> other dependencies.

Ghostscript's situation seems similar to Python's, but I don't know
much about it so I have no opinion. Guile seems special because it's
tightly integrated with Lilypond's parser, whereas the only code that
uses the Python API is in midi.c (which I just rewrote in Python with
negligible performance impact). The Bourne shell doesn't appear to be
shipped with LilyPond -- the Linux sharchive is at the mercy of
whatever /bin/sh the user happens to have installed.

-- Ben