lilypond-devel
[Top][All Lists]
Advanced

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

Re: Python 3


From: Matthew Peveler
Subject: Re: Python 3
Date: Mon, 30 Sep 2019 20:46:19 -0300

On Mon, Sep 30, 2019 at 7:08 PM Dan Eble <address@hidden> wrote:

> The thought that gave rise to my question was that I would be more
> comfortable collaborating if these changes were in git rather than a dozen
> patches in multiple messages in the mailing list archive.  (I don’t intend
> that to sound mean.)
>

I've been maintaining my work in
https://github.com/MasterOdin/lilypond/tree/py3_future2, though I fear I
squashed Jonas' patches into a singular commit between Knut's and my
commits. However, I think before going further, it is important that the
maintainers finalize what they would like to see in terms of python
compatibility for LilyPond and GUB, though a fair number of the changes can
be landed in upstream master and work on Python 2.4 as well (move to new
style classes, change the string raise to the LilyError class, etc.),
though some require a minimum of Python 2.6 (changes to exception handlers,
__future__.print_function).

I'd be happy to start putting together some patches and submitting them for
review if that would be helpful in this effort, or if this effort is better
directed somewhere else within the python infrastructure of LilyPond/GUB.

> my principle test was that the targets finished without error
> > . . .
> > The stepmake stuff though is were I have no idea how to handle as I am
> not sure exactly what its purpose/doing is.
>
> Is that pessimism?
>

Somewhat, though more at the bigger picture of that this makefile is far
far more complex than the simple ones I've ever dealt with and trying to
figure out the pieces of how it all fits together, plus the necessary
modifications to get it cross version compatible.


> If you want to discover whether the targets you are testing exercise the
> rules in python-module-rules.make, you can insert a command that will fail
> when you get there, e.g.
>
> $(outdir)/%.pyo: $(outdir)/%.py
>         false # DO NOT COMMIT
>         $(PYTHON) -O -c 'import py_compile; py_compile.compile ("$<")'
>
> If your tests are exercising those rules and nothing else seems to go
> wrong, that should reduce your concern.
>
Sorry, I was unclear, should not have rushed to put that last email
together as I was walking out the door. It's more accurate to say that I
understand conceptually what that particular snipped does and how one could
make it work on just Python 2 or Python 3.7, but I do not know one would
approach making it work on both Python 2 and Python3.7 (and potentially
other Python3 targets) and that I think it would be something in if
statements in python-module-vars.make to be in pseudo-code:

if python3:
  py_version = python -c "import sys; print(str(sys.version_info[0]) +
str(sys.version_info[1]))"
  build_dir = $(outdir)/__pycache__
  extension = .cpython-$(py_version).pyc
else:
  build_dir = $(outdir)
  extension = .pyc

with the build target being:

$(build_dir)/%$(extension): $(outdir)/%.py

-

I briefly tried to convert that to actual make syntax, but was getting
nowhere slowly, and have given up on that bit for now.

Matt


reply via email to

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