PEP 702: Fix typo, section ordering (#2982)
This commit is contained in:
parent
15caa8f24b
commit
78231877fc
100
pep-0702.rst
100
pep-0702.rst
|
@ -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
|
||||
===============
|
||||
|
||||
|
|
Loading…
Reference in New Issue