Python 3, was Re: ANN: Frescobaldi 2.19.0

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Python 3, was Re: ANN: Frescobaldi 2.19.0

Andrew Bernard
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.

Andrew





On 23/04/2016, 6:33 PM, "David Kastrup" <[hidden email]> 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.


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
Andrew Bernard <[hidden email]> writes:

>> On 23/04/2016, 6:33 PM, "David Kastrup" <[hidden email]> 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.

dak@lola:/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
dak@lola:/usr/local/tmp/lilypond$ python --version
Python 2.7.11+
dak@lola:/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

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

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

Andrew Bernard
Hi David,

But lilypond ships its own internal version of python in …lilypond/usr/bin. Is this not to shield lilypond from system versions?

In my Ubuntu I have:

$ uname -a
Linux fivefold 4.2.0-35-generic #40-Ubuntu SMP Tue Mar 15 22:15:45 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

$ /usr/bin/python --version
Python 2.7.10

and in the lilypond install:



$ ./python
Python 2.4.5 (#1, Apr  5 2015, 13:45:28)
[GCC 4.9.2] on linux

Clearly a considerably, and not entirely compatible, earlier version - as I know, having written a whole lot of python scripts for lilypond in 2.7 before realising we are on 2.4.


I am aware the entire ecosystem has to be ported. I am offering to do the work. It does not bother me that you think it is ‘unsexy’.

But I don’t understand why the system vesion of python matters. Why do we bundle it then?

Also, python 2 and 3 stand happily side by side on my openSUSE systems, ny Ubuntu systems, my Fedora systems, and my Debian systems. I am having trouble seeing what the issue is. If there comes a dependcy on python 3, surely anybody who is capable of downloading and installing lilypond can also download and install python 3?

Andrew




On 23/04/2016, 8:57 PM, "David Kastrup" <[hidden email]> wrote:

>dak@lola:/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
>dak@lola:/usr/local/tmp/lilypond$ python --version
>Python 2.7.11+
>dak@lola:/usr/local/tmp/lilypond$


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
Andrew Bernard <[hidden email]> writes:

> Hi David,
>
> But lilypond ships its own internal version of python in
> …lilypond/usr/bin.

Assuming that you install from our precompiled binary packages.
Obviously, that's not what the developers do since they need to run
LilyPond right after compiling it.  Also obviously that is not what the
packagers of distributions do since they compile a native version of
LilyPond and most certainly do not ship versions of Python crosscompiled
by us.

> I am aware the entire ecosystem has to be ported. I am offering to do
> the work.

Check out working on and with GUB for compiling various binaries first
in order to figure out how much work that's actually going to be.
That's a rather big hurdle, and it does not help overly with GNU/Linux
systems (and MacPorts and whatever else) packaging their own
compilations.  But the GUB hurdle of course is our personal showstopper.

> But I don’t understand why the system vesion of python matters. Why do
> we bundle it then?

We only bundle it for our installers, but LilyPond is obviously also
compilable natively.

> Also, python 2 and 3 stand happily side by side on my openSUSE
> systems, ny Ubuntu systems, my Fedora systems, and my Debian
> systems.

But they don't magically don't turn #!/usr/bin/python (or whatever else)
into #!/usr/bin/python3 and the latter will stop working with Python 4
anyway.

> I am having trouble seeing what the issue is. If there comes a
> dependcy on python 3, surely anybody who is capable of downloading and
> installing lilypond can also download and install python 3?

The "surely anybody who is capable of downloading and installing
LilyPond can also ..." argument is nonsense.  We are not trying to prove
mathematically that it is possible to install LilyPond, we are talking
about the kind of practical hurdle imposed here.

If you want to talk about theories, one could compile LilyPond natively
under Windows.  That's what Git also does, requiring the attention of
something like two developers and trailing half a year behind.
LilyPond's Windows version just falls out of our release process,
simultaneously with the rest.

Everything requiring constant effort and attention, even if you think
it's not a big deal, is something that is keeping people from using
LilyPond, or keeping developers from working on more important things.

Upgrading to a newer version of GCC stopped our release process from
working for several months.  That's exactly the kind of "it should not
be a big deal" that you are talking about here.

--
David Kastrup

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

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

Federico Bruni-2
On Sat, Apr 23, 2016 at 02:56:47PM +0200, David Kastrup wrote:
>
> Upgrading to a newer version of GCC stopped our release process from
> working for several months.  That's exactly the kind of "it should not
> be a big deal" that you are talking about here.
>

That's why the upgrades should be planned in advance before there's few time left.

Python 2 will reach end of life in 2020 (no bugfix releases from that date).
I guess that in 4 years Linux distros will "have to" (?) migrate to python3.
We might find ourselves in a similar position as for guile1.8/guile2

I would not discourage Andrew.
The task is difficult but it's worth the effort. I hope that he'll try
to tackle it and get support by this community.

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
Federico Bruni <[hidden email]> writes:

> On Sat, Apr 23, 2016 at 02:56:47PM +0200, David Kastrup wrote:
>>
>> Upgrading to a newer version of GCC stopped our release process from
>> working for several months.  That's exactly the kind of "it should not
>> be a big deal" that you are talking about here.
>>
>
> That's why the upgrades should be planned in advance before there's
> few time left.
>
> Python 2 will reach end of life in 2020 (no bugfix releases from that date).
> I guess that in 4 years Linux distros will "have to" (?) migrate to python3.
> We might find ourselves in a similar position as for guile1.8/guile2

Guile 1.8 is already the other way round: most distributions only still
support it because of LilyPond.  That's actually a quite more urgent
deal.

--
David Kastrup

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

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

Stemby
In reply to this post by Federico Bruni-2
2016-04-23 15:19 GMT+02:00 Federico Bruni <[hidden email]>:
I guess that in 4 years Linux distros will "have to" (?) migrate to python3.

Currently new Debian packages written in Python 2 should be refused:

https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html

Ciao,
Carlo

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

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

Noeck
And I was not up-to-date in a previous mail: Python 3 is already the
default in the latest Ubuntu release.

Joram

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

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

m.tarenskeen


On Sat, 23 Apr 2016, Noeck wrote:

> And I was not up-to-date in a previous mail: Python 3 is already the
> default in the latest Ubuntu release.

Fedora:

https://fedoraproject.org/wiki/Changes/Python_3_as_Default

--

MT

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
In reply to this post by Noeck
Noeck <[hidden email]> writes:

> And I was not up-to-date in a previous mail: Python 3 is already the
> default in the latest Ubuntu release.

How do you figure that?  I have an up-to-date Ubuntu and calling "python
--version" gives 2.7.11+.

--
David Kastrup

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

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

Noeck

>> Python 3 is already the default in the latest Ubuntu release.
>
> How do you figure that?  I have an up-to-date Ubuntu and calling "python
> --version" gives 2.7.11+.

By default, I mean what is installed by default/ships with the default
installation [1]. /usr/bin/python will point to python2 for some longer
time as PEP394 [2] requests. And Ubuntu plans to follow that
recommendation [3].

[1]: https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#Python_3
[2]: http://legacy.python.org/dev/peps/pep-0394/
[3]: https://wiki.ubuntu.com/Python/3

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
Noeck <[hidden email]> writes:

>>> Python 3 is already the default in the latest Ubuntu release.
>>
>> How do you figure that?  I have an up-to-date Ubuntu and calling "python
>> --version" gives 2.7.11+.
>
> By default, I mean what is installed by default/ships with the default
> installation [1]. /usr/bin/python will point to python2 for some longer
> time as PEP394 [2] requests. And Ubuntu plans to follow that
> recommendation [3].

So how do you define "the default" when /usr/bin/python is Python2?  And
when the package "python" lists as

dak@lola:/usr/local/tmp/lilypond$ dpkg -l python
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                          Version                     Architecture                Description
+++-=============================================-===========================-===========================-===============================================================================================
ii  python                                        2.7.11-1                    i386                        interactive high-level object-oriented language (default version)

--
David Kastrup

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

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

Noeck
> So how do you define "the default"

As written before: What ships with the default installation.

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

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

Thomas Morley-2
In reply to this post by Andrew Bernard
2016-04-23 11:35 GMT+02:00 Andrew Bernard <[hidden email]>:

> 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.
>
> Andrew
>
>
>
>
>
> On 23/04/2016, 6:33 PM, "David Kastrup" <[hidden email]> 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.


As a side-note, midi2ly needs our shipped python-version. It stopps
working even with my system-python, i.e. 2.7.9.
Not sure, whether this requires a bugreport, because there is no bug
with lily's python...

Cheers,
  Harm

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
In reply to this post by Noeck
Noeck <[hidden email]> writes:

>> So how do you define "the default"
>
> As written before: What ships with the default installation.

So python3 needs to be invoked using #!/usr/bin/python3 in the scripts
(what happens when Python 4 gets created), and we need to either support
Python2 and Python3 in parallel (including from GUB) _or_ make a hard
switch where we change _every_ script to use Python3 _and_ change GUB
from one version to the next.

_And_ Wols insists that he does _not_ want to use a common subset of
Python2 and Python3 even temporarily but do this right away using
Python3-only features.

Now having a separate prescribed #!/usr/bin/python3 shebang may seem to
make testing half-way reliable.  But in reality, the LilyPond code base
does not contain #!/usr/bin/python to any sizable degree (there is a
single script which might be an oversight) but instead #!@TARGET_PYTHON@
so again, there does not seem to be much of an alternative for an
all-or-nothing approach, and trying to mix this with making use of new
language features at the same time seems like a logistic nightmare.

