Santiago Soler

Another idea would be to apply `fft` over indexes only, instead of looking for coordinates.

> Can you elaborate on this? `xrft` uses the raw coordinates to inform the coordinates after the fft is taken. Sure! Sorry for the brevity, now that I reread it...

If working with indexes is too complex, maybe we could just ignore these extra coordinates and apply the FFT only on the ones that are named after the dimensions of...

I've just noticed that `pad` has a similar problem: it raises a cryptic `xarray` error when trying to pad a grid with the extra `upward` coordinate. So probably a single...

I'm very interested in seeing an implementation of padding in `xrft` (as mentioned in #154). Just a minor thought. Wouldn't be better to have a separate function to apply padding...

> > I'm very interested in seeing an implementation of padding in `xrft` (as mentioned in #154). > > Just a minor thought. Wouldn't be better to have a separate...

> @santisoler Would you like to give it a go for a PR? Sure! I can tackle this. I would like to have some common thoughts about the design of...

Regarding including the padding inside `fft`, I agree with @bennyrowland. I think `pad` will end up having many more arguments than just `True`/`False`, and they could scale in the future...

> If you want to simply match the xarray `pad()` behaviour, but handling extrapolating coordinates better, then it might be more sensible to approach that directly in xarray. @shoyer for...

I agree with this! We would need to think what to do with the `extra_coords`. Any thoughts?