PEP 702: Changes after discussion

pep-0702.rst

@@ -233,8 +233,8 @@ The ``pyanalyze`` type checker has
 `prototype support <https://github.com/quora/pyanalyze/pull/578>`__
 for emitting deprecation errors.
 
-Rejected ideas
-==============
+Open issues
+===========
 
 Runtime warnings
 ----------------
@@ -250,6 +250,11 @@ thorny issues:
 * Users may want to control the :func:`~warnings.warn` call in more detail
   (e.g., changing the warning class).
 * ``typing.py`` generally aims to avoid affecting runtime behavior.
+* To raise a wwarning, the ``@deprecated`` decorator would have to wrap
+  functions and patch ``__new__`` on classes. This would complicate runtime
+  introspection.
+* Users may not expect usage of an object from the ``typing`` module to
+  affect runtime behavior.
 
 Users who want to use ``@deprecated`` while also issuing a runtime warning
 can use the ``if TYPE_CHECKING:`` idiom, for example:
@@ -273,6 +278,14 @@ can use the ``if TYPE_CHECKING:`` idiom, for example:
                return wrapper
            return decorator
 
+While this code block looks complex, it could be encapsulated in a library.
+
+Still, the behavior could be made opt-in, and perhaps the benefits of
+incorporating a runtime warning outweigh the costs.
+
+Rejected ideas
+==============
+
 Deprecation of modules and attributes
 -------------------------------------
 
@@ -307,6 +320,9 @@ in the type system where strings are just strings, not forward references,
 complicating the implementation of type checkers. In addition, my data
 show that this feature is not commonly needed.
 
+Features for deprecating more kinds of objects could be added in a future
+PEP.
+
 Acknowledgments
 ===============