--
David Kastrup

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

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

Urs Liska
Am 24.04.2016 um 09:56 schrieb David Kastrup:

> Noeck <[hidden email]> writes:
>
>>> So how do you define "the default"
>>
>> As written before: What ships with the default installation.
>
> So python3 needs to be invoked using #!/usr/bin/python3 in the scripts
> (what happens when Python 4 gets created), and we need to either support
> Python2 and Python3 in parallel (including from GUB) _or_ make a hard
> switch where we change _every_ script to use Python3 _and_ change GUB
> from one version to the next.
>
> _And_ Wols insists that he does _not_ want to use a common subset of
> Python2 and Python3 even temporarily but do this right away using
> Python3-only features.
>
> Now having a separate prescribed #!/usr/bin/python3 shebang may seem to
> make testing half-way reliable.  But in reality, the LilyPond code base
> does not contain #!/usr/bin/python to any sizable degree (there is a
> single script which might be an oversight) but instead #!@TARGET_PYTHON@
> so again, there does not seem to be much of an alternative for an
> all-or-nothing approach, and trying to mix this with making use of new
> language features at the same time seems like a logistic nightmare.
>

OK, but what happens when we face the situation that some distros have
#!/usr/bin/python to Python 2 and other to Python 3?
This is something we can't control at all, so at latest *then* we'd be
in that situation, with the difference that *now* we have at least a
chance to control the transition.

