Re: [Scons-dev] Re PR #171
On Mon, 2014-09-08 at 12:01 -0400, Neal Becker wrote: > Take a look at future package: > https://pypi.python.org/pypi/future/0.13.0 I wonder if we should ditch the current python3 branch despite all the great work done with it and start again from current default/tip using the above extension to the idea of __future__ and ignoring the 2to3 and six stuff? As Anatoly has said applying 2to3 is a way of moving a 2 codebase to a 3 codebase not supporting a single codebase with 2.7 and 3.3+. The crucial thing here though is to explicit not support 2.5 and earlier (no problem) and 3.[012] (no problem now since anyone using these is shooting themselves in the foot :-). -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Re PR #171
anatoly techtonik wrote: > On Mon, Sep 8, 2014 at 12:56 PM, Gary Oberbrunner > wrote: >> On Mon, Sep 8, 2014 at 4:16 AM, anatoly techtonik >> wrote: >>> >>> On Sun, Aug 31, 2014 at 8:54 PM, Gary Oberbrunner >>> wrote: >>> > On Sun, Aug 31, 2014 at 1:42 PM, Russel Winder >>> > wrote: >>> >> >>> >> The whole ASCII string / Unicode codepoint sequence thing brings the >>> >> Python 2/Python 3 thing to a head. If we want a codebase that runs >>> >> under >>> >> both Python 2 and Python 3 then we almost certainly have to use six to >>> >> provide the indirection layer for things like strings (unless we write >>> >> our own). Alternatively the Python 3 codebase can be separate (which is >>> >> what Anatoly was advocating if I remember correctly) and then do >>> >> careful >>> >> cherry picks from the Python 2 codebase. >>> > >>> > six.py is now included in the python3 branch. At this point not >>> > everything >>> > works (still a long way from it) but I see no showstopping issues that >>> > have >>> > cropped up yet. (By showstopping I mean something that would prevent >>> > shipping a single codebase that works in 2.7 and 3.x.) >>> >>> With new workflow can you rebase Python 3 changes on top of current >>> HEAD so that it becomes a single lineage of commits and make them >>> drafts? >> >> So far I have just merged the default branch into python3 periodically >> rather >> than rebasing it onto default, which would change the commit IDs. This >> seems OK so far. > > I doubt that it is possible to do a good review of the ported code, but it > will at least make it more suitable for review. In ideal world there should be > incremental enhancements so that the final Python 3 merge won't end up > with FUBAR. > >>> This way everybody can see what it takes to go Python 3 step by >>> step. (Too bad there are no hostings that support Evolve extension yet). >>> >>> Have also tried https://github.com/python-modernize/python-modernize ? >> >> The python3 branch already has had 2to3 run on it, as the very first step I >> believe. >> What does python-modernize add? It says it's a very thin shim around 2to3. > > 2to3 makes code incompatible with Python 2. > > With modernize it is possible to go one fixer at a time and bisect errors > later. Take a look at future package: https://pypi.python.org/pypi/future/0.13.0 -- -- Those who don't understand recursion are doomed to repeat it ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Re PR #171
On Mon, Sep 8, 2014 at 7:03 AM, anatoly techtonik wrote: > > Yesterday I wasted about 4 hours debugging issues with Python 3 listed as: > http://bugs.python.org/issue20731 > http://bugs.python.org/issue20844 > and one more issue about py.ini > If they are python bugs, is there anything we can do to work around them? What OS and python version were you using? and I am not sure that I want to continue dealing with this can of worms. > OK, fine to leave it for someone else then. I only wish that all bad modifications can be back traced and reverted and > for > that they need to come in small chunks in project history, and its good > when > the branch point is based on single state during review, i.e. without > merges. That sounds like a wonderful goal. I doubt it's achievable in practice. 'hg annotate' should help with what you're asking about; yes you may have to do a few hops to get the original author but I doubt that will dominate the debugging time for any particular bug. -- Gary ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Re PR #171
On Mon, Sep 8, 2014 at 1:52 PM, Gary Oberbrunner wrote: > On Mon, Sep 8, 2014 at 6:35 AM, anatoly techtonik > wrote: >> >> 2to3 makes code incompatible with Python 2. >> >> With modernize it is possible to go one fixer at a time and bisect errors >> later. > > I believe individual fixers were applied and python2 compatibility has been > added back in a piece at a time. It's not complete but a lot of tests pass > both on python2 and python3. You can try it. Patches gratefully accepted! Yesterday I wasted about 4 hours debugging issues with Python 3 listed as: http://bugs.python.org/issue20731 http://bugs.python.org/issue20844 and one more issue about py.ini and I am not sure that I want to continue dealing with this can of worms. I only wish that all bad modifications can be back traced and reverted and for that they need to come in small chunks in project history, and its good when the branch point is based on single state during review, i.e. without merges. -- anatoly t. ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Re PR #171
On Mon, Sep 8, 2014 at 6:35 AM, anatoly techtonik wrote: > 2to3 makes code incompatible with Python 2. > > With modernize it is possible to go one fixer at a time and bisect errors > later. > I believe individual fixers were applied and python2 compatibility has been added back in a piece at a time. It's not complete but a lot of tests pass both on python2 and python3. You can try it. Patches gratefully accepted! -- Gary ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Re PR #171
On Mon, Sep 8, 2014 at 12:56 PM, Gary Oberbrunner wrote: > On Mon, Sep 8, 2014 at 4:16 AM, anatoly techtonik > wrote: >> >> On Sun, Aug 31, 2014 at 8:54 PM, Gary Oberbrunner >> wrote: >> > On Sun, Aug 31, 2014 at 1:42 PM, Russel Winder >> > wrote: >> >> >> >> The whole ASCII string / Unicode codepoint sequence thing brings the >> >> Python 2/Python 3 thing to a head. If we want a codebase that runs >> >> under >> >> both Python 2 and Python 3 then we almost certainly have to use six to >> >> provide the indirection layer for things like strings (unless we write >> >> our own). Alternatively the Python 3 codebase can be separate (which is >> >> what Anatoly was advocating if I remember correctly) and then do >> >> careful >> >> cherry picks from the Python 2 codebase. >> > >> > six.py is now included in the python3 branch. At this point not >> > everything >> > works (still a long way from it) but I see no showstopping issues that >> > have >> > cropped up yet. (By showstopping I mean something that would prevent >> > shipping a single codebase that works in 2.7 and 3.x.) >> >> With new workflow can you rebase Python 3 changes on top of current >> HEAD so that it becomes a single lineage of commits and make them >> drafts? > > So far I have just merged the default branch into python3 periodically > rather > than rebasing it onto default, which would change the commit IDs. This > seems OK so far. I doubt that it is possible to do a good review of the ported code, but it will at least make it more suitable for review. In ideal world there should be incremental enhancements so that the final Python 3 merge won't end up with FUBAR. >> This way everybody can see what it takes to go Python 3 step by >> step. (Too bad there are no hostings that support Evolve extension yet). >> >> Have also tried https://github.com/python-modernize/python-modernize ? > > The python3 branch already has had 2to3 run on it, as the very first step I > believe. > What does python-modernize add? It says it's a very thin shim around 2to3. 2to3 makes code incompatible with Python 2. With modernize it is possible to go one fixer at a time and bisect errors later. -- anatoly t. ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Re PR #171
On Mon, Sep 8, 2014 at 4:16 AM, anatoly techtonik wrote: > On Sun, Aug 31, 2014 at 8:54 PM, Gary Oberbrunner > wrote: > > On Sun, Aug 31, 2014 at 1:42 PM, Russel Winder > wrote: > >> > >> The whole ASCII string / Unicode codepoint sequence thing brings the > >> Python 2/Python 3 thing to a head. If we want a codebase that runs under > >> both Python 2 and Python 3 then we almost certainly have to use six to > >> provide the indirection layer for things like strings (unless we write > >> our own). Alternatively the Python 3 codebase can be separate (which is > >> what Anatoly was advocating if I remember correctly) and then do careful > >> cherry picks from the Python 2 codebase. > > > > six.py is now included in the python3 branch. At this point not > everything > > works (still a long way from it) but I see no showstopping issues that > have > > cropped up yet. (By showstopping I mean something that would prevent > > shipping a single codebase that works in 2.7 and 3.x.) > > With new workflow can you rebase Python 3 changes on top of current > HEAD so that it becomes a single lineage of commits and make them > drafts? So far I have just merged the default branch into python3 periodically rather than rebasing it onto default, which would change the commit IDs. This seems OK so far. > This way everybody can see what it takes to go Python 3 step by > step. (Too bad there are no hostings that support Evolve extension yet). > > Have also tried https://github.com/python-modernize/python-modernize ? > The python3 branch already has had 2to3 run on it, as the very first step I believe. What does python-modernize add? It says it's a very thin shim around 2to3. -- Gary ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Re PR #171
On Sun, Aug 31, 2014 at 8:54 PM, Gary Oberbrunner wrote: > On Sun, Aug 31, 2014 at 1:42 PM, Russel Winder wrote: >> >> The whole ASCII string / Unicode codepoint sequence thing brings the >> Python 2/Python 3 thing to a head. If we want a codebase that runs under >> both Python 2 and Python 3 then we almost certainly have to use six to >> provide the indirection layer for things like strings (unless we write >> our own). Alternatively the Python 3 codebase can be separate (which is >> what Anatoly was advocating if I remember correctly) and then do careful >> cherry picks from the Python 2 codebase. > > six.py is now included in the python3 branch. At this point not everything > works (still a long way from it) but I see no showstopping issues that have > cropped up yet. (By showstopping I mean something that would prevent > shipping a single codebase that works in 2.7 and 3.x.) With new workflow can you rebase Python 3 changes on top of current HEAD so that it becomes a single lineage of commits and make them drafts? This way everybody can see what it takes to go Python 3 step by step. (Too bad there are no hostings that support Evolve extension yet). Have also tried https://github.com/python-modernize/python-modernize ? ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Re PR #171
On Sun, Aug 31, 2014 at 1:42 PM, Russel Winder wrote: > The whole ASCII string / Unicode codepoint sequence thing brings the > Python 2/Python 3 thing to a head. If we want a codebase that runs under > both Python 2 and Python 3 then we almost certainly have to use six to > provide the indirection layer for things like strings (unless we write > our own). Alternatively the Python 3 codebase can be separate (which is > what Anatoly was advocating if I remember correctly) and then do careful > cherry picks from the Python 2 codebase. > six.py is now included in the python3 branch. At this point not everything works (still a long way from it) but I see no showstopping issues that have cropped up yet. (By showstopping I mean something that would prevent shipping a single codebase that works in 2.7 and 3.x.) > > There is also then process: I can probably spend an hour here an hour > there fixing broke tests but should these individual sessions be > separate pull requests? > Sure. On the python3 branch. If you have a bunch of related ones, I see no reason those couldn't be reviewed and merged together. -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
[Scons-dev] Re PR #171
The whole ASCII string / Unicode codepoint sequence thing brings the Python 2/Python 3 thing to a head. If we want a codebase that runs under both Python 2 and Python 3 then we almost certainly have to use six to provide the indirection layer for things like strings (unless we write our own). Alternatively the Python 3 codebase can be separate (which is what Anatoly was advocating if I remember correctly) and then do careful cherry picks from the Python 2 codebase. There is also then process: I can probably spend an hour here an hour there fixing broke tests but should these individual sessions be separate pull requests? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
