Christopher Barker wrote: >> Following the full >> PEP procedure
>or a parallel NPEP system. Actually, I originally intended just to mean "follow the procedure" not "do it in their system". But, in thinking about it, if it's compatible with their system to develop a whole subpackage in their procedure space, we should. Ultimately the decision to include something in Python is one they will make, and such decisions are largely social ones. The more they have seen, been included in, and had chance to comment on our stuff, the more bought in they are and the less chance there is of objection to it. As for rapid pace of change, it would be feasible to agree on a core set of functionality that should go in the main language, to look at that with our decade of experience, and decide on a design and implementation that would be stable relative to what we have now. Mostly the code would just transfer; what people complain about is fluff, underlying package structure, API inconsistency, and turds. A few things might have API changes (like np.median() not long ago). There would be some significant issues to decide to do or not to do (like generalized ufuncs not long ago), but not many. I am thinking small here, though others will differ. No financials, nothing now deprecated, no fromnumeric namespace, nothing that is likely to evolve fast. Simple, clean, organized. The rest goes into scipy. --jh-- _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion