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>`__
|
`prototype support <https://github.com/quora/pyanalyze/pull/578>`__
|
||||||
for emitting deprecation errors.
|
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
|
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
|
Features for deprecating more kinds of objects could be added in a future
|
||||||
PEP.
|
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
|
Acknowledgments
|
||||||
===============
|
===============
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue