Repository navigation
How to extend warnings.deprecated? #2256
Description
Activity
Another issue: there seems to be no reason why it takes
LiteralStringonly, so that should be changed tostrin the stubs.Another issue: there seems to be no reason why it takes
LiteralStringonly, so that should be changed tostrin the stubs.LiteralStringis used intentionally, see python/typeshed#11699.This goes back to the original issue then:
How do I keep the property of seeing the deprecation (strike-through function call) and its message, but can also add e.g. a mandatory
versionparameter and extra behavior to the decorator?The following hack is very unpythonic and easy to get wrong:
@deprecated("some message") @deprecated_at("3.5") def f(...): ...
So
deprecatedis a class: python/cpython#150076I want to add keyword arguments. So how about we say this?
in subclasses,
msgshould stay a position-only argument at position 0 so type checkers can display itSubclasses of deprecated have no special meaning in the type system.
let’s change that then
@JelleZijlstra what’s necessary to change that? A whole PEP?
At a minimum we should have a discussion on discuss.python.org. A small extension like the ones you suggested above shouldn't need a PEP.
We need more metadata for our deprecation decorator, but the spec doesn’t say how
deprecatedmarks an API. So the only way to mark something as deprecated it is by creating an API with the same exact signature and replace it withwarnings.deprecatedat the type level:We need to define
deprecated(msg: str, version: packaging.Version)and have it work with the type system. How?