You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This looks quite interesting; however, it'd be highly beneficial to be able to optionally specify what is replacing the call.
importdeprecation@deprecation.deprecated(deprecated_in="1.0", removed_in="2.0",current_version=__version__,details="Reasoning for change", replaced_by=bar)deffoo():
"""Do some stuff"""returnbar()
defbar():
"""Do some stuff using new API"""return1
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.
The text was updated successfully, but these errors were encountered:
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
This looks quite interesting; however, it'd be highly beneficial to be able to optionally specify what is replacing the call.
details
could probably be used more for reasoning behind the change whilereplaced_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: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 outdetails
in a way that clearly communicates the change to the user. By reservingdetails
for more detailed reasoning (ex:foo had a security issue and needed to go away because X
) and taking inreplaced_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.
The text was updated successfully, but these errors were encountered: