Discussed on call. OK to go ahead with this. Vendor GaussianKDE and make the current version private.@oscargus if you were still interested in pulling this out as a toolbox that would be fine as well, but we will deprecate here. Maybe if the toolbox is set up we can change the deprecation messages to point to it?

@jklymak I'm interested in a toolbox with related functions, yes. While these may not be the ones I use and focus, it may very much make sense to add them there.

I'll see if I can come up with something quite soon, at least before 3.6... Not sure if we should wait with merging this until we can point to it (matplotlib/mpl-signal or something) or if we simply should prepare a new PR later on and merge this when (if) decided.

I don't think there is a rush for the deprecation if you think you will have something in a couple of months.

oh, hold it, do we still not require scipy as a hard requirement

I'm certainly OK with deprecating spectral functions from mlab, but I would much rather not add a dependency on scipy. While conda is mostly always available these days, in the rare cases where it's not and no wheels are available (e.g. shortly after new python releases), compiling scipy can be a huge pain (due to the fortran parts), much worse than numpy and matplotlib.

Yes, that was the consensus on the call - just vendor GaussianKDE. The other functions thatshould depend on scipy, but do not, will just be flat out deprecated, and maybe moved to a different toolbox if people really complain about the lack of apsd function.

If we want to have a signal related toolkit it makes the most sense for it to be a stand-alone package so you can apologetically depend on scipy!

Started a bit on the toolbox:https://github.com/oscargus/mplsignal so can easily move relevant functions there when needed. (I expect to maybe release a first version in a few weeks and may ask to have it move to the mpl organization before that as I expect to move it at some stage anyway,)

Btw, the idea is to not depend on scipy there either (even though some functions are customized to fit exactly into some scipy-functions likefreqz that has a plot-callback), so at least provide some fallback functions.

I'm completely befuddled as to why this PR fails font-name tests. I rebased off master, and I don't see any way I touched font handling. Something weird is going on...

I realized that we either should deprecate the corresponding functions in pyplot/Axes as well or make sure that they use the non-deprecated versions directly from numpy (where possible) or scipy (and fail gracefully if it is not installed).

I could open a PR using the numpy functions directly if that is the preferred solution (but will not spend time otherwise).

Edit: I was a bit too quick here and realize that it is onlyxcorr andcohere that relies onmlab. Still it would require some change. Probably we should keep windows and detrends?

Edit 2: But considering that the tests are removed, which are really tests for pyplot functions, there is still an issue to consider here.

I realized that we either should deprecate the corresponding functions in pyplot/Axes as well or make sure that they use the non-deprecated versions directly from numpy (where possible) or scipy (and fail gracefully if it is not installed).

We should definitely deprecate those!

...done.

What's the status here? Is this dependent on mplsignal being released on PyPI? (It doesn't seem to be there yet.)
Normally the tests should only be removed when the implementations are removed too (they should be protected withwith pytest.warns(...): in the meantime)?

What's the status here? Is this dependent on mplsignal being released on PyPI? (It doesn't seem to be there yet.)

I don't think this should wait for a replacement package.

Normally the tests should only be removed when the implementations are removed too (they should be protected with with pytest.warns(...): in the meantime)?

OK, I can do that

In the long-term, will GaussianKDE live in another module? Or will mlab stay around to host it?

It probably should get put somewhere else, but seems a bit cumbersome to move it now.

Normally the tests should only be removed when the implementations are removed too (they should be protected with with pytest.warns(...): in the meantime)?

OK, I can do that

Actually thats a pretty huge PITA - test_mlab has >100 tests, most of which now fail due to the deprecation warning.... Surely I don't have to wrap them all in awith pytest.warns(...): ?

I think(?) you can use a pytestmark (https://docs.pytest.org/en/7.1.x/example/markers.html#marking-whole-classes-or-modules) with a custom warningsfilter mark (https://docs.pytest.org/en/7.1.x/how-to/capture-warnings.html#pytest-mark-filterwarnings, see alsohttps://docs.python.org/3/library/warnings.html#describing-warning-filters for syntax).

OK, tests marked to filter deprecation warnings. I assume we don't need to wrap the individual calls to allowother deprecation warnings to be caught, so this should be fine. This needs a rebase before merging to undo the files that were removed and then added.

This one is a bit annoying to drag from milestone to milestone. I still feel we should deprecate all this, but if we aren't going to do it, then let's close the PR. Thanks!

... we are about to feature freeze for 3.7 - if we would like this change, now is the time to do it, otherwise, we can close this...

I should be able to get it into mplsignal and make a first release during the holidays.

OK, I'll close this as I don't see it getting in before 3.7 is frozen, and I'm not willing to rebase it to 3.8. I think we should not be providing this, but understand if folks want to keep it around.