[Numpy-discussion] Proposed Roadmap Overview

[David Cournapeau]

Hi Travis,

On Thu, Feb 16, 2012 at 10:39 PM, Travis Oliphant <travis at continuum.io> 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.

cheers,

David