On Mar 23, 8:30 pm, Mateusz Paprocki <[email protected]> wrote: > Hi, > > It's a good question whether this is "big enough". Surely it's important > enough to consider this as a GSoC project. I think that the biggest problem > currently (unless I forgot about something else) are __cmp__ methods. We are > gradually taking care of this issue across SymPy but there is still a lot of > work to be done in this area. It's up to you to recognize issues that have > to be fixed and figure out a schedule you would like to follow (don't > hesitate to ask, because we already made some effort to make SymPy > compatible with Python 3 and we have some code in development branches that > could help you). If it happens that there is not enough work in porting > SymPy to Python 3, then you might consider widening the project and make > SymPy run in a subset of Jython, PyPy, IronPython, etc. (I don't remember > which are already supported).
To be completely honest, I haven't ported such a big project before so I fear I won't be able to accurately judge how long each part is going to take. So, any help in that regard is quite appreciated. I tried to look at the work done previously, but the links were dead. In any case, based on ronan's suggestions on IRC, I feel that also going for PyPy compliance is a worthwhile addition to the core goal of porting to Python 3. It is related, and goes hand-in-hand with the "Python only" design goal for SymPy. Though various tests currently fail, PyPy development is proceeding at a break-neck pace and I believe it should be possible to completely support it (at the very least, fast development means any changes that would have to be made to PyPy wouldn't languish for months). Again, though, I'm not sure I can accurately estimate how long this project would take. Alternatively (or in addition to, I suppose) to PyPy support, I could work on better packaging/a buildbot system. This is closely related to porting to Python 3 [*], so can be seen as more of a natural fit. Better packaging would surely lead to increased adoption, which can only be a good thing. And, again, closely related to this is a more robust testing framework, which can only be a good thing. In essence, in such a case, my project would improve the base infrastructure needed to continue development at a fast-pace. In any case, I will investigate more over the next couple of days. One more question about the mandatory patch for the GSoC application: can I pick something at random to fix (for example, correcting the warnings "Python -3" shows, as a starting point for Python 3 porting), or do I have to choose something from the EasyToFix page? Thanks, Vlada [*]For those not aware, a dual Python 2/3 code base mostly means that code is in Python 2 and that the 2to3 tool is automatically ran if we are building for Python 3. Such a system is obviously closely connected to both the packaging and a thorough test framework. -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