I think this is about what Federico meant with this Guile 1.8/2
comparison - he didn't mean to say that we are in that situation *now*
but that we might run into it when the decisions of the distros are taken.

Urs

--
Urs Liska
www.openlilylib.org

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
In reply to this post by Thomas Morley-2
Thomas Morley <[hidden email]> writes:

> 2016-04-23 11:35 GMT+02:00 Andrew Bernard <[hidden email]>:
>> 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.
>>
>> Andrew
>>
>>
>>
>>
>>
>> On 23/04/2016, 6:33 PM, "David Kastrup" <[hidden email]> 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.
>
>
> As a side-note, midi2ly needs our shipped python-version. It stopps
> working even with my system-python, i.e. 2.7.9.
> Not sure, whether this requires a bugreport, because there is no bug
> with lily's python...

In my opinion it does.  At least unless the problem consists in missing
libraries.  Then it may need mentioning in the dependencies (unless
already listed there), and it may be worth checking that system
packagings of LilyPond also have the requisite dependencies.

But if there is a bona-fide language version problem with midi2ly, of
course it's a bug.  Our prepackaged binaries are a service and
convenience for LilyPond users, but "the" LilyPond is just the source
code.

--
David Kastrup

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

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

Federico Bruni-2
In reply to this post by Thomas Morley-2
On Sun, Apr 24, 2016 at 09:44:33AM +0200, Thomas Morley wrote:
>
> As a side-note, midi2ly needs our shipped python-version. It stopps
> working even with my system-python, i.e. 2.7.9.
> Not sure, whether this requires a bugreport, because there is no bug
> with lily's python...
>

I will add a comment to the first of these two issues (and mark the second as duplicate):
https://sourceforge.net/p/testlilyissues/issues/1895/
https://sourceforge.net/p/testlilyissues/issues/1895/


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
In reply to this post by Urs Liska
Urs Liska <[hidden email]> writes:

