Matthew Brett writes: [...]
If we do value constructive disagreement then we'll go out of our way to talk through the points of contention, and make sure that the people who disagree, especially the minority, feel that they have been fully heard.
If we don't value constructive disagreement then we'll let the other side know that further disagreement will be taken as a sign of bad faith.
Now - what do you see here? I see the second and that worries me.
It is disappointing that you choose not to participate in the thread linked above or in the pull request itself. If I remember correctly, you were working on finishing up your dissertation, so I fully understand the time constraints involved there. However, the pull request and the email notification is the de facto method of staging and discussing changes in any development project. No objections were raised in that pull request, so it went in after some time passed. To hold off the merge, all one would need to do is fire off a quick comment requesting a delay to have a chance to review the pull request.
I think the pull-request was not the right vehicle for the discussion, you think it was, that's fine, I don't think we need to rehearse that.
My question (if you are answering my question) is: if you put yourself in my or Nathaniel's shoes, would you feel that you had been warmly encouraged to express disagreement, or would you feel something else.
I sense (bear with me, my senses are not very sharp) that you feel your concerns have not been addressed, and thus the sensation that features you disagreed upon were sneaked through a silent pull request. And yes, the initial discussions were too heated on some moments (me included), but that does not imply that the current state is ignoring the concerns everybody raised.
Luckily, git is a VCS, so we are fully capable of reverting any necessary changes if warranted. If you have any concerns or suggestions for changes in the current implementation, feel free to raise them and open additional pull requests. There is no "ganging up" here or any other subterfuge. Tell us exactly what are your issues with the current setup, provide example code demonstrating the issues, and we can certainly discuss ways to improve this.
Has the situation changed since the counter-NEP that Nathaniel and I wrote up?
I couldn't find the link, but AFAIR the main concerns were: - Using bit patterns as a more efficient missing data mechanism that is compatible with third-party binary libraries. As the NEP says, although not implemented (due to lack of time), bit patterns are a desirable extension that will be able to coexist with masks while providing a single and consistent Python and C API for both bit patterns and masks. - Being able to expose the non-destructive nature of masks. There is only one very specific path leading to such behaviour [1], so users not interested in it should never inadvertently fall into its use (aka, they don't even need to know about it). [1] http://docs.scipy.org/doc/numpy/reference/arrays.maskna.html#creating-na-mas... If we agree that it is reasonable to think that the concerns in the "counter-NEP" have been addressed in the current implementation, then I think it is not unreasonable to take the silence to Mark's mail and the pull request as a green light. Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth