[Numpy-discussion] Removal of mask arrays? [was consensus]
Charles R Harris
Thu Apr 26 22:29:19 CDT 2012
On Tue, Apr 24, 2012 at 6:46 PM, Travis Oliphant <email@example.com>wrote:
> On Apr 24, 2012, at 6:59 PM, Charles R Harris wrote:
> On Tue, Apr 24, 2012 at 5:24 PM, Travis Oliphant <firstname.lastname@example.org>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@example.com> 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
>> 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.
Now that I've been working on it, I can assure you that 1.6.2 is a terrible
candidate for a long term release. The changes between 1.6 and 1.7 are
already enormous and I'm not even going to try to backport some of the
fixes. In addition, the *big* changes to datetime that made it workable are
not in 1.6. The reason the difference is so big is not only the big delay
in the release schedule, but the fact that 1.7 was being prepared for the
takeoff to 2.0. I think 1.7 or later is the only reasonable candidate for
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion