Thanks everyone for the replies! I'm going to reply to all of the suggested changes here:

1. Issue a runtime warning (Shantanu)

I'm still not sold on this as it will make the implementation more complex and break some user expectations (see ItsDrike's message). I'm going to move this to "Open Issues" and ask for additional opinions on discuss.python.

2. Deprecating variables (ItsDrike, Nir)

I can see merit in this but it also adds significant complexity, and we can always add it later in a separate PEP.

3. Why not put it in warnings? (Nikita)

As long as the decorator doesn't raise a warning, it definitely doesn't fit the `warnings` module. If we do add a warning, I could see this changing, but the primary purpose of the decorator will remain communicating with type checkers.

4. Add version argument/sync the interface with the `Deprecated` library (Eric)

I would consider this, but it would be confusing if there is a `version` argument that is ignored by static type checkers. We don't currently expect static type checkers to know what version of a third-party library is being used.

El dom, 1 ene 2023 a las 16:12, Jelle Zijlstra (<jelle.zijlstra@gmail.com>) escribió:
I just posted PEP 702, Marking deprecations using the type system: https://peps.python.org/pep-0702/.

The PEP proposes adding an @typing.deprecated() decorator to mark classes, methods, and functions as deprecated. Type checkers will leverage this decorator to inform users about their usage of deprecated features.

I welcome feedback on any aspect of the proposal. However, two main points came up in initial discussions:

- The proposal specifies that the decorator does not raise any runtime DeprecationWarning. Should we change this, perhaps with an opt-in flag?
- The proposal allows users to mark classes, functions, and overloads as deprecated, but there are other things that may want deprecation. Should we add support for deprecating modules, or variables, or parameters?

Happy New Year!