On Tue, Aug 25, 2015 at 3:58 PM, Charles R Harris <charlesr.har...@gmail.com > wrote:
> > > On Tue, Aug 25, 2015 at 1:00 PM, Travis Oliphant <tra...@continuum.io> > wrote: > >> Thanks for the write-up Nathaniel. There is a lot of great detail and >> interesting ideas here. >> >> <snip> >> > > There are at least 3 areas of compatibility (ABI, API, and semantic). >> ABI-compatibility is a non-feature in today's world. There are so many >> distributions of the NumPy stack (and conda makes it trivial for anyone to >> build their own or for you to build one yourself). Making less-optimal >> software-engineering choices because of fear of breaking the ABI is not >> something I'm supportive of at all. We should not break ABI every >> release, but a release every 3 years that breaks ABI is not a problem. >> >> API compatibility should be much more sacrosanct, but it is also >> something that can also be managed. Any NumPy 2.0 should definitely >> support the full NumPy API (though there could be deprecated swaths). I >> think the community has done well in using deprecation and limiting the >> public API to make this more manageable and I would love to see a NumPy 2.0 >> that solidifies a future-oriented API along with a back-ward compatible API >> that is also available. >> >> Semantic compatibility is the hardest. We have already broken this on >> multiple occasions throughout the 1.x NumPy releases. Every time you >> change the code, this can change. This is what I fear causing deep >> instability over the course of many years. These are things like the >> casting rule details, the effect of indexing changes, any change to the >> calculations approaches. It is and has been the most at risk during any >> code-changes. My view is that a NumPy 2.0 (with a new low-level >> architecture) minimizes these changes to a single release rather than >> unavoidably spreading them out over many, many releases. >> >> I think that summarizes my main concerns. I will write-up more forward >> thinking ideas for what else is possible in the coming weeks. In the mean >> time, thanks for keeping the discussion going. It is extremely exciting to >> see the help people have continued to provide to maintain and improve >> NumPy. It will be exciting to see what the next few years bring as >> well. >> > > I think the only thing that looks even a little bit like a numpy 2.0 at > this time is dynd. Rewriting numpy, let alone producing numpy 2.0 is a > major project. Dynd is 2.5+ years old, 3500+ commits in, and still in > progress. If there is a decision to pursue Dynd I could support that, but > I think we would want to think deeply about how to make the transition as > painless as possible. It would be good at this point to get some feedback > from people currently using dynd. IIRC, part of the reason for starting > dynd was the perception that is was not possible to evolve numpy without > running into compatibility road blocks. Travis, could you perhaps summarize > the thinking that went into the decision to make dynd a separate project? > Thanks Chuck. I'll do this in a separate email, but I just wanted to point out that when I say NumPy 2.0, I'm actually only specifically talking about a release of NumPy that breaks ABI compatibility --- not some potential re-write. I'm not ruling that out, but I'm not necessarily implying such a thing by saying NumPy 2.0. > <snip> > > Chuck > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -- *Travis Oliphant* *Co-founder and CEO* @teoliphant 512-222-5440 http://www.continuum.io
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
