On Apr 29, 2011, at 4:01 PM, Vinzent Steinberg wrote: > On Apr 29, 10:59 pm, Ronan Lamy <ronan.l...@gmail.com> wrote: >> Le vendredi 29 avril 2011 à 11:56 -0700, Ondrej Certik a écrit : >>> 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 also think it should be some kind of matrix printer. I'm not sure if > we need some special object to store some flags, but then we should > redesign our printer system to be consistent. > >>> 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. > > I think there are some misunderstandings. It seem that Ronan is rather > against the technical implementation.
Well, I understood it that he was against the idea itself, especially based on his first email to this thread. I'd say rather he is against implementing in SymPy, as opposed to in some other library that uses SymPy. Perhaps Ronan can clarify? > > [...] >>> 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. > > I don't understand why you are upset about it. IMHO it would be > perfectly valid if someone says "-1" without giving any reason. Sure, > it would be more constructive to explain, but I think it's fine > nevertheless, because he just states opinion, it's like a vote. "-1" > is just short for "I'm against this change as it is currently > proposed, and my opinion does not count more or less than any other > opinion.". That's the democratic spirit in Open Source development I > really like. > > Why does discussion about patches spoil the fun? Is it because you > don't want to merge patches if someone is -1? > > After all, the calculation is simple. -1 + 4 == 3 > 0. So how could > one person steer development vs. a majority? (Paradoxically you tell > Ronan to campaign to steer development, where all he did is stating > his opinion.) > > [...] >>> I have no problems if people >>> give -1 to my or any other code from technical reasons, that's why we >>> do it. > > I agree that Ronan could have been more clear that he is rather > against the technical implementation than against the feature, but > isn't this what he did in the end? > >>> 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). > > Again, I don't get the point about steering development. (In the end > it even seems that Ronan agrees that it belongs to sympy.) > >> 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 > [...] >>> 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. > > Maybe we should change our development model. I think currently we say > a patch can't go in until everyone agrees (this is a very high > standard IMHO), but I think it is also fine to merge if there is a > majority. However, in this case it seems that it would be enough to > make TableForm not inherit from Basic. This might be a good idea. The -1 cases where everyone agrees upon them are clear (something wrong with the patch). The cases like this where people disagree (i.e., don't change their +1 to -1 after hearing someone else's argument for -1) are usually about something higher level, like "does this belong in SymPy?" or "this should be implemented in a fundamentally different way". Aaron Meurer > >> 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. > > That's how I understand a "-1". > > Vinzent -- 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.
