lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0


From: David Kastrup
Subject: Re: Python 3, was Re: ANN: Frescobaldi 2.19.0
Date: Sat, 23 Apr 2016 12:57:49 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Andrew Bernard <address@hidden> writes:

>> On 23/04/2016, 6:33 PM, "David Kastrup" <address@hidden> wrote:
>>
>>>Well, unless there are really compelling reasons otherwise, sticking
>>>with a common subset (namely making it work with Python 3 while keeping
>>>it working with Python 2) would seem like the sanest option.
>
> Pardon my ignorance but why do you want to support a common subset?
> For what purpose? The whole point of Python 3 is that it breaks 2 in
> order to become a superior and more consistent langauge. It’s been out
> since 2008, an eternity in IT terms. Please help me understand.

address@hidden:/usr/local/tmp/lilypond$ uname -a
Linux lola 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:34:49 UTC 2016 i686 
i686 i686 GNU/Linux
address@hidden:/usr/local/tmp/lilypond$ python --version
Python 2.7.11+
address@hidden:/usr/local/tmp/lilypond$ 

Without a really compelling reason, using a version of Python not
corresponding to the default version of Python for even the most
up-to-date version of the most common GNU/Linux distribution (which
LilyDev is based on) means that we buy into early adopter problems.  In
particular since we are talking about the whole cross-building
environment for all operating systems we are supporting.

So there is a whole wagonload of additional work and maintenance and
trouble involved with becoming incompatible to Python 2.

As I said: staying compatible with Python 2 while making sure we become
compatible to Python 3 is unsexy work.  It will pave the ground for a
later time where we may follow Ubuntu in making Python 3 the default,
and go there also with GUB.  And after a grace period _after_ that,
using pure Python 3 or later constructs will no longer come at
considerable cost to other people involved with the project.

There is a whole lot of weight to be lifted in connection with becoming
incompatible with Python 2.  Part of the weight will be gone once Ubuntu
itself moves there.  But without an actual plan and the resources for
actually pulling the weight here, it does not seem that declaring the
fallout "somebody else's problem" is going to be the least problematic
option.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]