I'm concerned by the addition of a different class instead of relying on our Axes class. I don't see the advantage, and the inconvenience is that this not coherent at all with the current API. Had this been discussed elsewhere?

It's nice--but it looks to me like this is heading towards being an independent toolkit package rather than something that should be included in the main matplotlib repository. The heart of it is a specialized set of calculations; the plotting is almost incidental. We want to move matplotlib towards being a general plotting library, and delegate analysis calculations and specialized plotting to other libraries. This could be very useful as one of those other libraries.

Aren't lot of these calculations inscipy.signal? I agree w/ @NelleV and @efiring that the calculations and plotting should be kept as separate as possible.

We just had a conversation about these fncs on gitter. The consensus seemed to be to try and deprecate the mlab functions, and move the _axes methods to just call the scipy.signal functions. It probably needs its own issue, or further discussion in #9151

I think in an ideal world Matplotlib would just call scipy methods where possible. The problem is Matplotlib doesn't depend on scipy because historically installing scipy was difficult. So, the decision that I think needs to be made before we go any further with the mlab spectral code is is

Should Matplotlib expect users who want to plot spectral data to have an installation of scipy?

• If the answer is yes, then the spectral functions need an overhaul and major API change to conform to scipy
• If the answer is no, we can stick with the current functions and work on something like this PR.

I do agree that it probably would be better to utilize the scipy.signal functions though I think the worries about complexity are not really substantiated (we are talking about maybe less than fifty lines of algorithmic code). The majority of the code (minus the examples) is consistency checking and emitting meaningful error messages.
What makes spectral analysis difficult is the required attention to detail of parameters and scaling (If I counted right, there are 9 parameters for a periodogram and 18 scalings of the y-axis). So I'm not sure if the plotting is incidental as @efiring claimed. I believe automatically providing the essential information in the plot (precise label names, correct units, frequency resolution, etc) lowers the learning curve for beginners considerably. I know this contradicts a bit the goal stated by @jklymak of separating calculation and plotting as much as possible.
So besides the question of the dependency of SciPy raised by @dstansby I would add the question: Is it worthwhile for Matplotlib to provide a less antiquated, low-level and more pythonic interface for basic spectral analysis. If this PR is anywhere near the sweet spot is of course a point of further discussion.

It looks like none of @NelleV @efiring @jklymak (as well as myself) believe that Matplotlib should include such a feature, and @dstansby seems to be OK either way (depending on the scipy situation). So I'll close the PR.

I also believe that this functionality belongs to a third-party module, which can be listed in the third-party packages page (https://matplotlib.org/thirdpartypackages/index.html).

Thank you for your work on this @vollbier please do not be discouraged that this is not merged!

I agree with @efiring @anntzer that this would be better suited as a stand alone package which depends on Matplotlib. The two technical benefits to this are being able have more liberal dependencies than Matplotlib (ex scipy, fftw, etc) and to operate on your own release schedule. It also lets you have a much more opinionated domain specific API. This may mean something like seaborn (/https://seaborn.pydata.org) / altair ( https://altair-viz.github.io/) which are tuned to particular data structures and statistical computations or something like windrose (https://github.com/python-windrose/windrose/) which aggressively customizes the Axes object.

The tight coupling between data / computation and the axis labels, ticks, and scales breaks some of the core abstraction of Matplotlib and poses some problems for composition (what happens if I want to show two of these plots with different windowing? That information is in the title so one of them will be labeled wrong).

The pattern of having a data / computation based object that you then call plot on is not a pattern we current have in the library (but both pandas and lmfit do!) and I am not sure we want to bring in.

I am open to it living at matplotlib/mpl-spectra (or something similar) and leaving it under your (@vollbier ) control. Examples of projects like this are https://matplotlib.org/mpl-probscale/ or https://matplotlib.org/cmocean/ .