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

[David Kastrup]

Urs Liska <address@hidden> writes:

> Am 24.04.2016 um 09:56 schrieb David Kastrup:
>> Noeck <address@hidden> 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 address@hidden@
>> 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