[Numpy-discussion] Proposed Roadmap Overview

Mark Wiebe mwwiebe@gmail....
Fri Feb 17 14:56:25 CST 2012


On Fri, Feb 17, 2012 at 12:49 PM, Ralf Gommers
<ralf.gommers@googlemail.com>wrote:

>
>
> On Fri, Feb 17, 2012 at 12:24 AM, Charles R Harris <
> charlesr.harris@gmail.com> wrote:
>
>>
>>
>> On Thu, Feb 16, 2012 at 4:20 PM, <josef.pktd@gmail.com> wrote:
>>
>>> On Thu, Feb 16, 2012 at 5:56 PM, Warren Weckesser
>>> <warren.weckesser@enthought.com> wrote:
>>> >
>>> >
>>> > On Thu, Feb 16, 2012 at 4:39 PM, Travis Oliphant <travis@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

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
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20120217/bc12a986/attachment.html 


More information about the NumPy-Discussion mailing list