issues to address in moving towards 0.3.0

[grlee77]

I opened this issue as a place for us to add/discuss issues to address for a future 0.3.0 release.

I took a quick look at a diff of current master and @nigma's pywt. It looks like the majority of the code should already be backwards compatible (and it already works with Python 3).

Here are a few issues I think need to be addressed:

• A copy of six was included as _tools/six.py. It appears to only currently be used to import string_types here:
  https://github.com/rgommers/pywt/blob/496fab3ad1cc6fd35f359d560c9b0e4fa40da8a2/pywt/src/_pywt.pyx#L23
  Should we: 1.) keep this as a local copy, 2.) add six as a dependency, 3.) just define string_types directly ourselves?
• current master already has one new function (idtwn) in multidim.py. Should this be kept in the initial v0.3.0 release because was already committed? We can change to the more efficient implementation I proposed in added wavedecn and waverecn to multilevel.py #52 for a later release.
• In thresholding.py, the individual functions soft, hard, greater, less have been replaced with a single function called threshold that has a 'mode' argument to determine the threshold type.
  Should we provide wrappers with the old names for backwards compatiblity?
  i.e.

def soft(data, value, substitute=0):
    return threshold(data, value, mode='soft', substitute=substitute)

Backwards compatiblity would also require adding the following to __init__.py:

import tresholding

so that these would be called as pywt.thresholding.soft as in the old API

[kwohlfahrt]

• I would define string_types if it is necessary. On a quick check, it is only used to pre-screen inputs to MODES.from_object, and raises a TypeError if they are out of range or not stringy. MODES.from_object also checks whether they are in range, and getattr raises a TypeError anyway (python3 at least) if called with a non-string - unless Cython behaves differently I think this can be removed. I'll play with it in a couple of days.
• No strong opinion on idwtn. I need it but I'll be using git master anyway so little difference.
• Yes, I would define the old names (personally I would use functools.partial)

I would like to get #59 merged, just need to figure out how to define the CFLAGS for old gcc (gcc >= 5.1 defaults to -std=gnu11, which is sufficient).

[grlee77]

I agree on functools.partial.
I haven't had a chance to review #59 yet, but will try to get to it this week.

[rgommers]

I'd keep idwtn. The v0.3.0 release should be fully backwards-compatible, but I don't see a reason not to add anything new. Removing it now and then re-adding it seems like effort that could be better spent elsewhere to me.

[rgommers]

I've created v0.3.0 and v0.4.0 Milestones that we can tag issues and PRs with.

[rgommers]

Agree on adding back the old names with functools.partial.

[rgommers]

@kwohlfahrt is there a good reason to want to merge gh-59 right before instead of right after tagging v0.3.0? If not, I'd prefer after in order to reduce the risk (it's the kind of large PR that potentially can introduce a regression).

[kwohlfahrt]

I have some other stuff brewing on top of it that I would have then put towards the next release, and given that #59 doesn't change any internal or external interfaces I thought it would be OK to merge for a backwards compatible release.

That was it, if you think it's too risky then we can postpone it too.

[kwohlfahrt]

Also having had a closer look, I'm going to disagree with everybody (including my past self). Given that thresholding.threshold is essentially a switch and the different modes share no code, I think it would make more sense to restore the individual functions, and then simply call out to them from the combined one. Will open a PR tomorrow.

[rgommers]

All issues discussed here are resolved, so how about tagging v0.3.0 tomorrow?

Regarding releases, I propose to just use the Github Releases feature (can add release notes and source code / binaries at https://github.com/rgommers/pywt/releases).

Furthermore we need something on PyPi. I'd like to just https://pypi.python.org/pypi/PyWavelets instead of a renamed fork (seems better for users), but that we need permission from @nigma. I'll open an issue about that on his repo.

[rgommers]

Opened nigma/pywt#13 for PyPi access.

[rgommers]

At least one more thing to do before tagging the release: update the metadata in setup.py (author, download url, supported Python versions, etc.).

[rgommers]

This is all done, so closing.

[rgommers]

Tagged and sources on PyPi and https://github.com/PyWavelets/pywt/releases/tag/v0.3.0 now. Still want to produce some Windows wheels and put them on PyPi, after that send the release announcement.