> Am 24.04.2016 um 09:56 schrieb David Kastrup:
>> Noeck <[hidden email]> writes:
>>
>>>> So how do you define "the default"
>>>
>>> As written before: What ships with the default installation.
>>
>> So python3 needs to be invoked using #!/usr/bin/python3 in the scripts
>> (what happens when Python 4 gets created), and we need to either support
>> Python2 and Python3 in parallel (including from GUB) _or_ make a hard
>> switch where we change _every_ script to use Python3 _and_ change GUB
>> from one version to the next.
>>
>> _And_ Wols insists that he does _not_ want to use a common subset of
>> Python2 and Python3 even temporarily but do this right away using
>> Python3-only features.
>>
>> Now having a separate prescribed #!/usr/bin/python3 shebang may seem to
>> make testing half-way reliable.  But in reality, the LilyPond code base
>> does not contain #!/usr/bin/python to any sizable degree (there is a
>> single script which might be an oversight) but instead #!@TARGET_PYTHON@
>> so again, there does not seem to be much of an alternative for an
>> all-or-nothing approach, and trying to mix this with making use of new
>> language features at the same time seems like a logistic nightmare.
>>
>
> OK, but what happens when we face the situation that some distros have
> #!/usr/bin/python to Python 2 and other to Python 3?
> This is something we can't control at all, so at latest *then* we'd be
> in that situation, with the difference that *now* we have at least a
> chance to control the transition.
>
> I think this is about what Federico meant with this Guile 1.8/2
> comparison - he didn't mean to say that we are in that situation *now*
> but that we might run into it when the decisions of the distros are taken.

Our scripts run with either Guile-1.8 or Guile-2.0 as far as I can tell.
Which is sort-of a soft transition.  It's just core LilyPond which has
not yet been ported over to the Guile-2 kernel and linkable libraries.

But we have statements here to the effect that those interested in the
porting are not interested in using a common subset for the Python3
effort (which we won't likely be able to put off forever).  I am
pointing out the consequences of such an approach.  It will cause a
whole lot of work and fallout, and it's not at all clear to me that the
bulk of those consequences will rest on the shoulders of those who want
to have it done in that manner.

And I haven't seen _any_ compelling argument yet _why_ there is no
useful common ground between Python2 and Python3 that could do the job
without major rewrites of the current code base.

--
David Kastrup

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

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

m.tarenskeen
Has anyone considered using the six library? Six has helped me a lot in my own Python projects to write code that is compatible with both python2 and python3.

MT


-------- Oorspronkelijk bericht --------
Onderwerp: Re: Python 3, was Re: ANN: Frescobaldi 2.19.0
Van: David Kastrup
Aan: Urs Liska
Cc: [hidden email]


Urs Liska writes:

> Am 24.04.2016 um 09:56 schrieb David Kastrup:
>> Noeck writes:
>>
>>>> So how do you define "the default"
>>>
>>> As written before: What ships with the default installation.
>>
>> So python3 needs to be invoked using #!/usr/bin/python3 in the scripts
>> (what happens when Python 4 gets created), and we need to either support
>> Python2 and Python3 in parallel (including from GUB) _or_ make a hard
>> switch where we change _every_ script to use Python3 _and_ change GUB
>> from one version to the next.
>>
>> _And_ Wols insists that he does _not_ want to use a common subset of
>> Python2 and Python3 even temporarily but do this right away using
>> Python3-only features.
>>
>> Now having a separate prescribed #!/usr/bin/python3 shebang may seem to
>> make testing half-way reliable. But in reality, the LilyPond code base
>> does not contain #!/usr/bin/python to any sizable degree (there is a
>> single script which might be an oversight) but instead #!@TARGET_PYTHON@
>> so again, there does not seem to be much of an alternative for an
>> all-or-nothing approach, and trying to mix this with making use of new
>> language features at the same time seems like a logistic nightmare.
>>
>
> OK, but what happens when we face the situation that some distros have
> #!/usr/bin/python to Python 2 and other to Python 3?
> This is something we can't control at all, so at latest *then* we'd be
> in that situation, with the difference that *now* we have at least a
> chance to control the transition.
>
> I think this is about what Federico meant with this Guile 1.8/2
> comparison - he didn't mean to say that we are in that situation *now*
> but that we might run into it when the decisions of the distros are taken.

Our scripts run with either Guile-1.8 or Guile-2.0 as far as I can tell.
Which is sort-of a soft transition. It's just core LilyPond which has
not yet been ported over to the Guile-2 kernel and linkable libraries.

But we have statements here to the effect that those interested in the
porting are not interested in using a common subset for the Python3
effort (which we won't likely be able to put off forever). I am
pointing out the consequences of such an approach. It will cause a
whole lot of work and fallout, and it's not at all clear to me that the
bulk of those consequences will rest on the shoulders of those who want
to have it done in that manner.

And I haven't seen _any_ compelling argument yet _why_ there is no
useful common ground between Python2 and Python3 that could do the job
without major rewrites of the current code base.

--
David Kastrup

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
12