[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Python compatibility
Re: Python compatibility
Tue, 15 Jan 2019 19:37:12 +0100
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
Carl Sorensen <address@hidden> writes:
> On 1/15/19, 6:05 AM, "lilypond-devel on behalf of Knut Petersen"
> <address@hidden on behalf of
> address@hidden> wrote:
> @everybody: Does anybody volunteer to write a patch to allow
> python to be compatible with gcc 8? Probably it's easier to tell
> python's config to look for a gcc-7 (and maybe some other names) if
> the systems gcc is version 8.x (and to abort with a reasonable error
> message if no compatible compiler is
> I don't know how to write the patch that you've requested.
> I've looked into python a little bit, and find that python 2.4.5 is
> more than 10 years old; it's not even receiving new security updates.
> It seems like it would be better to spend time updating our python
> code base to be compatible with either python 2.7.15 (released
> 2018-05-01) or python 3.7.2 (released 2018-12-24). I would expect
> python 3.7.2 to be compatible with gcc 8.x.
> I'm willing to take a stab at converting our python codebase. I can't
> promise I'll succeed. But in order to get started, I'd like to get
> answers to a couple of questions:
> 1) Why should I prefer 2.7.x over 3.7x (or vice versa)? All of my
> python coding to this point has been in 2.x. I suspect there would be
> lots more changes to go to 3.x. So any opinions on which I should
2.7.x. That has some chance of being a reasonably doable one-man job
with occasional help rather than a specialist job. The 3.x migration
can be done independently without being tied to Gub work.
Enough people are already running LilyPond (namely versions compiled
without Gub) on 2.7.x that it is clear that this is "just" a matter of
getting Gub to compile it. For a one-by-one file migration to Python
3.x we'd need to stick to a compatible subset, or require both Python
versions (particularly in Gub). It would make more sense to figure out
a strategy with which we could make dependable progress with Python-3
compatibility so that at one point of time it would become a matter of
_replacing_ Python2 with Python3 in Gub rather than requiring both at
So to tackle 3.x, there needs to be a design phase and autoconf magic
and stuff to get to a state where it becomes easy to migrate single
files (without requiring them to need Python 3.x).
In contrast, migrating to 2.7 is a Gub-only job. That's much better
defined and better cut out to be single-person or at least single-focus