On Sat, Oct 19, 2024 at 2:18 PM Dan Schult wrote:
> This is quite helpful. Thanks!
>
> Github search:
> I'm not surprised that many github hits are like homework problems. The
> big resistance to removing np.matrix early on (~2008) came from educators
> who wanted a Matrix oriented experience for their students who had recent
> linear algebra background. It was heavily used for at least a decade in the
> education setting. That started to wane when Python created the `@`
> operator. But change is slow. It's been 10 years with `@`.
>
> I very much support Ralf's concerns that this not push SciPy. It would be
> pushing me after-all. But it is hard to know how to proceed with the
> transfer from spmatrix to sparray without also knowing something about the
> support for np.matrix from the numpy devs. But... there's no reason removal
> of spmatrix needs to happen first. It may be quite natural for both to be
> moved to a single separated package. Or they could be removed at the same
> time. We'll have to see what makes sense.
>
> Thanks Nathan for the preview of github usage and perspective from the 2.0
> release. I'm also pleased to find that github search results for PRs can be
> sorted by date. While there are 28K PRs involving np.matrix, the recent PRs
> are almost all dependabot reminding folks to upgrade their dependencies. Of
> the top 30, 3 were actions to **remove** np.matrix in favor of ndarray. 1
> was `scipy.interpolate` (which also mentioned removing support for
> `np.matrix`, though provided a workaround instead). And the remaining 26
> are dependency updates. That takes us back to Aug 30. Jumping to the most
> recent 80 PRs gave the same type of results, but I didn't bother counting.
> Almost all of them are dependency updates. Most of the rest are moving away
> from np.matrix. It is clear that recent activity (as measured by PRs) does
> not show much activity using np.matrix.
>
> Perhaps most importantly, there don't seem to be any courses being run
> this semester that have students creating PRs using np.matrix.
>
> And thanks Marten, Sebastian and Chuck for the nudge to find a way to move
> forward with the deprecation process. I think the change to
> `VisibleDeprecationWarning` is a good next step. Hopefully we don't have to
> wait another 7 years for the following step unless we decide that keeping
> that code in numpy is the best way to go. No one seems to have argued for
> just leaving np.matrix in the package forever, but I think it is a
> reasonable approach (similar to stating that RandomState will remain
> forever). But given the decline in usage, and the negative impacts of
> having multiple interfaces to array-like objects, it is probably better to
> stop supporting matrix at some point.
>
> Summary:
> It seems like eventually removing np.matrix is desirable. The choice of
> removing versus separating depends somewhat on how easy that is for both
> devs, and for users. It might be worth a short exploration to see if there
> is a solution. We should time this so it doesn't negatively impact the
> transition SciPy sparse is making. They are the main users, and leaving
> np.matrix as it is costs very little.
>
> Action items from this discussion include:
> - Exploring impact on SciPy of a change to `VisibleDreprecationWarning`,
> possibly followed by a PR to make the change.
>
When something gets deprecated in NumPy, as a rule we remove it in SciPy
immediately. We could _maybe_ postpone full removal for a bit, but I don't
really see a way to keep sparse matrices around if `np.matrix` gets a
visible deprecation warning. The most conservative open source project
which depends on sparse matrices is probably scikit-learn, so I'd suggest
getting an answer from the scikit-learn team about what the minimum
timeline is that they can live with for first deprecation and then removal
of sparse matrices.
Cheers,
Ralf
> - Investigating a light-weight, simple separation package that wouldn't
> affect user experience much. If that's hard, then we have identified the
> pain points. If that's easy then it informs the choice of a path forward
> for both matrix and spmatrix.
> - Collect info about the current usage of np.matrix, and what type of
> usage the large existing codebase needs. Put that info into a NEP, along
> with a summary of the history and current discussion, and a description of
> our exploration into possible light-weight routes to separation.
>
> I don't expect this to be soon -- maybe by next summer -- unless other
> people get involved. I'm interested in further discussion and suggestions
> too.
>
> FYI Chuck: It looks like Event Horizon Telescope doesn't use np.matrix at
> all any more.
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: ralf.gomm...@gmail.com
>
