On Mon, Oct 7, 2013 at 7:47 AM, Russel Winder <[email protected]> wrote:
> On Fri, 2013-10-04 at 14:19 -0400, Gary Oberbrunner wrote: > […] > > What I've been thinking is this: > > * for now, we continue working on the python3-port branch until it > works. > > * until python3-port works, regular changes go on default as usual. > > * merge from default into python3-port as needed, to keep it current. > > * as soon as it's working (which means on both python2 and python3 all > > tests pass, and a few people say it works in their environments), we > merge > > it to default and close that branch. > > * From then on, all new changes go on default, and must support our list > > of supported pythons (2.7.2 or greater, and 3.3 or greater, right?) > > From a quick look, the python3 branch looks like Python3 only code, it > needs bringing back to be Python 2 compliant as well as Python 3 > compliant. Yes, that's correct (though much of the 2to3 stuff ought to be _basically_ python2 compliant with some massaging). > Step 1 is to put: > > from __future__ import absolute_import, division, print_function, > unicode_literals > > as the first statement in every code file and see what happens. > Perhaps that's step 2 :-); I've already started on some print changes to handle unicode/string variation, per my last email. As for absolute_import, I'm not sure that's needed; isn't it better to use relative imports? I think Neal's changes already move in that direction. As for unicode_literals, I believe (?) that as of python3.3, u'xxx' works again, so that shouldn't matter. Let me know if not. As for division, I guess we need to do that, but there's some work there to ensure we use // wherever we mean divide-and-floor (which is most of the time, in this type of code I think). > […] > > Feature branches seem to be the worst part of hg IMHO. Dirk, your > workflow > > seems OK, although a bit indirect; you could run into problems once your > > changes are accepted, pulling back in. Russel, would Dirk's setup work > for > > you? Alternatively if we used a separate repo for python3 work would > that > > be better? (Seems weird to me, even though it seems to be common practice > > in mercurial). > > Apparently bookmarks are to Mercurial what feature branches are to Git. I was going to object that bookmarks don't get pushed, but apparently now they can be: http://mercurial.selenic.com/wiki/Bookmarks/ says push -B <bookmark> pushes that bookmark and its changesets. Since most pull requests come from the default branch, bookmarks are a good idea for naming what otherwise come in as nameless heads. In the python3 case, though, would using a bookmarked head be significantly different workflow-wise (e.g. in how you maintain the D tool)? -- Gary
_______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
