Small correction: none of those were decided on, it was more a “not to be considered before 2.0”.
I think the first thing to agree on is the principles for the release, in particular this:
Most of the items on that wiki page seem like they’d clash with this. For a 2.0 release along the lines I described, we’re only removing some already-deprecated things (possibly with 1-2 exceptions) and do a few more impactful deprecations. A six month timeline is easily compatible with that. The most work will be the actual preparation for making the array types support public.
As for concrete items on that list:
- Already deprecated things are the compat shims for private APIs and possibly
scipy.misc(since all its namespace members are deprecated). - Removals of APIs that aren’t yet deprecated (fftpack, mstats, ltisys/wavelets/splines, signal.cwt, sparse matrices, cKDTree, changes of return types away from tuples): that would all be out of scope.
- uarray is the one that maybe we could get away with, since there are only a few large users and that functionality is essentially being replaced in large part by the dispatching on array types we will now make public
- I’d also say that most of this is low-prio and if we want to get rid of it, a deprecation could be done in any regular feature release
rngkeyword behavior changes is the one item that seems relevant and we’ve been working towards for a while.
Do you agree with the principles I proposed, or are you advocating for a much more breaking major release @j-bowhay?