Final pass over the deprecated public modules

[pavyamsiri]

This should fully close issue #48. See the list at the end of the comment to see all of the modules that are public but are going to be deprecated. I found them by looking at the top most comment that says that they will be deprecated in v2.0.0 in the actual scipy git repo. Tell me if I should just add the list to my original issue instead.

This PR should address the rest of the modules not stubbed out by #54.

Problems with merging

It seems that @jorenham has already tried to stub out some of the deprecated modules already so there are conflicts that need to be addressed.

List of all deprecated public modules

There are 109 such modules in total.

• signal.ltisys
• signal.spectral
• signal.waveforms
• signal.bsplines
• signal.fir_filter_design
• signal.signaltools
• signal.wavelets
• signal.lti_conversion
• signal.filter_design
• signal.windows.windows
• sparse.coo
• sparse.data
• sparse.sparsetools
• sparse.dok
• sparse.csr
• sparse.compressed
• sparse.lil
• sparse.spfuncs
• sparse.extract
• sparse.base
• sparse.sputils
• sparse.construct
• sparse.bsr
• sparse.dia
• sparse.csc
• sparse.linalg.interface
• sparse.linalg.matfuncs
• sparse.linalg.dsolve
• sparse.linalg.eigen
• sparse.linalg.isolve
• constants.codata
• constants.constants
• interpolate.fitpack2
• interpolate.dfitpack
• interpolate.fitpack
• interpolate.polyint
• interpolate.interpolate
• interpolate.ndgriddata
• interpolate.rbf
• optimize.linesearch
• optimize.minpack
• optimize.slsqp
• optimize.tnc
• optimize.cobyla
• optimize.optimize
• optimize.lbfgsb
• optimize.zeros
• optimize.minpack2
• optimize.nonlin
• optimize.moduleTNC
• linalg.matfuncs
• linalg.decomp_lu
• linalg.decomp_svd
• linalg.decomp_qr
• linalg.decomp_schur
• linalg.decomp
• linalg.basic
• linalg.misc
• linalg.special_matrices
• linalg.decomp_cholesky
• odr.models
• odr.odrpack
• misc.common
• misc.doccer
• fftpack.realtransforms
• fftpack.helper
• fftpack.pseudo_diffs
• fftpack.basic
• io.idl
• io.mmio
• io.harwell_boeing
• io.netcdf
• io.matlab.mio_utils
• io.matlab.mio4
• io.matlab.mio5_params
• io.matlab.mio
• io.matlab.mio5_utils
• io.matlab.streams
• io.matlab.byteordercodes
• io.matlab.mio5
• io.matlab.miobase
• io.arff.arffread
• stats.kde
• stats.morestats
• stats.mvn
• stats.mstats_extras
• stats.biasedurn
• stats.stats
• stats.mstats_basic
• ndimage.morphology
• ndimage.fourier
• ndimage.interpolation
• ndimage.filters
• ndimage.measurements
• integrate.vode
• integrate.dop
• integrate.odepack
• integrate.quadpack
• integrate.lsoda
• special.specfun
• special.add_newdocs
• special.basic
• special.spfun_stats
• special.sf_error
• special.orthogonal
• spatial.qhull
• spatial.kdtree
• spatial.ckdtree
• spatial.transform.rotation

[jorenham]

Wow great, thanks for this!

In the future you could avoid such conflicts by splitting it up by e.g. package. Just to be clear; I'm not saying you should split this one up or anything, but it's just something I've been trying to do myself 🤷🏻‍♂️

[jorenham]

I found them by looking at the top most comment that says that they will be deprecated in v2.0.0 in the actual scipy git repo. Tell me if I should just add the list to my original issue instead.

At this early development stage there's no need to worry about formalities too much.
So as far as I'm concerned you can do whatever you think is best in this case 👌🏻

[jorenham]

It seems that @jorenham has already tried to stub out some of the deprecated modules already so there are conflicts that need to be addressed.

My earlier changes were mostly directed to fixing the failing stubtest, which has some unavoidable overlap with your work on the deprecations.
The merge conflicts look very minimal, and you changes are clearly an improvement in those cases.

[jorenham]

Oh and quick little DRY idea I had in the case of deprecated classes, is to e.g.

from typing_extensions import deprecated
from ._ckdtree import cKDTree as _cKDTree

@deprecated("Lorem ipsum")
class cKDTree(_cKDTree): ...

I believe that this is "correct enough", at least as far as stubtest and pyright concerned

[pavyamsiri]

Wow great, thanks for this!

In the future you could avoid such conflicts by splitting it up by e.g. package. Just to be clear; I'm not saying you should split this one up or anything, but it's just something I've been trying to do myself 🤷🏻‍♂️

That's a fair suggestion. I think I thought it would be too many PRs but in hindsight the monolithic nature of this PR is also a problem in and of itself.

[jorenham]

the monolithic nature of this PR is also a problem in and of itself.

oh don't worry it about it; if this woould've been e.g. a numpy PR then it would've been a different story, but at this point in scipy.stubs I really don't mind

[pavyamsiri]

Oh and quick little DRY idea I had in the case of deprecated classes, is to e.g.

from typing_extensions import deprecated
from ._ckdtree import cKDTree as _cKDTree

@deprecated("Lorem ipsum")
class cKDTree(_cKDTree): ...

I believe that this is "correct enough", at least as far as stubtest and pyright concerned

Ah this is very helpful. Should cut down on the file size as well.

I tried to shadow the inheritance structure at first but I got warnings about using deprecated classes from a lint so I ended up having to stub out every single method and inherited method as well.

I really should have just tried what you just did though.

[jorenham]

Maybe it could help to have the deprecated OptimizeResult classes inherit from typing_extensions.Any, so that typecheckers will allow accessing any attribute, instead of none?

And I spotted one or two deprecated OptimizationWarning without a base class, otherwise it won't be usable in e.g. warnings.catch_warnings

[pavyamsiri]

Maybe it could help to have the deprecated OptimizeResult classes inherit from typing_extensions.Any, so that typecheckers will allow accessing any attribute, instead of none?

And I spotted one or two deprecated OptimizationWarning without a base class, otherwise it won't be usable in e.g. warnings.catch_warnings

It doesn't seem like you can inherit typing_extensions.Any. mypy seems to think that you can't at least.

[jorenham]

It doesn't seem like you can inherit typing_extensions.Any. mypy seems to think that you can't at least.

I believe it's a basedmypy thing.
You could supress that error with # type: ignore[no-subclass-any]

---

edit:

it's a basedmypy thing:
https://kotlinisland.github.io/basedmypy/error_code_list3.html#don-t-subclass-any-no-subclass-any

[jorenham]

I kinda like your commit message style btw; maybe I'll adopt it here myself 🤔

[pavyamsiri]

I kinda like your commit message style btw; maybe I'll adopt it here myself 🤔

Thanks! Although I am not really too consistent with it. I mostly got it from looking at other repos, so I don't have a good grasp of the exact style.

[jorenham]

Ready to merge?

[pavyamsiri]

Should be all good now.

[jorenham]

OK great, thanks a lot @pavyamsiri !