<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 31, 2018 at 4:50 PM, Matti Picus <span dir="ltr"><<a href="mailto:matti.picus@gmail.com" target="_blank">matti.picus@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">At the recent NumPy sprint at BIDS (thanks to those who made the trip) we spent some time brainstorming about a roadmap for NumPy, in the spirit of similar work that was done for Jupyter. The idea is that a document with wide community acceptance can guide the work of the full-time developer(s), and be a source of ideas for expanding development efforts.<br>
<br>
I put the document up at <a href="https://github.com/numpy/numpy/wiki/NumPy-Roadmap" rel="noreferrer" target="_blank">https://github.com/numpy/numpy<wbr>/wiki/NumPy-Roadmap</a>, and hope to discuss it at a BOF session during SciPy in the middle of July in Austin.<br></blockquote><div><br></div><div>Thanks for writing that up!<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Eventually it could become a NEP or formalized in another way.<br></blockquote><div><br></div><div>A NEP doesn't sound quite right, but moving from wiki to somewhere more formal and with more control over the contents (e.g. <a href="http://numpy.org">numpy.org</a> or in the docs) would be useful. A roadmap could/should also include things like required effort, funding and knowledge/people required. <br><br></div><div>A couple of comments on the content:<br></div><div>- a mention of stability or backwards compatibility goals under philosophy would be useful<br></div><div>- the "Could potentially be split out into separate packages..." should be removed I think - the maskedarray one was already rejected, and the rest are similarly unhelpful.<br></div><div>- "internal refactorings": MaskedArray yes, but the other ones no. numpy.distutils and f2py are very hard to test, a big refactor pretty much guarantees breakage. there's also not much need for refactoring, because those things are not coupled to the numpy.core internals. numpy.financial is simply uninteresting - we wish it wasn't there but it is, so now it simply stays where it is.<br></div><div>- One item that I think is missing under "New functionality" is runtime switching of backend for numpy.linalg (IIRC discussed on this list before) and numpy.random (MKL devs are interested in this).<br><br></div><div>Cheers,<br></div><div>Ralf<br><br></div></div></div></div>