E.g.
|
warnings.warn(f"{attr} is deprecated. Please use {newAttr} instead.", DeprecationWarning) |
Currently the stack trace for these warnings will start at the definition site, when really they should start at the usage site. This would match the recommendation given in the warnings module and is also the stacklevel @warnings.deprecated uses by default for calling a deprecated function.
Pytest will only show the first stacklevel in its warnings summary by default and will be the main way people encounter these warnings, since they're off by default, so it's best for the first stack level to be indicative of where something needs to change in order for the warning to go away. It also makes it easier to filter the warning for specific third party packages that have yet still to make the transition, rather than ignoring the warning globally and risk regressions in your own code.
E.g.
pyasn1/pyasn1/codec/ber/encoder.py
Line 952 in 0100d9a
Currently the stack trace for these warnings will start at the definition site, when really they should start at the usage site. This would match the recommendation given in the
warningsmodule and is also the stacklevel@warnings.deprecateduses by default for calling a deprecated function.Pytest will only show the first stacklevel in its warnings summary by default and will be the main way people encounter these warnings, since they're off by default, so it's best for the first stack level to be indicative of where something needs to change in order for the warning to go away. It also makes it easier to filter the warning for specific third party packages that have yet still to make the transition, rather than ignoring the warning globally and risk regressions in your own code.