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
It should be possible to (somehow) specify simple cases of parameter replacement. Say, 1-to-1 or n-to-1 parameter replacements in which 1 (or multiple) parameters are replaced by 1 new replacement parameter.
The parameter deprecation call should allow specifying:
which parameter is the replacement
that passing both should be an exception (and default to raising one)
an optional "transformation" to apply to the argument passed into the deprecated parameter which either:
converts the old argument into one for the new replacement (e.g. lambda old_value: _from_legacy(old_value) would pass the upconverted value into the new replacement parameter).
passes the old argument through as-is (and thereby simply raises the deprecation warning)
drops the argument entirely (i.e. ignores the old argument entirely. The advantage is that the call signature of the wrapped function can already remove the deprecated parameter, making its deletion slightly easier.)
(The deprecation message should then also list the replacement parameter, as it does for regret.callable).
The text was updated successfully, but these errors were encountered:
It should be possible to (somehow) specify simple cases of parameter replacement. Say, 1-to-1 or n-to-1 parameter replacements in which 1 (or multiple) parameters are replaced by 1 new replacement parameter.
The parameter deprecation call should allow specifying:
lambda old_value: _from_legacy(old_value)
would pass the upconverted value into the new replacement parameter).(The deprecation message should then also list the replacement parameter, as it does for
regret.callable
).The text was updated successfully, but these errors were encountered: