The important part: About the backend: I suppose (not sure) that the community will be mostly interested in the svgfig backend. Then about pyglet: rewrite will definitely be useful, as the current code is in the form of spaghetti, but it will not be a very interesting task. I would leave it for the end of gsoc if I have the time. I doubt that Google Charts API will be used much (as you said it is not for plotting functions).
A rant: About lambdify and experimental_lambdify: IMO lambdify is an unpythonic abomination: It tries to serve multiple unrelated and sometimes exclusive purposes (1. compiler to numpy/mpmath, 2. useless additional syntax for `lambda x: blah_x` 3. check all the other strange examples in the tests.). The tests and docstrings contradict each other (is it for "fast _numerical_ calculations" or for this `lambda x : UNevaluated_expression_of_x`) The code is unmaintainable: is it a compiler? If it is, where is the AST tree processing? To what does it compile? The way that it uses `exec` on an enormous uncontrolled namespace... Yes, I dislike this piece of code very strongly. The lambdify function was created (according to git log) to be used for fast(therefore not subs().evalf()) numerical(therefore numpy) evaluation for use in the old plotting module. Then it got used in other places for completely unrelated tasks. Then it evolved to take care of those tasks (badly) but the documentation was not updated. My experimental_lambidify is slightly less ugly and it is good only for numerical calculations (better than lambdify) but it can be rewritten in a much cleaner way (using python AST). In the plotting examples you can see all the cases where lambdify fails but experimental_lambdify works. This all was just to point out how unsustainable the use of lambdify is. I would like to see it removed (it will break some code). This is my opinion on the question, but the core developers should decide. I propose to check all the places where lambdify is used in our codebase (mostly numerical stuff like nsolve and the old plotting module). Then test it with one of the many trivial expressions that make it crash and the see what must be done to substitute it with experimental_lambidify in this particular place (which has many rough edges, but much less than lambidfy). That way lambdify can be removed. This way there will be an api change in the next version, but it will work better. -- 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.
