<br><br><div class="gmail_quote">On Wed, May 9, 2012 at 6:13 PM, Paul Ivanov <span dir="ltr"><<a href="mailto:pivanov314@gmail.com" target="_blank">pivanov314@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div class="im">On Wed, May 9, 2012 at 3:12 PM, Travis Oliphant <span dir="ltr"><<a href="mailto:travis@continuum.io" target="_blank">travis@continuum.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="word-wrap:break-word">On re-reading, I want to make a couple of things clear:   <div><br></div><div><span style="white-space:pre-wrap">     </span>1) This "wrap-up" discussion is *only* for what to do for NumPy 1.7 in such a way that we don't tie our hands in the future.    I do not believe we can figure out what to do for masked arrays in one short week.   What happens beyond NumPy 1.7 should be still discussed and explored.    My urgency is entirely about moving forward from where we are in master right now in a direction that we can all accept.      The tight timeline is so that we do *something* and move forward.    </div>

<div><br></div><div><span style="white-space:pre-wrap"> </span>2) I missed another possible proposal for NumPy 1.7 which is in the write-up that Mark and Nathaniel made:  remove the masked array additions entirely possibly moving them to another module like numpy-dtypes.</div>

<div><br></div><div>Again, these are only for NumPy 1.7.   What happens in any future NumPy and beyond will depend on who comes to the table for both discussion and code-development. </div></div></blockquote><div><br></div>

</div><div>I'm glad that this sentence made it into the write-up: "A project like numpy requires developers to write code for advancement to occur, and obstacles that impede the writing of code discourage existing developers from contributing more, and potentially scare away developers who are thinking about joining in." I agree, which is why I'm a little surprised after reading the write-up that there's no deference to the alterNEP (admittedly kludgy) implementation? One of the arguments made for the NEP "preliminary NA-mask implementation" is that "has been extensively tested against scipy and other third-party packages, and has been in master in a stable state for a significant amount of time." It is my understanding that the manner in which this implementation found its way into master was a source of concern and contention. To me (and I don't know the level to which this is a technically feasible) that's precisely the reason that BOTH approaches be allowed to make their way into numpy with experimental status. Otherwise, it seems that there is a sort of "scaring away" of developers - seeing (from the sidelines) how much of a struggle it's been for the alterNEP to find a nurturing environment as an experimental alternative inside numpy. In my reading, the process and consensus threads that have generated so many responses stem precisely from trying to have an atmosphere where everyone is encouraged to join in. The alternatives proposed so far (though I do understand it's only for 1.7) do not suggest an appreciation for the gravity of the fallout from the neglect the alterNEP and the issues which sprang forth from that.</div>

<div><br></div><div>Importantly, I find a problem with how personal this document (and discussion) is - I'd much prefer if we talk about technical things by a descriptive name, not the person who thought of it. You'll note how I've been referring to NEP and alterNEP above. One advantage of this is that down the line, if either Mark or Nathaniel change their minds about their current preferred way forward, it doesn't take the wind out of it with something like "Even Paul changed his mind and now withdraws his support of Paul's proposal." We should only focus on the technical merits of a given approach, not how many commits have been made by the person proposing them or what else they've done in their life: a good idea has value regardless of who expresses it. In my fantasy world, with both approaches clearly existing in an experimental sandbox inside numpy, folks who feel primary attachments to either NEP or alterNEP would be willing to cross party lines and pitch in towardd making progress in both camps. That's the way we'll find better solutions, by working together, instead of working in opposition.</div>

<div><br></div></div></blockquote><div><br>We are certainly open to code submissions and alternate implementations. The experimental tag would help there. But someone, as you mention, needs to write the code.<br><br>Chuck <br>
</div></div>