Am Samstag, den 21.09.2019, 11:25 +0200 schrieb David Kastrup: > Jonas Hahnfeld via lilypond-devel < > lilypond-devel@gnu.org > > 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.
I agree that this would be ideal, but pretty hard: Already the result of running 2to3 can't be executed under Python 2 in some cases or may start to give different results. Examples include * "isinstance(s, unicode)" -> "isinstance(s, str)", which is something different in Python 2, and * "import StringIO" -> "import io", which didn't have all functions in Python 2. If that is the way required to get Lilypond ported to Python 3, I can try to work into that direction. But finally, I guess there will need to be a hard switch to Python 3... My 2 cents, Jonas
signature.asc
Description: This is a digitally signed message part
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel