On Fri, Feb 17, 2012 at 9:56 PM, Mark Wiebe <mwwi...@gmail.com> wrote:
> On Fri, Feb 17, 2012 at 12:49 PM, Ralf Gommers < > ralf.gomm...@googlemail.com> wrote: > >> >> >> On Fri, Feb 17, 2012 at 12:24 AM, Charles R Harris < >> charlesr.har...@gmail.com> wrote: >> >>> >>> >>> On Thu, Feb 16, 2012 at 4:20 PM, <josef.p...@gmail.com> wrote: >>> >>>> On Thu, Feb 16, 2012 at 5:56 PM, Warren Weckesser >>>> <warren.weckes...@enthought.com> wrote: >>>> > >>>> > >>>> > On Thu, Feb 16, 2012 at 4: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. >>>> >> >>>> >> * 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 > > Those both apply. > 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? > > The main reason is to allow starting to clean up the code, as Chuck said in his initial message: http://comments.gmane.org/gmane.comp.python.numeric.general/47765. So this would include old macros, maybe things like numarray support. Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion