On Wed, May 9, 2012 at 6:13 PM, Paul Ivanov <pivanov...@gmail.com> wrote:
> > > On Wed, May 9, 2012 at 3:12 PM, Travis Oliphant <tra...@continuum.io>wrote: > >> On re-reading, I want to make a couple of things clear: >> >> 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. >> >> 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. >> >> 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. >> > > 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. > > 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. > > 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. Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion