[Numpy-discussion] next NumPy triage meeting - October 16th, 2024 at 18:00 UTC

[Inessa Pawson via NumPy-Discussion]

The next NumPy triage meeting will be held this Wednesday, October 16th at
18:00 UTC. This is a meeting where we synchronously triage prioritized PRs
and issues.
Join us via Zoom:
https://numfocus-org.zoom.us/j/82096749952?pwd=MW9oUmtKQ1c3a2gydGk1RTdYUUVXZz09
.
Everyone is welcome to attend and contribute to a conversation.
Please notify us of issues or PRs that you’d like to have reviewed by
adding a GitHub link to them in the meeting agenda:
https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg.

-- 
Cheers,
Inessa

Inessa Pawson
GitHub: inessapawson
___
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: arch...@mail-archive.com

[Numpy-discussion] What to do with np.matrix

[Dan Schult]

Hello everyone,
I've been helping scipy.sparse provide a sparse array interface along-side
sparse matrix.
With that effort making good progress, we are starting to think about
bigger implications.

Now may be a good time to reconsider *what to do with np.matrix*.
I think we have three options:

1) Leave np.matrix as is (with the docs discouraging its use)
2) Deprecate and then remove np.matrix
3) Split np.matrix out as a separate library `numpy-matrix` (maybe
eventually with spmatrix)

(Below, I've listed some arguments for each option from previous mailing
list conversations.)

I'm planning on writing a NEP to summarize the discussion that follows,
before proceeding
with any work. I'd appreciate your feedback on the feasibility of the above
options, or
ideas for other options to consider.

Thank you!
Dan

===
*From previous conversations (links below):*

Reasons for *1) leave as is*:

- Nothing needs to be done.
- Use for np.matrix is declining anyway.
- Old code can still use np.matrix without any changes.

Reasons for *2) remove np.matrix*:

- “The purpose here is to remove np.matrix from numpy so beginners will
never see it.“
- Option 3) has little payoff if the “teaching advantages” of np.matrix are
largely addressed by `@`.
- Slightly less maintenance time after the removal. (But more to remove it.)

Reasons for *3) numpy-matrix library*:

- Allows/Forces old code to switch once to `npm.matrix` (better than
multiple times, worse than never).
- Old code can start to switch now… and will still work for any previous
numpy version.
- Devs still have to maintain the code.
- Beginners do not see npm.matrix when starting with numpy. But still
available.


*Details and summary of history:*

*Q*: Why now? *A*: We have made progress with handling np.matrix:
   - Python 2.7 is no longer supported
   - @ is now available
   - Docs now suggest that np.matrix should not be used for new code
   - Docs are largely free of np.matrix (but not all – subclass examples
use np.matrix)
   - Scipy.sparse supports sparray (spmatrix is still there too)
   - Array API sets expectations for containers.
   - We have the history of numpy-financial as a previous split-off library.

Previous discussion ideas not yet implemented: (Many others are already
implemented)
- “The purpose here is to remove np.matrix from numpy so beginners will
never see it.“
- Easy for linear algebra, but later hard to extend to powerful
ideas of ndarrays.
- `@` should make ndarray easy enough for linear algebra.
- 3 different semantics for ndarray, matrix, spmatrix. Matrix does evil
by existing.
- Teaching concerns: `np.matrix` has powerful (readable) notation for
matrix mult,
  pow, and inverse. Most agree that `@` is all that’s needed.
  The `pow` and `inv` methods are OK.
   - Idea: Split out np.matrix as a library `numpy-matrix`-> npm.matrix
   - Make the new library look at numpy version and if old, use np.matrix
code.
  If numpy is new, use npm.matrix code. (Allows people to switch their
code
  while still supporting old numpy. Creates pointers to np.matrix for
type
  checking, etc.)
   - Remove remaining examples of np.matrix from numpy docs.
- `spmatrix` and `np.matrix` are linked. Sometimes `spmatrix` returns
`np.matrix`.

*Links:*
- 2017 mailing list thread

- 2014 mailing list thread

- The mailing list in 2008 has multiple threads related to np.matrix.
Most posts are not directly related to this question.
But if you search the archives for "2008 np.matrix" you will find lots of
discussion.
___
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: arch...@mail-archive.com

[Numpy-discussion] Re: What to do with np.matrix

[Marten van Kerkwijk]

Hi Dan, others,

Great news that the sparse array implementation is getting there!
The continued existence of np.matrix has in large part been because of
sparse matrices, so in some sense the decision depends also on what
happens to those.

But generally I'm in favour of just deprecating and removing matrix, as
I don't see any advantages. But admittedly I'm biased: I was the one
that added the PendingDeprecationWarning, and attempted to consolidate
at least all the tests in matrixlib to make eventual deprecation easier...

Regardless, since there have been 7 years of PendingDeprecationWarning,
I think changing that to a regular DeprecationWarning should not
surprise anybody, at least not if they had built a package based on
np.matrix.

It is maybe good to add that it is less easy to split of matrix into its
own package than it was for the financial routines: because matrix
overrides some pretty basic assumptions of arrays (mostly how shapes
behave), there are bits of special-casing for np.matrix throughout the
rest of the code, which we would want to remove if np.matrix is no
longer part of numpy.  I.e., moving it might mean having to define
``matrix.__array_function__`` and override those functions. This means a
new package would need a bit of a champion.

All the best,

Marten
___
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: arch...@mail-archive.com