On Mon, Oct 14, 2024 at 8:09 AM Sebastian Berg <sebast...@sipsolutions.net> wrote:
> On Sat, 2024-10-12 at 12:13 -0400, Marten van Kerkwijk wrote: > > Hi Dan, others, > > > > <snip> > > > 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
