PEP 702: Fix typo, section ordering (#2982)

This commit is contained in:
Jelle Zijlstra 2023-01-24 07:23:21 -08:00 committed by GitHub
parent 15caa8f24b
commit 78231877fc
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 50 additions and 50 deletions

View File

@ -234,56 +234,6 @@ The ``pyanalyze`` type checker has
`prototype support <https://github.com/quora/pyanalyze/pull/578>`__
for emitting deprecation errors.
Open issues
===========
Runtime warnings
----------------
Users might expect usage of the ``@deprecated`` decorator to issue a
:exc:`DeprecationWarning` at runtime. However, this would raise a number of
thorny issues:
* When the decorator is applied to a class or an overload, the warning
would not be raised as expected. For classes, the warning could be
raised on instantiation, but this would not cover usage in type
annotations or :func:`isinstance` checks.
* 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:
.. code-block:: python
from typing import TYPE_CHECKING
import functools
import warnings
if TYPE_CHECKING:
from typing import deprecated
else:
def deprecated(msg):
def decorator(func):
@functools.wraps(func)
def wrapper(*args, **kwargs):
warnings.warn(msg, DeprecationWarning, stacklevel=2)
return func(*args, **kwargs)
wrapper.__deprecated__ = msg
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
==============
@ -324,6 +274,56 @@ show that this feature is not commonly needed.
Features for deprecating more kinds of objects could be added in a future
PEP.
Open issues
===========
Runtime warnings
----------------
Users might expect usage of the ``@deprecated`` decorator to issue a
:exc:`DeprecationWarning` at runtime. However, this would raise a number of
thorny issues:
* When the decorator is applied to a class or an overload, the warning
would not be raised as expected. For classes, the warning could be
raised on instantiation, but this would not cover usage in type
annotations or :func:`isinstance` checks.
* 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 warning, 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:
.. code-block:: python
from typing import TYPE_CHECKING
import functools
import warnings
if TYPE_CHECKING:
from typing import deprecated
else:
def deprecated(msg):
def decorator(func):
@functools.wraps(func)
def wrapper(*args, **kwargs):
warnings.warn(msg, DeprecationWarning, stacklevel=2)
return func(*args, **kwargs)
wrapper.__deprecated__ = msg
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.
Acknowledgments
===============