On Fri, Feb 17, 2012 at 12:49 PM, Ralf Gommers <[email protected]>wrote:
> > > On Fri, Feb 17, 2012 at 12:24 AM, Charles R Harris < > [email protected]> wrote: > >> >> >> On Thu, Feb 16, 2012 at 4:20 PM, <[email protected]> wrote: >> >>> On Thu, Feb 16, 2012 at 5:56 PM, Warren Weckesser >>> <[email protected]> wrote: >>> > >>> > >>> > On Thu, Feb 16, 2012 at 4:39 PM, Travis Oliphant <[email protected]> >>> > 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. >>> >> >>> >> * NumPy 2.0 to come out in January of 2013. Mark Wiebe and I >>> will >>> >> post to this list a document that explains some of it's proposed >>> features >>> >> and enhancements. I won't steal his thunder for some of the things >>> he is >>> >> working on. >>> >> >>> >> If there are code issues people would like to see addressed, it would >>> be a >>> >> great time to speak up and/or propose something that you would like >>> to see. >>> > >>> > >>> > >>> > The above list looks great. Another request that comes up >>> occasionally on >>> > the mailing list is for the efficient computation of order statistics, >>> the >>> > simplest case being a combined min/max function. Longish thread starts >>> > here: http://thread.gmane.org/gmane.comp.python.numeric.general/44130/ >>> >>> The list looks great, but for the time table I expect there will be at >>> least a 1.9 and 1.10 necessary to improve what "we didn't get quite >>> right in the first place", or what not many users had time to try out. >>> >>> >> >> That's my sense also. I think the long list needs to be prioritized and >> broken up into smaller chunks. >> > > +1 for an extra release (or two). > > Looking at the list of features, which looks great by the way, I think the > last release before adding a whole bunch of new features should be the LTS. > Ideally 1.8 would be mostly the refactoring and the LTS, with 1.9 > containing most of the new features. If not, 1.7 should probably be the LTS. > To be clear, the purpose behind an LTS release is to provide ongoing bugfixes for users to whom one of the following applies: * Must use Python 2.4. * Are on a platform whose C/C++ compiler will never be updated anymore This way, developing NumPy can be made easier by not having to keep compatibility with really old systems. Am I understanding this correctly, or am I missing some aspect of the LTS strategy? Thanks, Mark > > Ralf > > > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion > >
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
