lilypond-devel
[Top][All Lists]
Advanced

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

Re: Python compatibility


From: Carl Sorensen
Subject: Re: Python compatibility
Date: Tue, 15 Jan 2019 18:49:40 +0000
User-agent: Microsoft-MacOutlook/10.10.5.181209


´╗┐On 1/15/19, 11:37 AM, "David Kastrup" <address@hidden> wrote:

    Carl Sorensen <address@hidden> writes:
    
    > 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
    > try?
    
    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.

My plan was actually *not* to put the updated python into GUB, but rather to 
convert the python code in LilyPond so I could build and run lilypond with 
python 2.7.x or 3.x on  a lilydev VM.  I wasn't planning on working on GUB 
integration, because I don't have the build-system chops for that.  Maybe this 
makes my proposal an overly-optimistic proposal, and I should not get drawn in. 
 I'd welcome thoughts about this.
    
    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
    once.

My hope  was to actually do the _replace_ of Python2.4.x with Python2.7.x or 
Python3 in the lilypond code base, but not in GUB.  I was not hoping to do a 
one-at-a-time file conversion, precisely because of the difficulty involved in 
getting both supported.  But I note that Python provides several conversion 
utilities, including the six library, which is supposed to enable running the 
same code in either Python2 or Python3.

    
    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
    work.

Is it crazy to think of replacing all of the python files before making the 
change to GUB?  I literally do not know the answer to this question.

Thanks,

Carl
 


reply via email to

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