Hi Travis, On Thu, Feb 16, 2012 at 10:39 PM, Travis Oliphant <tra...@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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
