https://codereview.appspot.com/555260044/diff/567150044/scripts/convert-ly.py
File scripts/convert-ly.py (right):
https://codereview.appspot.com/555260044/diff/567150044/scripts/convert-ly.py#newcode361
scripts/convert-ly.py:361: f = f
On 2020/02/04 19:45:33, dak wrote:
> That line looks spuriou
https://codereview.appspot.com/555260044/diff/567150044/scripts/convert-ly.py
File scripts/convert-ly.py (right):
https://codereview.appspot.com/555260044/diff/567150044/scripts/convert-ly.py#newcode361
scripts/convert-ly.py:361: f = f
That line looks spurious. Any reason for keeping it in?
ht
Reviewers: dak,
Message:
On 2020/02/04 19:32:10, dak wrote:
> Foreseeable consequences for Python 2.7?
None, because the minimum version is Python 3.5
Description:
Fix convert-ly with Python 3
The error was "'str' object has no attribute 'decode'", so it alrea
Foreseeable consequences for Python 2.7?
https://codereview.appspot.com/555260044/
Jonas Hahnfeld writes:
> Am Sonntag, den 26.01.2020, 17:30 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> hah...@hahnjo.de
>> > writes:
>>
>> > Am Sonntag, den 26.01.2020, 16:25 +0100 schrieb David Kastrup:
>> > > > OK. So what is your proposal for how to proceed with Jonas' patch?
>> > >
Am Sonntag, den 26.01.2020, 17:30 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> hah...@hahnjo.de
> > writes:
>
> > Am Sonntag, den 26.01.2020, 16:25 +0100 schrieb David Kastrup:
> > > > OK. So what is your proposal for how to proceed with Jonas' patch?
> > >
> > > Different possibilities. Pr
Jonas Hahnfeld writes:
> Am Sonntag, den 26.01.2020, 16:25 +0100 schrieb David Kastrup:
>>
>> > OK. So what is your proposal for how to proceed with Jonas' patch?
>>
>> Different possibilities. Probably easiest is to have different GUB
>> setups for LilyPond-2.20 and LilyPond-2.22. Then we can
Am Sonntag, den 26.01.2020, 16:25 +0100 schrieb David Kastrup:
> Han-Wen Nienhuys <
> hanw...@gmail.com
> > writes:
>
> > On Sun, Jan 26, 2020 at 3:33 PM David Kastrup <
> > d...@gnu.org
> > > wrote:
> > > > > What David is concerned about (as far as I understand) is that we need
> > > > > to modi
Han-Wen Nienhuys writes:
> On Sun, Jan 26, 2020 at 3:33 PM David Kastrup wrote:
>> >> What David is concerned about (as far as I understand) is that we need
>> >> to modify the spec for LilyPond to require the new python3 package as a
>> >> dependency. This will (obviously) not work for packagin
On Sun, Jan 26, 2020 at 3:33 PM David Kastrup wrote:
> >> What David is concerned about (as far as I understand) is that we need
> >> to modify the spec for LilyPond to require the new python3 package as a
> >> dependency. This will (obviously) not work for packaging 2.20.
> >
> > Fair enough, but
o make this explicit: The proposal is to drop support for Python 2
>> > > > (now EOL), requiring everyone wishing to build LilyPond 'master' to
>> > > > have an appropriate version of Python 3 available. This should be
>> > > > sufficiently easy
rop support for Python 2
> > > > (now EOL), requiring everyone wishing to build LilyPond 'master' to
> > > > have an appropriate version of Python 3 available. This should be
> > > > sufficiently easy (see above), but I'd like to have consens
Am Sonntag, den 26.01.2020, 14:53 +0100 schrieb Han-Wen Nienhuys:
> On Mon, Jan 6, 2020 at 8:21 PM David Kastrup <
> d...@gnu.org
> > wrote:
> > > > 1) Adapt the build system to find and require Python 3.
> > > > patch:
> > > > https://coderevie
On Mon, Jan 6, 2020 at 8:21 PM David Kastrup wrote:
> >> 1) Adapt the build system to find and require Python 3.
> >> patch:
> >> https://codereview.appspot.com/545370043
> >>
> >> 2) The largest part of the switch is running 2to3 which is now a
Am Montag, den 06.01.2020, 19:12 +0100 schrieb Jonas Hahnfeld:
> Am Donnerstag, den 19.12.2019, 20:13 +0100 schrieb Jonas Hahnfeld:
> > Hello friends of Python 3!
> >
> > to make the initial proposal short: With today's patches, I think
> > 'master' w
Reviewers: lemzwerg,
Message:
Closing as the change got smaller and smaller as I discovered more edge
cases where the current code matters with Python 2.x
Description:
Encoding changes for Python 3
This is required to eventually make the scripts work with Python 3.
The change happens to also
Am Montag, den 06.01.2020, 19:44 +0100 schrieb Jonas Hahnfeld:
> Am Montag, den 06.01.2020, 19:32 +0100 schrieb David Kastrup:
> > Jonas Hahnfeld <
> > hah...@hahnjo.de
> >
> > > writes:
> > > Am Donnerstag, den 19.12.2019, 20:13 +0100 schrieb Jonas H
Jonas Hahnfeld writes:
> Am Donnerstag, den 19.12.2019, 20:13 +0100 schrieb Jonas Hahnfeld:
>> Hello friends of Python 3!
>>
>> to make the initial proposal short: With today's patches, I think
>> 'master' would be ready to switch over to Python 3.x.
Am Montag, den 06.01.2020, 19:32 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> hah...@hahnjo.de
> > writes:
>
> > Am Donnerstag, den 19.12.2019, 20:13 +0100 schrieb Jonas Hahnfeld:
> > > Hello friends of Python 3!
> > >
> > > to make the in
Am Donnerstag, den 19.12.2019, 20:13 +0100 schrieb Jonas Hahnfeld:
> Hello friends of Python 3!
>
> to make the initial proposal short: With today's patches, I think
> 'master' would be ready to switch over to Python 3.x.
> As a reminder, Python 2 will go EOL on 1s
As I said on the mailing list multiple times, it's actually
a ton of work to make the scripts work with Python 2 _and_
Python 3 at the same time. [...]
I've forgotten that you've already added Python 3.x support to gub, so I
withdraw my comments :-)
https://codereview.appspot.com/545370043/
Reviewers: lemzwerg,
Message:
On 2019/12/20 00:12:25, lemzwerg wrote:
Mhmm, I'm not happy with that. What I can imagine is to *prefer*
Python 3.x
over 2.x.
Is there a reason to enforce 3.x? I thought that all of your recent
work was to
ensure that the scripts work both with 2.x an
Mhmm, I'm not happy with that. What I can imagine is to *prefer* Python
3.x over 2.x.
Is there a reason to enforce 3.x? I thought that all of your recent
work was to ensure that the scripts work both with 2.x and 3.x – am I
missing something?
https://codereview.appspot.com/545370043/
LGTM
https://codereview.appspot.com/571280043/
Hello friends of Python 3!
to make the initial proposal short: With today's patches, I think
'master' would be ready to switch over to Python 3.x.
As a reminder, Python 2 will go EOL on 1st of January 2020 - in 13 days
if I counted correctly. That probably doesn't mean tha
On 2019/11/25 02:44:20, Dan Eble wrote:
On 2019/11/24 11:47:01, hahnjo wrote:
> On 2019/11/23 16:45:17, Dan Eble wrote:
> > If an XML file is opened as a binary file, will the treatment of
> > platform-specific line endings become inconvenient for some
people?
>
> I hope it does not: Once we kn
On 2019/11/24 11:47:01, hahnjo wrote:
On 2019/11/23 16:45:17, Dan Eble wrote:
> If an XML file is opened as a binary file, will the treatment of
> platform-specific line endings become inconvenient for some people?
I hope it does not: Once we know it's really text, the code will call
decode('u
k +
doc.
Description:
Prepare for encoding changes in Python 3
This is most of the remaining diff for porting to Python 3,
but this also works in Python 2.4 already (even though not
strictly needed).
Individual changes:
1. Encode strings before hashing
Python 3 requires "bytes-like objects".
3. Open midi and musicxml files in binary mode
Only decode once we are sure that the content is not compressed.
If an XML file is opened as a binary file, will the treatment of
platform-specific line endings become inconvenient for some people?
https://codereview.appspot.com/573280043/
LGTM, thanks!
https://codereview.appspot.com/573280043/
On Sep 30, 2019, at 19:46, Matthew Peveler wrote:
>
> I've been maintaining my work in
> https://github.com/MasterOdin/lilypond/tree/py3_future2
> . . .
> … 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 t
On Mon, Sep 30, 2019 at 7:08 PM Dan Eble 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.)
>
On Sep 30, 2019, at 17:05, Matthew Peveler wrote:
>
> Please see attached for [ten] patches, which given the work done prior by
> Jonas, allows for running the various make targets under both python2&3
> (assuming application of my other two patches for py3)
The thought that gave rise to my qu
> This does assume however that GUB is updated to at least target at
> least Python 2.6 (for __future__.print_function).
GUB already contains python 2.6 support. However, lilypond isn't set
up to use it. This should be rather simple to do, I think. However,
I haven't gub used since months and
On Mon, Sep 30, 2019 at 5:46 PM Joram wrote:
> Am 27.09.19 um 22:34 schrieb Matthew Peveler:
> > long vs int, unicode vs str, StringIO vs io, iter.next vs
> > iter.__next__, reload, xrange vs range.
>
> It is very well feasible to support both version. I hope by shims you
> mean something like¹
>
are done, will the
> current makefiles continue to work in environments with Python 2, but
> require updates to work in environments with Python 3?
>
> Regards,
> —
> Dan
Please see attached for the patches, which given the work done prior by
Jonas, allows for running the vario
Am 27.09.19 um 22:34 schrieb Matthew Peveler:
> long vs int, unicode vs str, StringIO vs io, iter.next vs
> iter.__next__, reload, xrange vs range.
It is very well feasible to support both version. I hope by shims you
mean something like¹
from __future__ import division, print_function
fr
r py changes are done, will the current makefiles
continue to work in environments with Python 2, but require updates to work in
environments with Python 3?
Regards,
—
Dan
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
h just a handful of shims around the changes you
>> noted in long vs int, unicode vs str, StringIO vs io, iter.next vs
>> iter.__next__, reload, xrange vs range.
>
> Are these complications desirable? A clean and obvious implementation
> requiring Python 3 will be easier to maintain
s you
> noted in long vs int, unicode vs str, StringIO vs io, iter.next vs
> iter.__next__, reload, xrange vs range.
Are these complications desirable? A clean and obvious implementation
requiring Python 3 will be easier to maintain.
—
Dan
___
> 1. Python 2 old style classes had a default __cmp__ which would compare
> the id() of the classes, and used implicitly for sort. Python 3 removed
> this, but need to define a __lt__ method for sort compat.
> > 2. attempting to open midi files as str files, though they are filled
> wi
h Python 3.7.4.
>
> In applying your patches and running "make check", I encountered a couple of
> errors in scripts/build/output-distance.py, which would be summed up as:
>
> 1. Python 2 old style classes had a default __cmp__ which would compare the
> id() of the clas
On Mon, Sep 23, 2019 at 12:26 PM Matthew Peveler
wrote:
> Please see the attached for small patches for these two things, and got
"make check" to run for me using Python 3.7.4 as well.
Hm, not sure why the patch files got converted to binary when sending,
though I've also made them available at
ht
quot;make check", I encountered a couple
of errors in scripts/build/output-distance.py, which would be summed up as:
1. Python 2 old style classes had a default __cmp__ which would compare the
id() of the classes, and used implicitly for sort. Python 3 removed this,
but need to define a __lt__ m
Hello,
On 21/09/2019 17:57, Werner LEMBERG wrote:
[...] I've split the third patch ("Fix musicxml2ly with Python 3")
into four smaller logical groups. I don't really mind which version
is applied, the outcome is the same.
LGTM, t
> [...] I've split the third patch ("Fix musicxml2ly with Python 3")
> into four smaller logical groups. I don't really mind which version
> is applied, the outcome is the same.
LGTM, thanks.
Werner
___
lilypond-deve
g any benefit on its own. So for example only
>
> > changing the division operator will not make musicxml2ly work with
>
> > Python 3.
>
>
> In case there are patches within a series of patches that don't
> compile, please say that in the commit message for the benefi
>> Well, I prefer a series of patches instead of a single patch.
>
> Ok, I'll split the third one. My concern was that a single part of
> the series won't bring any benefit on its own. So for example only
> changing the division operator will not make musicxml2ly wo
if that is
>>
>> > really helpful here because none of these changes will do anything
>>
>> > on its own.
>>
>>
>> What do you mean with `none will do anything on its own'?
>>
>> > So my question is whether the patch is too la
ese changes will do anything
>
> > on its own.
>
>
> What do you mean with `none will do anything on its own'?
>
> > So my question is whether the patch is too large to go as one "fix
>
> > that script for Python 3"?
>
>
> Well, I prefer
27;?
> So my question is whether the patch is too large to go as one "fix
> that script for Python 3"?
Well, I prefer a series of patches instead of a single patch.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
> If I remember correctly, this will be the time that we definitely
> have to retire the PowerPC MacOSX version (it's not clear anybody is
> actually using it, though).
Hmm. Looking into MacPorts, I don't see any restriction for using
python 3.7 on PowerPC. It seems that OS X 10.4 and 10.5 are
Jonas Hahnfeld writes:
> Am Samstag, den 21.09.2019, 11:25 +0200 schrieb David Kastrup:
>
>> 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. T
> > 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.
> > >
> >
nd
>
> decode('utf-8')
>
> could be two patches.
>
> `git add -p' is your friend to do that conveniently.
Sure, that is the usual suggestion. But I'm not sure if that is really
helpful here because none of these changes will do anything on its own.
So m
rking 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 can
>> 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?
Yes, definitely.
> I've also started looking into this and used the branch
> dev/knupero/lilypy3devel as a starting point (see also
>
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
nd as well as Ubuntu use Python 2 by default. So
> it is to be expected that Python 3 operation has not seen thorough
> testing at this point of time.
>
> Making a list of problems and cutting&pasting the respective error
> messages occuring under which calls/circumstances wou
rences in your
setup.
Without more details, it is hard to tell. The default build
environments of LilyPond as well as Ubuntu use Python 2 by default. So
it is to be expected that Python 3 operation has not seen thorough
testing at this point of time.
Making a list of problems and cutting&p
know how this works (not done much open source
>> contributing), but I’m Charlotte, a CS student and I’m working on my
>> dissertation which incorporates Lilypond for the typesetting portion.
>>
>> Anyway, I updated my mac at the start of this project to python 3, and
>>
at the start of this project to python 3, and
> I tried running lilypond-book on one of my reports and found a bunch
> of issues with python 3, mostly just syntax changes/methods that have
> been deprecated.
>
> I was wondering if anyone had fixed this yet/if it’s an issue/fixed in
>
Hi!
I don’t really know how this works (not done much open source contributing),
but I’m Charlotte, a CS student and I’m working on my dissertation which
incorporates Lilypond for the typesetting portion.
Anyway, I updated my mac at the start of this project to python 3, and I tried
running
"Phil Holmes" writes:
> - Original Message -
> From: "David Kastrup"
> To: "Julien Rioux"
> Cc: "LilyPond Devel"
> Sent: Tuesday, March 18, 2014 2:39 PM
> Subject: Re: Python 3 support
>
>> Sure. I am not involve
- Original Message -
From: "David Kastrup"
To: "Julien Rioux"
Cc: "LilyPond Devel"
Sent: Tuesday, March 18, 2014 2:39 PM
Subject: Re: Python 3 support
Sure. I am not involved with GUB or the GitHub repos. So the question
what to use for LilyPo
On Tue, Mar 18, 2014 at 4:43 PM, Jeremiah Benham wrote:
> I have forked gub and have been working on it for a while now.
>
> https://github.com/jjbenham/gub
>
> It is very different now from https://github.com/gperciva/gub and the
> main master. I don't know how to contribute changes unless via p
I have forked gub and have been working on it for a while now.
https://github.com/jjbenham/gub
It is very different now from https://github.com/gperciva/gub and the main
master. I don't know how to contribute changes unless via per file basis.
Then each patch would need to be tested. I have added
Julien Rioux writes:
> On Tue, Mar 18, 2014 at 12:44 PM, David Kastrup wrote:
>
>>
>> That's not quite the same as "we already have hosting, a platform for
>> contribution and review comments". Everything beyond the content in
>> private repositories is gone if a project is removed. And "we ha
On Tue, Mar 18, 2014 at 12:44 PM, David Kastrup wrote:
>
> That's not quite the same as "we already have hosting, a platform for
> contribution and review comments". Everything beyond the content in
> private repositories is gone if a project is removed. And "we have" is
> a bit of a euphemism
Julien Rioux writes:
> On Tue, Mar 18, 2014 at 10:39 AM, David Kastrup wrote:
>
>> Julien Rioux writes:
>>
>> > The current hosting situation isn't bad that we need to take such
>> > important actions with savannah. With github, we already have hosting,
>> > a platform for contribution and revi
On Tue, Mar 18, 2014 at 10:39 AM, David Kastrup wrote:
> Julien Rioux writes:
>
> > The current hosting situation isn't bad that we need to take such
> > important actions with savannah. With github, we already have hosting,
> > a platform for contribution and review comments, and relatively str
Julien Rioux writes:
> If you are keen on it, why not? Not sure if it's worth the trouble,
> though: Maybe more visibility would bring GUB more workers, and in
> that vein endorsement by a big player would be a boost. Unfortunately,
> I'm not sure GUB has a strong significance anymore. With no
>
build current dev and stable branches of lilypond from
> > it. Then bump the python requirement in the dev branch and start
> > migrating to a codebase that supports python 2.6+ and python 3+
>
> Sounds great! Thanks for working on this.
>
>
When would be a good timing to do t
On Tue, Mar 18, 2014 at 6:24 AM, David Kastrup wrote:
> Julien Rioux writes:
>
> > (BTW moving GUB to a user-agnostic home such as
> > https://github.com/lilypond
>
> > would make sense to avoid such confusion. After Jan went mostly
> > inactive, Graham took over as the "official" home, but he
Julien Rioux writes:
> On Tue, Mar 18, 2014 at 3:33 AM, David Kastrup wrote:
>
>> I was of the opinion that GUB already uses Python 2.6?
>>
>>
> GUB master at https://github.com/gperciva/gub (the current "official" home)
> definitely does not use python 2.6. It ships python 2.4.5
Oh. I thought
On Tue, Mar 18, 2014 at 3:33 AM, David Kastrup wrote:
> I was of the opinion that GUB already uses Python 2.6?
>
>
GUB master at https://github.com/gperciva/gub (the current "official" home)
definitely does not use python 2.6. It ships python 2.4.5
If you are using GUB master at https://github.c
ches of lilypond from
>> it. Then bump the python requirement in the dev branch and start
>> migrating to a codebase that supports python 2.6+ and python 3+
>
> Sounds great! Thanks for working on this.
I was of the opinion that GUB alre
p the python requirement in the dev branch and start
> migrating to a codebase that supports python 2.6+ and python 3+
Sounds great! Thanks for working on this.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/m
the dev branch and start migrating to a codebase
that supports python 2.6+ and python 3+
Thoughts? Objections?
Regards,
Julien
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Fri, Oct 22, 2010 at 10:21:58PM +0200, Matthias Kilian wrote:
> On Tue, Oct 19, 2010 at 12:07:29AM +0100, Graham Percival wrote:
> > Anything that's used to build the website (as opposed to the html
> > version of the docs) cannot rely on configure. This affects
> > scripts/build/ create-*.py w
On Tue, Oct 19, 2010 at 12:07:29AM +0100, Graham Percival wrote:
> >> python/ yes, since it's not something that people call manually.
> >> But stuff in scripts/build/ shouldn't have @PYTHON@, otherwise
> >> it'll bork if you call it manually.
> >
> > But are those scripts supposed to be used witho
On Tue, Oct 19, 2010 at 8:02 AM, John Mandereau
wrote:
> Il giorno lun, 18/10/2010 alle 09.20 -0700, Patrick McCarty ha scritto:
>> On Mon, Oct 18, 2010 at 9:17 AM, John Mandereau
>> wrote:
>> > I don't understand the issue; can't you just set PYTHON=python2 when
>> > calling configure, and in ca
Il giorno lun, 18/10/2010 alle 09.20 -0700, Patrick McCarty ha scritto:
> On Mon, Oct 18, 2010 at 9:17 AM, John Mandereau
> wrote:
> > I don't understand the issue; can't you just set PYTHON=python2 when
> > calling configure, and in case you need some scripts in auxiliar call
> > them by prependi
(unlurking, i didn't spend much time on lilypond recently)
On Mon, Oct 18, 2010 at 01:59:15AM +0100, Graham Percival wrote:
> > --) Two scripts still have "/usr/bin/python" lines
> > (python/auxiliar/manuals_definitions.py, and scripts/build/pytt.py).
> > Those should be changed to "@PYTHON@", rig
On Mon, Oct 18, 2010 at 11:57 PM, Matthias Kilian
wrote:
> (unlurking, i didn't spend much time on lilypond recently)
>
>> python/ yes, since it's not something that people call manually.
>> But stuff in scripts/build/ shouldn't have @PYTHON@, otherwise
>> it'll bork if you call it manually.
>
> B
On Mon, Oct 18, 2010 at 9:17 AM, John Mandereau
wrote:
> Il giorno lun, 18/10/2010 alle 09.02 -0700, Patrick McCarty ha scritto:
>> Yes, but unfortunately, LilyPond needs special sed treatment, since
>> many substitutions are made *after* configure time. I will need to
>> file a bug report...
>>
Il giorno lun, 18/10/2010 alle 09.02 -0700, Patrick McCarty ha scritto:
> Yes, but unfortunately, LilyPond needs special sed treatment, since
> many substitutions are made *after* configure time. I will need to
> file a bug report...
>
> Specifically, I am looking for a way to make life easier wh
On Sun, Oct 17, 2010 at 5:59 PM, Graham Percival
wrote:
> On Sun, Oct 17, 2010 at 05:38:20PM -0700, Patrick McCarty wrote:
>> --) Two scripts still have "/usr/bin/python" lines
>> (python/auxiliar/manuals_definitions.py, and scripts/build/pytt.py).
>> Those should be changed to "@PYTHON@", right?
pointing at python binary
> (lilypond appears in this list)
>
> Packages which have "/usr/bin/python" or "/usr/bin/env
> python" in their files and will need to change to python2 if
> not already compatible with python-3.x. Note that some of
> these are fixed
On Mon, Oct 18, 2010 at 2:50 AM, Valentin Villenave
wrote:
> On Mon, Oct 18, 2010 at 2:38 AM, Patrick McCarty wrote:
>> Arch Linux will be migrating to Python 3 very soon, and I'm trying to
>> figure out what to do with regard to LilyPond's build system. I don'
On Mon, Oct 18, 2010 at 2:38 AM, Patrick McCarty wrote:
> Arch Linux will be migrating to Python 3 very soon, and I'm trying to
> figure out what to do with regard to LilyPond's build system. I don't
> know if Arch Linux is the first distribution upgrading to Python 3,
&
/usr/bin/env
python" in their files and will need to change to python2 if
not already compatible with python-3.x. Note that some of
these are fixed by just building against a python2 binary,
while others require some sed magic...
- Mark
__
On Sun, Oct 17, 2010 at 8:30 PM, Benjamin Peterson wrote:
> Patrick McCarty gmail.com> writes:
>>
>> Arch Linux will be migrating to Python 3 very soon,
>
> What does this mean? "$ python" will give Python 3?
Yes.
> If so, that's no good. "pyth
Benjamin Peterson python.org> writes:
> time in memoriam.
Hmm, that is a curious think-o. I meant "time immemorial" of course.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Patrick McCarty gmail.com> writes:
>
> Hello,
>
> Arch Linux will be migrating to Python 3 very soon,
What does this mean? "$ python" will give Python 3?
If so, that's no good. "python3" is supposed to be the name of the Python 3
executable for time
ubuntu packagers, or
something like that. It will contain the perfect solution to "how
should we start our python scripts", or "how can we survive the
transition to python 3", and the like. Or if there is no perfect
solution, then at least it will outline the flaws and
Hello,
Arch Linux will be migrating to Python 3 very soon, and I'm trying to
figure out what to do with regard to LilyPond's build system. I don't
know if Arch Linux is the first distribution upgrading to Python 3,
but this migration will be happening any day now.
The distribut
97 matches
Mail list logo
