I think supporting multiple python versions would be too much of a burden, we are busy enough supporting three toolkits :)<div>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.</div>
<div></div><div><br>On Saturday, 8 March 2014, Ravi Kumar <<a href="mailto:upman16@gmail.com">upman16@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div><div><div><div><div><div><div>Hello everyone,<br></div>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.<br><br><br></div>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.<br></div><br>1. Are there any constraints the community places on the strategy that is to be<br>


    adopted to port the code or  are the strategies up to the person submitting the<br>    proposal?<br>2. How reliable and thorough are the unit tests that are in place? <br><br><br></div>Here's what I've thought through so far.<br>

</div>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.<br>

<br></div>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.<br>

<br></div>Thanks,<br></div>Ravi Kumar<br></div>
</blockquote></div><br><br>-- <br>Daniel Narvaez<br><br>