[Numpy-discussion] Proposed Roadmap Overview

[Ralf Gommers]

On Fri, Feb 17, 2012 at 9:56 PM, Mark Wiebe <mwwiebe at gmail.com> wrote:

> On Fri, Feb 17, 2012 at 12:49 PM, Ralf Gommers <
> ralf.gommers at googlemail.com> wrote:
>
>>
>>
>> On Fri, Feb 17, 2012 at 12:24 AM, Charles R Harris <
>> charlesr.harris at gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Feb 16, 2012 at 4:20 PM, <josef.pktd at gmail.com> wrote:
>>>
>>>> On Thu, Feb 16, 2012 at 5:56 PM, Warren Weckesser
>>>> <warren.weckesser at enthought.com> wrote:
>>>> >
>>>> >
>>>> > On Thu, Feb 16, 2012 at 4: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.
>>>> >>
>>>> >>        * 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120217/eb4dfd43/attachment.html>