[Numpy-discussion] Proposed Roadmap Overview
Fri Feb 17 09:01:06 CST 2012
On Thu, Feb 16, 2012 at 10:39 PM, Travis Oliphant <email@example.com> wrote:
> Mark Wiebe and I have been discussing off and on (as well as talking with Charles) a good way forward to balance two competing desires:
> * addition of new features that are needed in NumPy
> * improving the code-base generally and moving towards a more maintainable NumPy
> I know there are load voices for just focusing on the second of these and avoiding the first until we have finished that. I recognize the need to improve the code base, but I will also be pushing for improvements to the feature-set and user experience in the process.
> As a result, I am proposing a rough outline for releases over the next year:
> * NumPy 1.7 to come out as soon as the serious bugs can be eliminated. Bryan, Francesc, Mark, and I are able to help triage some of those.
> * NumPy 1.8 to come out in July which will have as many ABI-compatible feature enhancements as we can add while improving test coverage and code cleanup. I will post to this list more details of what we plan to address with it later. Included for possible inclusion are:
> * resolving the NA/missing-data issues
> * finishing group-by
> * incorporating the start of label arrays
> * incorporating a meta-object
> * a few new dtypes (variable-length string, varialbe-length unicode and an enum type)
> * adding ufunc support for flexible dtypes and possibly structured arrays
> * allowing generalized ufuncs to work on more kinds of arrays besides just contiguous
> * improving the ability for NumPy to receive JIT-generated function pointers for ufuncs and other calculation opportunities
> * adding "filters" to Input and Output
> * simple computed fields for dtypes
> * accepting a Data-Type specification as a class or JSON file
> * work towards improving the dtype-addition mechanism
> * re-factoring of code so that it can compile with a C++ compiler and be minimally dependent on Python data-structures.
This is a pretty exciting list of features. What is the rationale for
code being compiled as C++ ? IMO, it will be difficult to do so
without preventing useful C constructs, and without removing some of
the existing features (like our use of C99 complex). The subset that
is both C and C++ compatible is quite constraining.
More information about the NumPy-Discussion