On Apr 24, 2012, at 6:59 PM, Charles R Harris wrote: > > > On Tue, Apr 24, 2012 at 5:24 PM, Travis Oliphant <[email protected]> wrote: > > On Apr 24, 2012, at 6:01 PM, Stéfan van der Walt wrote: > > > On Tue, Apr 24, 2012 at 2:25 PM, Charles R Harris > > <[email protected]> wrote: > >>> Why are we having a discussion on NAN's in a thread on consensus? > >>> This is a strong indicator of the problem we're facing. > >> > >> We seem to have a consensus regarding interest in the topic. > > > > For the benefit of those of us interested in both discussions, would > > you kindly start a new thread on the MA topic? > > > > In response to Travis's suggestion of writing up a short summary of > > community principles, as well as Matthew's initial formulation, I > > agree that this would be helpful in enshrining the values we cherish > > here, as well as in communicating those values to the next generation > > of developers. > > > >> From observing the community, I would guess that these values include: > > > > - That any party with an interest in NumPy is given the opportunity to > > speak and to be heard on the list. > > - That discussions that influence the course of the project take place > > openly, for anyone to observe. > > - That decisions are made once consensus is reached, i.e., if everyone > > agrees that they can live with the outcome. > > This is well stated. Thank you Stefan. > > Some will argue about what "consensus" means or who "everyone" is. But, if > we are really worrying about that, then we have stopped listening to each > other which is the number one community value that we should be promoting, > demonstrating, and living by. > > Consensus to me means that anyone who can produce a well-reasoned argument > and demonstrates by their persistence that they are actually using the code > and are aware of the issues has veto power on pull requests. At times > people with commit rights to NumPy might perform a pull request anyway, but > they should acknowledge at least in the comment (but for major changes --- > on this list) that they are doing so and provide their reasons. > > If I decide later that I think the pull request was made inappropriately in > the face of objections and the reasons were not justified, then I will > reserve the right to revert the pull request. I would like core developers > of NumPy to have the same ability to check me as well. But, if there is a > disagreement at that level, then I will reserve the right to decide. > > Basically, what we have in this situation is that the masked arrays were > added to NumPy master with serious objections to the API. What I'm trying > to decide right now is can we move forward and satisfy the objections without > removing the ndarrayobject changes entirely (I do think the concerns warrant > removal of the changes). The discussion around that is the most helpful > right now, but should take place on another thread. > > > Travis, if you are playing the BDFL role, then just make the darn decision > and remove the code so we can get on with life. As it is you go back and > forth and that does none of us any good, you're a big guy and you're rocking > the boat. I don't agree with that decision, I'd rather evolve the code we > have, but I'm willing to compromise with your decision in this matter. I'm > not willing to compromise with Nathaniel's, nor it seems vice-versa. > Nathaniel has volunteered to do the work, just ask him to submit a patch.
I would like to see Nathaniel and Mark work out a document that they can both agree to and co-author that is presented to this list before doing something like that. At the very least this should summarize the feature from both perspectives. I have been encouraged by Nathaniel's willingness to contribute code, and I know Mark is looking for acceptable solutions that are still consistent with his view of things. These are all positive signs to me. We need to give this another week or two. I would prefer a solution that evolves the code as well. But, I also don't want yet another masked array implementation that gets little use but has real and long-lasting implications on the ndarray structure. There is both the effect of the growth of the ndarray structure (most uses should not worry about this at all), but also the growth of the *concept* of an ndarray --- this is a little more subtle but also has real downstream implications. Some of these implications have been pointed out already by consumers of the C-API who are unsure about how code that was not built with masks in mind will respond (I believe it will raise an error if they are using the standard APIs -- It probably should if it doesn't). Long term, I agree that the NumPy array should not be so tied to a particular *implementation* as it is now. I also don't think it should be tied so deeply to ABI compatibility. I think that was a mistake to be so devoted to this concept that we created a lot of work for ourselves --- work that is easily eliminated by distributions that re-compile down-stream dependencies after an ABI breaking release of NumPy. I realize, I didn't disagree very strongly before -- I disagree with my earlier view. That's not to say future releases of NumPy 1.X will break ABI compatibility --- I just think the price is not worth the value of the thing we have set as the standard (it's just a simple re-compile of downstream dependencies). We are quite delayed to get things out as you have noted. If the desire is to get a long-term release schedule for Debian and/or Ubuntu, then I think the 1.6.2 release is a good idea. It also makes more sense to me as a Long-Term Release candidate. -Travis > > Chuck > > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
