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 <[email protected]> wrote: > On Tue, Feb 28, 2012 at 4:49 PM, Bryan Van de Ven <[email protected]> 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 > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
