Skip to content
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

Feature: Specify what replaces an API call... #18

Open
BenjamenMeyer opened this issue Apr 10, 2018 · 1 comment
Open

Feature: Specify what replaces an API call... #18

BenjamenMeyer opened this issue Apr 10, 2018 · 1 comment

Comments

@BenjamenMeyer
Copy link

This looks quite interesting; however, it'd be highly beneficial to be able to optionally specify what is replacing the call.

import deprecation

@deprecation.deprecated(deprecated_in="1.0", removed_in="2.0",
                        current_version=__version__,
                        details="Reasoning for change", replaced_by=bar)
def foo():
    """Do some stuff"""
    return bar()

def bar():
    """Do some stuff using new API"""
    return 1

details could probably be used more for reasoning behind the change while replaced_by could be used to explicitly note the new method if it was provided.

NOTE: replaced_by could either be an object or a string. If an object then the string could be formed via '.'.join([replaced_by.__module__, replaced_by.__name__]).

Output text related to replaced_by should simply be:

Please update usage of "foo" to "bar".

Reasoning: By calling out explicitly this way some uniformity is provided in the messaging to users.
Yes, this could be achieved by details but then the calling project would have to implement a standard on how to write out details in a way that clearly communicates the change to the user. By reserving details for more detailed reasoning (ex: foo had a security issue and needed to go away because X) and taking in replaced_by type argument the updated API can be consistently and reliably communicated.

NOTE: This might be one aspect of #17, but it probably stands on its own since (a) it could be achieved without #17 and (b) #17 would only enhance the capability.

@briancurtin
Copy link
Owner

I have some UI/UX things to think through on putting this all together, but overall I like this and agree that it stands on its own from #17.

briancurtin added a commit that referenced this issue May 5, 2018
This change adds the `replaced_by` parameter to `deprecated` to
allow the `details` parameter to handle prose details on the deprecation
and allow the decorator to be more consistent and automated in
representing the replacement code.

Resolves #18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants