[Numpy-discussion] Community Review #4 of the NumPy Comics
Hi all, The “How to Contribute to NumPy” comics are open for review again! Since the last review, I have added the last 6 pages, back cover and credits section. Here’s the issue link: https://github.com/numpy/numpy/issues/27375 Here’s the comic link: https://heyzine.com/flip-book/3e66a13901.html I have conducted some review sessions at the NumPy Community Call and NumPy Documentation call this and last month. The issue will be open for a few more days and will close on Thurs, Oct 17. Best, Mars ___ 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
On Mon, Oct 14, 2024 at 8:09 AM Sebastian Berg wrote: > On Sat, 2024-10-12 at 12:13 -0400, Marten van Kerkwijk wrote: > > Hi Dan, others, > > > > > > > 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. > > > `PendingDeprecationWarning` is hidden by default for all code, so only > "well maintained" libraries are unlikely to have noticed it. > I think there are warnings in the docs as well, though. So hopefully, > few new code uses it > > I am very happy to escalate (also to `VisibleDeprecationWarning`), but > the question is always how many users are affected by it and how. > And I am not that optimistic that it is few enough that we don't have > to make dealing with the change easier in some form. > > VisibleDeprecationWarning would be a good way to get things started. > > > > > 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. > > > This actually made me think a bit. We have two options (both need a > champion, and I hope we have that here in Dan). > An (almost) drop in package may indeed need `__array_function__` > because NumPy has a few `matrix` isinstance checks. > > I am slightly curious what code still uses matrix. If it is just some > localized matrix-heavy code, an incredibly light-weight replacement > might also serve the purpose well enough? > That would never pass `isinstance()` checks in third-party packages, > etc. so not sure it can work, though. > > When I looked at the Event Horizon Telescope project code, I noticed that it was using `matrix`. I don't know if that is still the case. > > In any case, overall, I am definitely in favor. The only question is > if we have to go to the trouble to create a drop-in replacement. > And for that it would be nice if we can see how easy that is, because > while tedious, it may not be all that hard. > > Probably best to stick the code somewhere in case it is needed. I should probably have done the same with the old Numeric compatibility code when I removed it. Chuck ___ 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
On Mon, Oct 14, 2024 at 9:10 AM Nathan wrote: > Here's a github code search for the string "np.matrix": > > https://github.com/search?q=%22np.matrix%22&type=code > > First, if you narrow down to just Python code, there are almost 60 > thousand results, which is quite high, much higher than we we're > comfortable with for outright removals for NumPy 2.0. > > Compared with code searches I did in service of the NumPy 2.0 API changes, > this returns a lot of repositories in the flavor of "someone's homework > assignments" rather than "core scientific python package" or "package owned > by a billion dollar corporation". > > So, it's good that "important" packages don't seem to use np.matrix much, > but also it's bad given that the code that *does* seem to use it is > probably infrequently or poorly tested, and will require a lengthy > deprecation period to catch, if the authors are inclined to do anything > about it at all. > > In that case, I think moving things to an external pypi package along with > a long-lived shim in NumPy that points people to the pypi package is > probably the least disruptive thing to do, if we're going to do anything. > > Putting the code on PyPI and leaving a shim behind would be the way to go. If nothing else it will serve to educate users as to the best current usage of NumPy. And speaking of education, we might want to do something similar with RandomState. It is amazing how many folks still think of it as the natural way to get random numbers in NumPy even though the preferred Generator based rng has been out for seven years. I think a large part of that problem comes from classrooms, books, and articles that still use RandomState, and the remainder from people who were unaware of the new capabilities. I think we could also make that transition in most of the NumPy testing code. Chuck ___ 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
On Sat, 2024-10-12 at 12:13 -0400, Marten van Kerkwijk wrote: > Hi Dan, others, > > 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. `PendingDeprecationWarning` is hidden by default for all code, so only "well maintained" libraries are unlikely to have noticed it. I think there are warnings in the docs as well, though. So hopefully, few new code uses it I am very happy to escalate (also to `VisibleDeprecationWarning`), but the question is always how many users are affected by it and how. And I am not that optimistic that it is few enough that we don't have to make dealing with the change easier in some form. > > 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. This actually made me think a bit. We have two options (both need a champion, and I hope we have that here in Dan). An (almost) drop in package may indeed need `__array_function__` because NumPy has a few `matrix` isinstance checks. I am slightly curious what code still uses matrix. If it is just some localized matrix-heavy code, an incredibly light-weight replacement might also serve the purpose well enough? That would never pass `isinstance()` checks in third-party packages, etc. so not sure it can work, though. In any case, overall, I am definitely in favor. The only question is if we have to go to the trouble to create a drop-in replacement. And for that it would be nice if we can see how easy that is, because while tedious, it may not be all that hard. - Sebastian > > 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: sebast...@sipsolutions.net > ___ 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
Here's a github code search for the string "np.matrix": https://github.com/search?q=%22np.matrix%22&type=code First, if you narrow down to just Python code, there are almost 60 thousand results, which is quite high, much higher than we we're comfortable with for outright removals for NumPy 2.0. Compared with code searches I did in service of the NumPy 2.0 API changes, this returns a lot of repositories in the flavor of "someone's homework assignments" rather than "core scientific python package" or "package owned by a billion dollar corporation". So, it's good that "important" packages don't seem to use np.matrix much, but also it's bad given that the code that *does* seem to use it is probably infrequently or poorly tested, and will require a lengthy deprecation period to catch, if the authors are inclined to do anything about it at all. In that case, I think moving things to an external pypi package along with a long-lived shim in NumPy that points people to the pypi package is probably the least disruptive thing to do, if we're going to do anything. -Nathan ___ 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
