<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Jul 24, 2018 at 5:38 PM Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com" target="_blank">ralf.gommers@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>This is very developer-centric view. We have lots of users and also lots of no-longer-active contributors. The needs, interests and previous work put into NumPy of those groups of people matter.</div></div></div></div></blockquote><div><br></div></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>Yes, I suppose it is :).</div><div><br></div><div>I tend to view NumPy's developers (interpreted somewhat broadly, including those who contribute to the project in other ways) as the ultimate representatives of NumPy's user base.</div></div></div></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div><div>I like would suggest the following criteria for considering removing a NumPy submodule:<br></div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div>1. It cannot be relied upon by other portions of NumPy.</div><div>2. Either</div><div>(a) the submodule imposes a significant maintenance burden upon the rest of NumPy that is not balanced by the level of dedicated contributions, or<br></div></div><div>(b) much better alternatives exist outside of NumPy</div></div></div></blockquote><div> </div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>To quote Nathaniel: "the rest of our policy is all about measuring disruption based on effects on users". That's absent from your criteria.</div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>Yes, "Can be achieved with minimum disruption for users" would be appropriate to add as another top level criteria.</div></div></div></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Why I would like to keep this point in is:</div><div>- the discussion does come up, see draft brainstorm roadmap list and gh-11457.</div><div>- the outcome of such discussions is in practice 100% clear.<br></div><div>- I would like to avoid having drawn out discussions each time (this eats up a lot of energy for me), and I *really* would like to avoid saying "I don't have time to discuss, but this is just not going to happen" or "consider it vetoed". <br></div><div>- Hence: just write it down, so we can refer to it.</div></div></div></div></blockquote><div><br></div><div>I would rather we just say that the bar for deprecating or removing *any* functionality in NumPy is extremely high. np.matrix is probably the best example in recent times:</div><div>- np.matrix is officially discouraged (which we prefer even to deprecation)</div><div>- we *anticipate* deprecating it as soon as there's a viable alternative to scipy.sparse</div><div>- even then, we will be very cautious about ever removing it, with the understanding that it is widely used</div><div><br></div><div>As for updating this section of the NEP:</div><div>- We could certainly note that to date NumPy has not removed any complete submodules (is this true?), and that these modules in particular, the cost-benefit ratio does not favor removal at this time.</div><div>- Documenting the criteria we've come up with here, even though it hasn't been satisfied yet, might be helpful to demonstrate the high bar that is required.<br></div><div><div>- I don't like rejecting the possibility of removing submodules entirely "simply not a good idea". It may become a good idea in the future, if some of the underlying facts change.<br></div><br class="inbox-inbox-Apple-interchange-newline"></div><div>I would also suggest highlighting two other strategies that NumPy uses in favor of deprecation/removal:<br></div><div>- Official discouragement. Discouraging or deemphasizing in our docs is the preferred strategy for older APIs that still have well defined behavior but that are arguably less consistent with the rest of NumPy. Examples: isin vs in1d, stack/block vs hstack/dstack/vstack.</div><div>- Benign neglect. This is our preferred strategy to removing submodules. Merely being in NumPy does not automatically guarantee that a module is well maintained, nor does it imply that a submodule is the best tool for the job. That's OK, as long as the incremental maintenance burden on the rest of NumPy is not too high.</div><div><br></div><div><br></div></div></div></div></div>