<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 1, 2018 at 9:57 AM, Stefan van der Walt <span dir="ltr"><<a href="mailto:stefanv@berkeley.edu" target="_blank">stefanv@berkeley.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Ralf,<br>
<span class=""><br>
On Thu, 31 May 2018 21:57:06 -0700, Ralf Gommers wrote:<br>
> - "internal refactorings": MaskedArray yes, but the other ones no.<br>
> numpy.distutils and f2py are very hard to test, a big refactor pretty much<br>
> guarantees breakage. there's also not much need for refactoring, because<br>
> those things are not coupled to the numpy.core internals. numpy.financial<br>
> is simply uninteresting - we wish it wasn't there but it is, so now it<br>
> simply stays where it is.<br>
<br>
</span>I want to clarify that in the current notes we put down ideas that<br>
prompted active discussion, even if they weren't necessarily feasible.<br>
I feel it is important to keep the conversation open to run its course<br>
until we have a good understanding of the various issues at hand.<br>
<br>
You may find that, in person, people are more willing to admit to their<br>
support for some "heretical" ideas than they are here on the list.<br></blockquote><div><br><div>Thanks Stefan, good points. I totally agree that anything can be discussed. </div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
E.g., you say that the financial functions "now simply stay", but that<br>
promises a future of a NumPy that never shrinks, while there is<br>
certainly some support for allowing NumPy to contract so that we can<br>
release maintenance burden and allow development of other core areas<br>
that have been neglected for a long time.<br>
<br>
You will *always* have small, vocal proponents of any specific piece of<br>
functionality; that doesn't necessarily mean that such functionality<br>
contributes to the health of a project as a whole.<br>
<br>
So, I gently urge us carefully reconsider the narrative that nothing can<br>
change/be removed, and evaluate each suggestion carefully, not weighing<br>
only the very evident negatives but also the longer term positives.<br></blockquote><br></div><div class="gmail_quote">I don't think there's such a narrative - e.g. the removal of np.matrix that we've planned and getting rid of MaskedArray at some point once we have a better new masked array implementation are *major* removals. We do plan those things because they have major benefits. Imho "major benefits" is a bar that needs to be passed before listing features as up for removal on a roadmap (even a draft one).<br></div><div class="gmail_quote"><div><br>It would be helpful maybe to find a form for the roadmap where the essentials of such discussions (key pros/cons) can be captured. Or at least split it in good/desirable/planned items and "wild ideas". <br><br>Re `financial`, there isn't much of a pro as far as I can tell - there's almost zero maintenance cost now, and it doesn't hinder any of the proposed new features. Plus it's a discussion we've had a couple of times before. <br><br>I know that the current roadmap doc is only draft, but it still says "NumPy Roadmap" and it's the best thing we have now, so I'd prefer to not have things there (or have them in a separate random/controversial ideas section) that are unlikely to happen or for which it's unclear if they're good ideas.<br><br></div><div>Cheers,<br></div><div>Ralf<br></div><div><br></div></div><br></div></div>