[Numpy-discussion] Proposed Roadmap Overview

[Mark Wiebe]

On Tue, Feb 28, 2012 at 11:03 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Tue, Feb 28, 2012 at 10:46 PM, Travis Oliphant <travis at continuum.io>
> wrote:
> > We already use the NEP process for such decisions.   This discussion
> came from simply from the *idea* of writing such a NEP.
> >
> > Nothing has been decided.  Only opinions have been shared that might
> influence the NEP.  This is all pretty premature, though ---  migration to
> C++ features on a trial branch is some months away were it to happen.
>
> Sure, I know we do have neps, they live in the main numpy repo (which
> btw, I think they should be moved to a standalone repo to make their
> management independent of the core code, but that's an easy and minor
> point we can ignore for now). I was just thinking that this discussion
> is precisely the kind of thing that would be well served by being
> organized in a nep, before even jumping into implementation.
>
> A nep can precisely help organize a discussion where there's enough to
> think about and make decisions *before* effort has gone into
> implementing anything.  It's important not to forget that once someone
> goes far enough down the road of implementing something, this adds
> pressure to turn the implementation into a fait accompli, simply out
> of not wanting to throw work away.
>
> For a decision as binary as 'rewrite the core in C++ or not', it would
> seem to me that organizing the problem in a NEP *before* starting to
> implement something in a trial branch would be precisely the way to
> go, and that it would actually make the decision process and
> discussion easier and more productive.
>

The development approach I really like is to start with a relatively rough
NEP, then cycle through feedback, updating the NEP, and implementation.
Organizing ones thoughts to describe them in a design document can often
clarify things that are confusing when just looking at code. Feedback from
the community, both developers and users, can help expose where your
assumptions are and often lead to insights from subjects you didn't even
know about. Implementation puts those ideas through the a cold, hard,
reality check, and can provide a hands-on experience for later rounds of
feedback.

This iterative process is most important to emphasize, the design document
and the code must both evolve together. Stamping a NEP as "final" before
getting into code is just as bad as jumping into code without writing a
preliminary design.

For the decision about adopting C++, a NEP proposing how we would go about
doing it, which evolves as the community gains experience with the idea,
will be very helpful. I would emphasize that the adoption of C++ does not
require a rewrite. The patch required to make NumPy build with a C++
compiler is very small, and individual features of C++ can be adopted
slowly, in a piecemeal fashion. What I'm advocating for is this kind of
gradual evolution, and my starting point for writing a NEP would be the
email I wrote here:

http://mail.scipy.org/pipermail/numpy-discussion/2012-February/060778.html

Github actually has a bug that the RST table of contents is stripped, and
this makes reading longer NEPS right in the repository uncomfortable. Maybe
alternatives to a git repository for NEPs should be considered. I reported
the bug to github, but they told me that was just how they did things.

Cheers,
Mark



>
> Cheers,
>
> f
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120228/86a75d3b/attachment.html>