[Numpy-discussion] Deprecate matrices in 1.15 and remove in 1.17?

[Nathaniel Smith]

On Thu, Nov 30, 2017 at 11:39 AM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Thu, Nov 30, 2017 at 11:43 AM, Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>> I'd suggest any release in the next couple of years is fine,but the one
>> where we drop Python 2 support is probably the worst choice. That's one of
>> the few things the core Python devs got 100% right with the Python 3 move:
>> advocate that in the 2->3 transition packages would not make any API changes
>> in order to make porting the least painful.
>
>
> Agree, we don't want to pile in too many changes at once. I think the big
> sticking point is the sparse matrices in SciPy, even issuing a
> DeprecationWarning could be problematic as long as there are sparse
> matrices. May I suggest that we put together an NEP for the NumPy side of
> things? Ralf, does SciPy have a mechanism for proposing such changes?

Agreed here as well... while I want to get rid of np.matrix as much as
anyone, doing that anytime soon would be *really* disruptive.

- There are tons of little scripts out there written by people who
didn't know better; we do want them to learn not to use np.matrix but
breaking all their scripts is a painful way to do that

- There are major projects like scikit-learn that simply have no
alternative to using np.matrix, because of scipy.sparse.

So I think the way forward is something like:

- Now or whenever someone gets together a PR: issue a
PendingDeprecationWarning in np.matrix.__init__ (unless it kills
performance for scikit-learn and friends), and put a big warning box
at the top of the docs. The idea here is to not actually break
anyone's code, but start to get out the message that we definitely
don't think anyone should use this if they have any alternative.

- After there's an alternative to scipy.sparse: ramp up the warnings,
possibly all the way to FutureWarning so that existing scripts don't
break but they do get noisy warnings

- Eventually, if we think it will reduce maintenance costs: split it
into a subpackage

I expect that one way or another we'll be maintaining matrix for quite
some time, and I agree with whoever said that most of the burden seems
to be in keeping the rest of numpy working sensibly with it, so I
don't think moving it into a subpackage is itself going to make a big
different either way. To me the logic is more like, if/when we decide
to actually break everyone's code by making `np.matrix` raise
AttributeError, then we should probably provide some package they can
import to get their code limping along again, and if we're going to do
that anyway then probably we should split it out first and shake out
any bugs before we make `np.matrix` start raising errors. But it's
going to be quite some time until we reach the "break everyone's code"
stage, given just how much code is out there using matrix, so there's
no point in making detailed plans right now.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org