On Fri, Apr 29, 2011 at 11:24 AM, Brian Granger <[email protected]> wrote: > In my mind the different mathematica *Form functions are analogous to > the different printers we have. In that light, I would develop > TableForm and yet another printer. Same is true of any other *Form > functions we want to copy from Mathematica.
I am not sure I understand what your idea is, but it seems that's exactly how I implemented it? TableForm is an object (it's not an issue for me whether or not it is derived from Basic, currently it is from technical reasons, but this can be changed), and then I have enhanced the printers to be able to print TableForm nicely in all our output printers. Because I want to use it with ascii (in terminal), in latex (when I write articles, it would be so much easier to just create the table in sympy, instead of wrestling with latex by hand), html, and so on. Is there a better design for such a thing? > But I do think we want this type of functionality in sympy, especially > something like TreeForm (I think that is what it is called) that > displays a nice expression tree. Great, I agree. So here is the result of the opinions: Ronan -1 Chris leaning towards +1 Mateusz +1 Ondrej +1 Brian +1 other people either don't mind or didn't have time to express their opinions. I aksed Aaron, but he is busy at the moment. So the trend is obvious. Let me be honest. Receiving such "-1, doesn't belong to sympy" reviews makes SymPy development no fun. Both me and Mateusz start to feel this way. And I would like to changes this. When I started sympy, the goal was obvious --- to create Mathematica like functionality in Python. In order to achieve the goal, I have worked extremely hard to build a community around sympy, because it is not possible to achieve such a goal all by myself. Since then I have now transferred the leadership to Aaron, so as such his opinion on this is crucial. However, my own goal has not changed at all. We have created patch reviews, because it improves the quality of the code going in and improves the community. I have no problems if people give -1 to my or any other code from technical reasons, that's why we do it. However, in order for this to work, the patch review should not be used to steer the project in another direction, or to stall the development by simply saying "-1, this doesn't belong to sympy". Clearly the above survey shows, that all people we asked so far say, that it *does* belong to sympy (the question of course is how to best implement it, but that's not an issue right now). So if you want to steer the development of sympy, it needs to happen on the mailinglist, and you need to get support from people around sympy and so on. So in particular for this patch, if you don't want this in sympy Ronan, you need to start campaigning for it, because at the moment, your opinion is in minority. I value it however, thanks for being around and thanks for having it. So it is ok that you have an opinion like that and one of the great things about the sympy community is that people do have different opinions, and so we can see things from different angles. However, in order to move forward, if somebody with a minority opinion on the issue gives -1, it stops development until this is resolved. So I would like to ask you Ronan, if you would be willing to let this and similar patches go in. Ondrej -- 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.
