On Fri, Jan 6, 2017 at 11:59 PM, Ralf Gommers <ralf.gomm...@gmail.com> wrote: > > > On Sat, Jan 7, 2017 at 2:52 PM, Charles R Harris <charlesr.har...@gmail.com> > wrote: >> >> >> >> On Fri, Jan 6, 2017 at 6:37 PM, <josef.p...@gmail.com> wrote: >>> >>> >>> >>> >>> On Fri, Jan 6, 2017 at 8:28 PM, Ralf Gommers <ralf.gomm...@gmail.com> >>> wrote: >>>> >>>> >>>> >>>> On Sat, Jan 7, 2017 at 2:21 PM, CJ Carey <perimosocord...@gmail.com> >>>> wrote: >>>>> >>>>> >>>>> On Fri, Jan 6, 2017 at 6:19 PM, Ralf Gommers <ralf.gomm...@gmail.com> >>>>> wrote: >>>>>> >>>>>> This sounds like a reasonable idea. Timeline could be something like: >>>>>> >>>>>> 1. Now: create new package, deprecate np.matrix in docs. >>>>>> 2. In say 1.5 years: start issuing visible deprecation warnings in >>>>>> numpy >>>>>> 3. After 2020: remove matrix from numpy. >>>>>> >>>>>> Ralf >>>>> >>>>> >>>>> I think this sounds reasonable, and reminds me of the deliberate >>>>> deprecation process taken for scipy.weave. I guess we'll see how >>>>> successful >>>>> it was when 0.19 is released. >>>>> >>>>> The major problem I have with removing numpy matrices is the effect on >>>>> scipy.sparse, which mostly-consistently mimics numpy.matrix semantics and >>>>> often produces numpy.matrix results when densifying. The two are coupled >>>>> tightly enough that if numpy matrices go away, all of the existing sparse >>>>> matrix classes will have to go at the same time. >>>>> >>>>> I don't think that would be the end of the world, >>>> >>>> >>>> Not the end of the world literally, but the impact would be pretty >>>> major. I think we're stuck with scipy.sparse, and may at some point will >>>> add >>>> a new sparse *array* implementation next to it. For scipy we will have to >>>> add a dependency on the new npmatrix package or vendor it. >>> >>> >>> That sounds to me like moving maintenance of numpy.matrix from numpy to >>> scipy, if scipy.sparse is one of the main users and still depends on it. > > > Maintenance costs are pretty low, and are partly still for numpy (it has to > keep subclasses like np.matrix working. I'm not too worried about the > effort. The purpose here is to remove np.matrix from numpy so beginners will > never see it. Educating sparse matrix users is a lot easier, and there are a > lot less such users. > >> >> What I was thinking was encouraging folks to use `arr.dot(...)` or `@` >> instead of `*` for matrix multiplication, keeping `*` for scalar >> multiplication. > > > I don't think that change in behavior of `*` is doable.
I guess it would be technically possible to have matrix.__mul__ issue a deprecation warning before matrix.__init__ does, to try and encourage people to switch to using .dot and/or @, and thus make it easier to later port their code to regular arrays? I'm not immediately seeing how this would help much though, since there would still be this second porting step required. Especially since there's still lots of room for things to break at that second step due to matrix's insistence that everything be 2d always, and my impression is that users are more annoyed by two-step migrations than one-step migrations. -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
