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, how do you think we should go about porting then? On 9 March 2014 06:02, Daniel Narvaez <[email protected]> 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 <[email protected]> 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 [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
