Le vendredi 29 avril 2011 à 11:56 -0700, Ondrej Certik a écrit : > 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. > You're mixing opinions about the feature and reviews of the patch. I'm not against the feature, I just want to make sure that implementing it inside sympy is needed, otherwise it will just rot, as happened for sympy.plot. > > 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. > If you don't want negative reviews, why have reviews at all?
> 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). How to implement it is very much the issue. I suggested that the feature might actually be available without changing a single line in sympy (but having taken a better look at tablib, I guess I was wrong). The only definite thing I said is that TableForm should not inherit from Basic. > > 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. Well, the pull request itself steers the development of sympy, so I don't see how it's possible to review it without doing likewise. Anyway, I'm glad you value everybody's opinion. That's why I expressed it, no matter whether I end up in the minority or not. > 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. A "-1" isn't a veto. I have no problem with patches I dislike going in, provided there's been clear support for it from several reviewers. -- 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.
