-
Notifications
You must be signed in to change notification settings - Fork 260
MRG: add routine to deprecate with from/to versions #479
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Current coverage is 94.42% (diff: 100%)@@ master #479 diff @@
==========================================
Files 161 164 +3
Lines 21321 21597 +276
Methods 0 0
Messages 0 0
Branches 2284 2295 +11
==========================================
+ Hits 20100 20394 +294
+ Misses 801 783 -18
Partials 420 420
|
@functools.wraps(func) | ||
def deprecated_func(*args, **kwargs): | ||
if expired: | ||
raise expired_class(message) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't better place for this check within outer decorator itself? So you don't wait for it to be used but indicate to developers/yourself that it is time to really remove it completely?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My worry is that someone (presumably me) will forget to remove them in time, and some code will get out into the wild in that state. In that case, then the error will only occur if they try and use the functions that they shouldn't be using, instead of completely breaking the module import.
I think all these functions have their deprecations checked, so they should generate a test error when they expire.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was kinda the point - now codebase has methods which should have been gone awhile back. Since bookings is using them, nothing is removed. As long as you run tests on 'to be released' version (easy to do by just pushing a PR with to be released changes), you will know that those functions must be removed. I guess I will also use it eg in duecredit where releases are done from successfully built tagged pushes to github. If build/release would fail - I would know that I had to remove some
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But overall out is up to you of cause! Just kinda defeats the original cause/purpose of my whining ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right - but don't forget - tests will fail as soon as the version goes over the version where deprecation ends. So, even if I release a version where I forgot to remove the function, as soon as I start the next development version, on the commit after the release, the tests will fail. That way I get to see that I forgot, without giving the user code which won't import.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. That is if you do have a test for every deprecated function. I didn't look at coverage of those functions, but overall coverage is not 100% (no pun intended, coverage is exemplary high) so some might be sneaking in.
But that is again is all fine with me ;-)
I guess note it is time also to annotate those which issue deprecation warning already. Paired within this PR would provide usecase testing ;-) |
Just doing that now - should be done in an hour or so. |
b527e25
to
b24e459
Compare
b24e459
to
385e68b
Compare
dd14a0b
to
ca51667
Compare
OK - I believe all deprecation warnings are covered by the tests, and are versioned. |
ca51667
to
00d4e18
Compare
00d4e18
to
39fbd6b
Compare
39fbd6b
to
26e1ab4
Compare
@deprecate_with_version('get_header method is deprecated.\n' | ||
'Please use the ``img.header`` property ' | ||
'instead.', | ||
'2.1', '4.0') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was at least deprecated in the docs at 2.0.0. Is this meant to indicate the first release a warning was raised?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I was assuming that no-one was reading the docs, and so dated the deprecation from the first warning.
Should be deprecating SpatialImage.get_affine. |
Weird: I'm seeint Maybe it should be removed on a shorter time-scale than 4.0, though, since it's pretty unlikely people would be using that at this point. |
@deprecate_with_version('get_shape method is deprecated.\n' | ||
'Please use the ``img.shape`` property ' | ||
'instead.', | ||
'1.2', '3.0') | ||
def get_shape(self): | ||
""" Return shape for image | ||
|
||
This function deprecated; please use the ``shape`` property instead |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think deprecate_with_version
adds to the docstring?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point.
Good catch with |
26e1ab4
to
51e12ae
Compare
@deprecate_with_version('get_header method is deprecated.\n' | ||
'Please use the ``img.header`` property ' | ||
'instead.', | ||
'2.1', '4.0') | ||
def get_header(self): | ||
""" Get header from image | ||
|
||
Please use the `header` property instead of `get_header`; we will | ||
deprecate this method in future versions of nibabel. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another docstring warning.
@deprecate_with_version('read_img_data deprecated.' | ||
'Please use ``img.dataobj.get_unscaled()`` instead.' | ||
'2.0.1', | ||
'4.0') | ||
def read_img_data(img, prefer='scaled'): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function also has a docstring deprecation notice.
51e12ae
to
f1e660d
Compare
5bc5904
to
b2512e9
Compare
b2512e9
to
638a6ad
Compare
I refactored the deprecation warning machinery - now in |
pass | ||
|
||
|
||
deprecate_with_version = Deprecator(cmp_pkg_version) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you want the warning class to be VisibleDeprecationWarning
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't planning on it. Numpy uses these for deprecations where the user is probably making a coding error. We could promote all our deprecations, but that might be noisy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gotcha. Just didn't see where it was being used. I'll have a more thorough review of the whole thing, now I'm awake again.
Review complete. |
Add function to compare our package version to others. We'll use this to see whether the deprecations have expired.
Add deprecation class and function that allows you to specify at which version deprecation began, and at which version deprecation will raise an error.
Check that dev version doesn't trigger error from deprecation decorator.
Replace `np.deprecate_with_doc` with `deprecate_with_version`. There are other deprecations around the code-base that could be signalled with this decorator.
It was already broken, and has been deprecated since version 1.0.
Specify version at which DeprecationWarning was first raised, and planned version for removal. Add tests for some deprecations that were not being tested.
Thanks to Chris M for reminding me.
ECAT overriding deprecated (now removed) from_filespec method in SpatialImages. Deprecate pending removal.
638a6ad
to
f82e217
Compare
Thanks for the review - I've extended the docstrings / comments a bit to make it clearer what I was trying to do. |
Got it. LGTM. |
Thanks a lot for the review. |
Add deprecation routine that allows you to specify at which version
deprecation began, and at which version deprecation will raise an error.