On Mar 9, 2014 7:23 PM, "Ravi Kumar" <<a href="mailto:upman16@gmail.com">upman16@gmail.com</a>> wrote: > > Hello Daniel, > So Improving the unit tests before the actual porting is a must, duely noted. > If only >=3.3 is supported, all the activities HAVE to be ported to >=3.3 as well. > Don't you think supporting 2.7+ for a while will enable a smoother transition? > > I also looked at the dependencies, telepathy doesn't seem to be ported to 3.3 yet, Yay! An excuse to make the collab framework so it actually works on things other than XO! This could be interesting. > how do you think we should go about porting then? > > > > On 9 March 2014 06:02, Daniel Narvaez <<a href="mailto:dwnarvaez@gmail.com">dwnarvaez@gmail.com</a>> wrote: >> >> I think supporting multiple python versions would be too much of a burden, we are busy enough supporting three toolkits :) >> Fedora 18 seems to have 3.3 so I think it would be fine to support >= 3.3. The unit tests in place are not really thorough, we started writing them only recently. Help improving that would be certainly very welcome. >> >> On Saturday, 8 March 2014, Ravi Kumar <<a href="mailto:upman16@gmail.com">upman16@gmail.com</a>> wrote: >>> >>> Hello everyone, >>> I'm Ravi Kumar, an undergrad Computer Science and Engineering student based in Bangalore. I'm familiar with Source code management with git and proficient with Python, Ruby and C, although I haven't made any real contributions to open-source projects. So this is all the more exciting to me. I see GSoC as a very good opportunity to learn and also be a part of and give something back to a community. >>> >>> >>> I went through the Ideas page and was interested in porting the sugar core onto Python 3.x and I had a bunch of questions. >>> >>> 1. Are there any constraints the community places on the strategy that is to be >>> adopted to port the code or are the strategies up to the person submitting the >>> proposal? >>> 2. How reliable and thorough are the unit tests that are in place? >>> >>> >>> Here's what I've thought through so far. >>> Maintaining a code base in python 2 or in python 3 and then using 2to3 or 3to2 to give out releases is going to be problematic. Say someone files a bug against the Python 3.x version and the code for it was generated using 2to3, there wouldn't be a very good way to fix this. >>> >>> So my initial strategy is to strengthen the unit tests, make them compatible across 2.6-3.3, automate testing with python 2.6 and 3.3 simultaneously with Tox or a similar tool, and then incrementally write polyglot using the six package and other methods to pass more and more unit tests until the whole of the codebase supports Python 2.6 through to 3.3. Then, improve and update the documentation so that the codebase is easy to maintain in the future. >>> >>> Thanks, >>> Ravi Kumar >> >> >> >> -- >> Daniel Narvaez >> > > > _______________________________________________ > Sugar-devel mailing list > <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> > <a href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a> >