[Numpy-discussion] Proposed Roadmap Overview

Travis Oliphant travis@continuum...
Wed Feb 29 00:46:59 CST 2012


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.

Travis 

--
Travis Oliphant
(on a mobile)
512-826-7480


On Feb 28, 2012, at 9:51 PM, Fernando Perez <fperez.net@gmail.com> wrote:

> On Tue, Feb 28, 2012 at 4:49 PM, Bryan Van de Ven <bryanv@continuum.io> wrote:
>> Just my own $0.02 regarding this issue: I am in favor of using C++ for
>> numpy, I think it could confer various benefits. However, I am also in
>> favor of explicitly deciding and documenting what subset of C++ features
>> are acceptable for use within the numpy codebase.
> 
> I would *love* to see us adopt the NEP/PEP process for decisions as
> complex as this one.  The PEP process serves the Python community very
> well, and I think it's an excellent balance of minimal overhead and
> maximum benefit for organizing the process of making
> complex/controversial decisions.  PEP/NEPs serve a number of important
> purposes:
> 
> - they encourage the proponent of the idea to organize the initial
> presentation in a concrete, easy to follow way that can be used for
> decision making.
> 
> - they serve as a stable reference of the key points in a discussion,
> in contrast to the meandering that is normal of a mailing list thread.
> 
> - they can be updated and evolve as the discussion happens,
> incorporating the distilled ideas that result.
> 
> - if important new points are brought up in the discussion, the
> community can ensure that they are added to the NEP.
> 
> - once a decision is reached, the NEP is updated with the rationale
> for the decision.  Whether it's acceptance or rejection, this ensures
> that in the future, others can come back to this document to see the
> reasons, avoiding repetitive discussions.
> 
> - the NEP can serve as documentation for a specific feature; we see
> this often in Python, where the standard docs refer to PEPs for
> details.
> 
> - over time, these documents build a history of the key decisions in
> the design of a project, in a way that is much easier to read and
> reason about than a random splatter of long mailing list threads.
> 
> 
> I was offline when the long discussions on process happened a few
> weeks ago, and it's not my intent to dig into every point brought up
> there.  I'm only proposing that we adopt the NEP process for complex
> decisions, of which the C++ shift is certainly one.
> 
> In the end, I think the NEP process will actually *help* the
> discussion process.  It helps keep the key points on focus even as the
> discussion may drift in the mailing list, which means ultimately
> everyone wastes less energy.
> 
> I obviously can't force anyone to do this, but for what it's worth, I
> know that at least for IPython, I've had this in mind for a while.  We
> haven't had any majorly contentious decisions that really need it yet,
> but for example I have in mind a redesign and extension of the magic
> system that I intend to write-up pep-style.  While I suspect nobody
> would yell if I just went ahead and implemented it on a pull request,
> there are enough moving parts and new ideas that I want to gather
> feedback in an organized manner before proceeding with implementation.
> And I don't find that idea to be a burden, I actually do think it
> will make the whole thing go more smoothly even for me.
> 
> Just a thought...
> 
> f
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion


More information about the NumPy-Discussion mailing list