On Jun 25, 2012, at 7:21 PM, Fernando Perez wrote: > On Mon, Jun 25, 2012 at 5:10 PM, Travis Oliphant <tra...@continuum.io> wrote: >> You are still missing the point that there was already a choice that was >> made in the previous class --- made in Numeric actually. >> >> You made a change to that. It is the change that is 'gratuitous'. > > As someone who played a role in that change (by talking with Chuck > about it, I didn't do the actual hard work), I'd like to pitch in. > > I think it's unfair to use the word gratuitous here, which is defined as: > > Adjective: > > Uncalled for; lacking good reason; unwarranted.
I appreciate your perspective, but I still think it's fair to use that word. I think it's been interpreted more broadly then I intended and in a different color than I intended. My use of the word is closer to "uncalled for" and "unwarranted" than an isolated "lacking good reason". I know very well that anything done in NumPy has a "good reason" because the people who participate in NumPy development are very bright and capable. For context, consider that for many years, the word "gratuitous" has been used in a non-derogatory way in the Python ecosystem to describe changes to semantics and syntax that don't have benefits significant enough to offset the pain it will cause to existing users. That's why I used the word. I am not trying to be derogatory. I am trying to be clear that we need to respect existing users of NumPy more than we have done from 1.5 to 1.7 in the enthusiasm to make changes. I will repeat my very simple argument: I think this particular change was uncalled for because now we will have 2 different conventions in NumPy for polynomial order coefficients. I understand it's a different API so code won't break which is a good thing --- but it will be a wart for NumPy as we explain for years to come about the different conventions in the same code-base. Working on the NumPy code base implies respecting the conventions that are already in place --- not just disregarding them and doing whatever we want. I'm not really sure why I have to argue the existing users point of view so much recently. I would hope that all of us would have the perspective that the people who have adopted NumPy deserve to be treated with respect. The changes that grate on me are the ones that seem to take lightly existing users of NumPy. > > > It is true that the change happened to not consider enough the reasons > that existed for the previous state of affairs, but it's *not* true > that there were no good reasons for it. Of course not. I've tried to make the point very clearly that I understand the good reasons for it. I do understand them. 12-13 years ago, when the decisions were being made about current conventions, I would likely have been persuaded by them. > But to say that there were no good reason is unfair to those who did > spend the time thinking about the problem, and who thought the reasons > they had found were indeed good ones. I did not ever say there were no good reasons. Please do not add energy to the idea that I'm dis-regarding the reasoning of those who thought about this. I'm not. I said the changes were uncalled for and unwarranted. I stand by that assessment. I do not mean any dis-respect to the people who made the changes. In that context, it's also useful to recognize how unfair it is to existing users to change conventions and ignore the work they have put in to understanding and using what is there. It's also useful to consider the unfairness of ignoring the thinking and work that went in to the existing conventions and APIs. > I know that this particular issue grates you quite a bit, but I urge > you to be fair in your appreciation of how it came to be: through the > work of well-intentioned and thoughtful (but not omniscient) people > when you weren't participating actively in numpy development. I'm trying very hard to be fair --- especially to changes like this. What grates me are changes that affect our user base in a negative way --- specifically by causing code that used to work to no longer work or create alterations to real conventions. This kind of change is just not acceptable if we can avoid it. I'm really trying to understand why others do not feel so strongly about this, but I'm not persuaded by what I've heard so far. Please note that I'm not trying to assign blame. I recognize the part that my failings and inadequacies have played in this (I continue to be willing to listen to others assessments of those inadequacies and failings and do my best to learn from them). I'm just trying to create a different context for future discussions about these sorts of things. I love the changes that add features and capability for our users. I have not called for ripping these particular changes out even though I would be much, much happier if there were a single convention for polynomial-coefficient order in NumPy. In fact, most of my messages have included references to how to incorporate such changes with as little impact as possible -- finding some way to reconcile things, perhaps by focusing attention away from such things (adding a keyword to the poly1d class, perhaps, to allow it to be called in reverse order). Best, -Travis _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
