Re: PEP 702: Marking deprecations using the type system
I would say that supporting deprecation for variables should absolutely be a part of this PEP, but it might not actually require a `typing.Deprecated` modifier like suggested in the rejected ideas, and instead we probably could get away with just use the `typing.deprecated`, which would simply mark it internally for the type-checker as a deprecated utility, but the call itself would just return the same value. So this could look like: `X = typing.deprecated("Constant moved to module.foo")(5)`, or to make this a bit easier for this kind of use,there could be a special case handling for 2 argument version of `typing.deprecated`, which would then look like: `X = typing.deprecated("Constant moved to module.foo", 5)`. That said, `typing.Deprecated` as suggested would probably be more consistent with the rest of the type system, but if the rejection was done purely to avoid adding yet another typing modifier that breaks forward references, this could be a solution that avoids it. The reason I think this should be supported is because in some cases, typed libraries might have some commonly used type alias that now needs to be renamed or moved elsewhere. Without a way to deprecate constants, this is completely impossible, not just on type checking time, but also on runtime, as this is just a type alias imported as a simple constant, so there's no easy way to emit a warning on runtime for such use, forcing the library to make an unexpected breaking change. I'd say that there should absolutely be some support in the typing system that allows typed libraries to safely get rid of a type alias, with a deprecation period. This is a bit more complicated with simple constants though, which this absolutely should work for too, however constants are likely gonna be used in non-typed environments too, and since this kind of deprecation won't actually cause any runtime warnings, people not using a type-checker might still end up facing an unexpected breaking change. I don't see any easy way to address this though.
One more thing that bothers me: why `typing.deprecated`? Why not `warnings.deprecated`? This is especially true if we raise runtime warnings. I would not expect to import this decorator from typing. пн, 2 янв. 2023 г. в 07:19, ItsDrike <me@itsdrike.com>:
I would say that supporting deprecation for variables should absolutely be a part of this PEP, but it might not actually require a typing.Deprecated modifier like suggested in the rejected ideas, and instead we probably could get away with just use the typing.deprecated, which would simply mark it internally for the type-checker as a deprecated utility, but the call itself would just return the same value. So this could look like: X = typing.deprecated("Constant moved to module.foo")(5), or to make this a bit easier for this kind of use,there could be a special case handling for 2 argument version of typing.deprecated, which would then look like: X = typing.deprecated("Constant moved to module.foo", 5).
That said, typing.Deprecated as suggested would probably be more consistent with the rest of the type system, but if the rejection was done purely to avoid adding yet another typing modifier that breaks forward references, this could be a solution that avoids it.
The reason I think this should be supported is because in some cases, typed libraries might have some commonly used type alias that now needs to be renamed or moved elsewhere. Without a way to deprecate constants, this is completely impossible, not just on type checking time, but also on runtime, as this is just a type alias imported as a simple constant, so there's no easy way to emit a warning on runtime for such use, forcing the library to make an unexpected breaking change.
I'd say that there should absolutely be some support in the typing system that allows typed libraries to safely get rid of a type alias, with a deprecation period. This is a bit more complicated with simple constants though, which this absolutely should work for too, however constants are likely gonna be used in non-typed environments too, and since this kind of deprecation won't actually cause any runtime warnings, people not using a type-checker might still end up facing an unexpected breaking change. I don't see any easy way to address this though. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: n.a.sobolev@gmail.com
Am 02.01.23 um 11:42 schrieb Никита Соболев:
One more thing that bothers me: why `typing.deprecated`? Why not `warnings.deprecated`? This is especially true if we raise runtime warnings. I would not expect to import this decorator from typing.
I agree with Nikita, even if it is a bit bikesheddy. I think this decorator will find wide use outside of type checkers, especially with linters and IDEs, but also with documentation generators. - Sebastian
participants (3)
-
ItsDrike -
Sebastian Rittau -
Никита Соболев