review comments: general

[grlee77]

Hi @OverLordGoldDragon

I haven't gotten a chance to look at this in much detail yet, but here are some initial overall comments regarding the code.

General comments

• 1.) This toolbox reimplements its own CWT. Is it possible to reuse the one already in PyWavelets?
  I know there are some numerical limitations to the CWT as currently implemented in PyWavelets (e.g. Complex Morlet wavelet in CWT is not symmetric at fractional scale PyWavelets/pywt#535, precision of CWT PyWavelets/pywt#531). I don't yet know if these are specifically a problem for this application.
  Alternatively, would the SciPy implementation work?

• 2.) PyWavelets uses the Numpydoc for docstrings as described at:https://docs.scipy.org/doc/numpy-1.15.0/docs/howto_document.html

I wouldn't make refactoring the docstrings a first priority though (The same applies for PEP8 issues)

• 3.) It would be good to make the argument handling more Pythonic.
  For example, rather than specify opts=None or opts={} and then parse it with a _get_opts helper, I would explicitly make the signature of synsq_cwt_fwd

def synsq_cwt_fwd(x, t=None, fs=None, nv=32, type='morlet', difftype='direct', gamma=None)```

so that it is easy for the user to determine the names and defaults of all options.

The same applies to the various other functions such as synsq_squeeze that are called within. It is better to explicitly list the arguments by name than hiding them within an opts dictionary.

[bluenote10]

For example, rather than specify opts=None or opts={} and then parse it with a _get_opts helper, I would explicitly make the signature of synsq_cwt_fwd

That would be very helpful indeed, and much more idiomatic. Note that passing a bunch of parameters around internally can still be done in a grouped fashion by putting them in a dict kwargs = dict(type=type, difftype=difftype, ...) which is then passed around via **kwargs.

[OverLordGoldDragon]

@bluenote10 Agreed, changed my mind since last time; opts's getting ditched.