[Numpy-discussion] Missing data wrap-up and request for comments

Charles R Harris charlesr.harris at gmail.com
Wed May 9 20:46:45 EDT 2012


On Wed, May 9, 2012 at 6:13 PM, Paul Ivanov <pivanov314 at gmail.com> wrote:

>
>
> On Wed, May 9, 2012 at 3:12 PM, Travis Oliphant <travis at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120509/4378b38e/attachment.html>


More information about the NumPy-Discussion mailing list