[Numpy-discussion] Proposed Roadmap Overview
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.
(on a mobile)
On Feb 28, 2012, at 9:51 PM, Fernando Perez <email@example.com> wrote:
> On Tue, Feb 28, 2012 at 4:49 PM, Bryan Van de Ven <firstname.lastname@example.org> 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
> - 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
> - 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...
> NumPy-Discussion mailing list
More information about the NumPy-Discussion