So I agree with Brian here. TableForm is just another printer, which clearly belongs in SymPy.
Aaron Meurer On Apr 29, 2011, at 12:56 PM, Ondrej Certik wrote: > On Fri, Apr 29, 2011 at 11:24 AM, Brian Granger <elliso...@gmail.com> 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. > > Ondřej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
