@rgommers can you comment on what you intend for downstream libraries like dask to do?

Thanks for the ping @jsignell. Your solution in this PR (just reimplementing the namedtuples) looks like the right one to me. These results classes were never intended to be public, and weren't really public either (stats.stats is just a namespace that was always missing underscores). See scipy/scipy#13118 for a discussion on whether these objects should be added to scipy.stats or not.

Thanks! Ok one more question @rgommers:

Is scipy.stats.linalg.MatrixLinearOperator meant to be public? It looks like it is a possible output of aslinearoperator so it would be surprising to me if it is purposefully private.

Is scipy.stats.linalg.MatrixLinearOperator meant to be public? It looks like it is a possible output of aslinearoperator so it would be surprising to me if it is purposefully private.

That may be an oversight, but I'm not sure. LinearOperator and aslinearoperator are in the sparse.linalg namespace, MatrixLinearOperator and IdentityOperator are the two non-underscored objects in _interface.py that are not in sparse.linalg. That said, they're also not in the docs and don't have direct test coverage, which is an indication that they weren't meant to be public.

MatrixLinearOperator is a specialization of LinearOperator, so I'm wondering if you have a use case where you need the former and can't use the latter? If so, I'm happy to propose making it public.

@jsignell were there more changes you wanted to make here?

The changes in this PR kind of work, but they brought up a larger question of how the dask-scipy integration should work. That conversation is happening in #8702

Ok based on #8702 (comment) I have removed all references to LinearOperator so I think this is good to go.