> The next step is rewriting parts in C++, but I would wait a little bit > with this one, until the internals of SymPy are not changing that > often as now. The huge disadvantage of C++ rewriting is that we will > need to have two equivalent implementations - C++ and Python and keep > both updated, because I certainly want SymPy to run on pure Python > only, the C++ should be only an optional addon. But I believe it will > be possible - that's my secret plan from the beginning - to write it > in Python first, to have something now (and slow) and then when we > know how to do it and it works, to rewrite parts to C++ or even C.
I would recommend using Cython ( http://www.cython.org ) for this. Having used it with SAGE, I'd have to say it is by far the easiest way to write Python extensions. In fact, you can take most Python modules (with some exceptions) and compile them to C without any changes using Cython. Note that in this case, you don't really get much of a speed advantage, but it allows you to move a working Python implementation over to C and then start making changes for improve speed. > I think we could even ask SAGE people why they use mercurial and what > are proc & cons for them. While I do not make use of all the features of Mercurial, I've found it to be quite nice when for doing SAGE development. I currently have three different branches that I'm doing development on for features which independent of each other. Within each branch, I can make commits, revert them etc. When I have something to submit, it's easy to make a hg bundle / patch against the main branch for William to apply. --Mike --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
