lilypond-devel
[Top][All Lists]
Advanced

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

Re: Python 3


From: David Kastrup
Subject: Re: Python 3
Date: Sat, 21 Sep 2019 11:25:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Jonas Hahnfeld via lilypond-devel <address@hidden> writes:

> Am Samstag, den 21.09.2019, 12:09 +1000 schrieb Andrew Bernard:
>> So let me get this straight.
>> 
>> It's not the case that GUB is completely broken. We can still build 
>> releases.
>> 
>> DK is working steadily to cherry pick items for 2.20.
>> 
>> Python 2 to Python 3 is a major issue.
>> 
>> So, I offered to do the 2->3 port a long time ago but circumstances 
>> prevented me from doing so. Would it be constructive if I launched into 
>> that aspect? I cant understand the lilypond internals code but I have 
>> extensive Python experience.
>> 
>> Would this be helpful to moving forward?
>> 
>> But have people already started on this, I thought?
>
> I've also started looking into this and used the branch
> dev/knupero/lilypy3devel as a starting point (see also 
> https://lists.gnu.org/archive/html/bug-lilypond/2019-08/msg00014.html).
>
> On top of that I've worked on the attached patches which brings the
> make targets check / test and doc back to life with Python 3.7.4. Maybe
> they can be added to the branch mentioned above to serve as a single
> source of truth? I know the third patch is pretty large, let me know if
> I should try to split it up...
>
> As I'm pretty new to the development of Lilypond, I'm not really sure
> if there's something else to do in the source code repository itself?
> I'm pretty sure I didn't get to run through all error branches in all
> scripts, but the targets mentioned in the documentation work for me
> right now. If not, sounds like working on GUB would be next?

I haven't checked yet, but at the current point of time, the best
patches will be those running under both Python 2 and Python 3 without
having to special-case code.  Those can be applied to master and thus
minimize the actual amount of code switching we ultimately need to do.

-- 
David Kastrup



reply via email to

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