Add decorator for deprecation tests#105
Conversation
|
I'm proposing a slightly different approach (which works in my head but did not test this out). Because the decorator runs at import time, we may be able to do two improvements
MVP: And use it as |
I like this functionality, except that this only works for this specific kind of deprecation (renaming a function). If we want to go with this approach and have different decorators for different types of deprecation then we could also just go whole hog and use a library like pyDeprecate. |
I think it's an improvement over the current PR and should handle rename/removal which are the most common scenarios. Anything more than this then probably will require a more complex solution -- generally I would prefer not adding another dependency for something like this. I just find it clunky to have to add a new test for each deprecation. |
|
Implemented your suggestions @ewu63 |
Purpose
When we make a backward incompatible change in our code (e.g changing the name of a function or argument), it is good practice to implement a "shim" so that code following the old API still works, then remove that shim in a later release (usually 2 minor versions later). However, we don't currently do anything to actually remind us to remove these shims.
This PR adds a decorator that both handles the deprecation warning, and raises an error if the shim is still present once the relevant package reaches the version the shim is supposed to be removed in.
e.g:
When called in version < 1.20:
When called in version >= 1.20:
Expected time until merged
Type of change
Testing
Checklist
ruff checkandruff formatto make sure the Python code adheres to PEP-8 and is consistently formattedfprettifyor C/C++ code withclang-formatas applicable