On Mar 24, 2011, at 6:07 AM, VPeric wrote: > 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.
I think the main thing was fixing the __hash__ warnings. These turned out to not be as bad as we thought they would be due to a bug in Python (the moral is use -3 in Python 2.7, not Python 2.6). See commit 53bf7024b466c5076aa6a12d3d4dc3532533af58. Also, some headway has been made in removing all cmp functions, which are no longer supported as arguments to sort(). You can see what else is there. I think those are the main things not covered by the 2to3 tool, but I might be wrong. Note: ignore warnings in mpmath, which is an external library (and the next version already supports Python 3), and Pyglet, which is also an external library, which we will be removing from inclusion in SymPy at some point in the future. > > 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. By the way, I think for these external Pythons like PyPy and Jython, we will only be able to officially support the most recent version (unless you think testing more is feasible), unlike we do with CPython. > > 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. This is also good. I think "in addition to" is good. Just put things in order of priority in your proposal. So, first, port to Python 3. Second, create a build system to make it all manageable. Third, port to other Pythons (ideally the build system from step 2 would be modular enough that you could just plug these in). > > 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? The easy to fix issues are just a suggestion for people who have never contributed before. But definitely fixing something related to your project is a good idea. Aaron Meurer > > 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. > -- 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.
