PEP 702: More discussion of precedent and runtime behavior (#2946)

Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
This commit is contained in:
Jelle Zijlstra 2023-01-03 09:00:06 -08:00 committed by GitHub
parent d42d5a8a70
commit 2220d705a9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 15 additions and 5 deletions

View File

@ -85,6 +85,14 @@ Several users have requested support for such a feature:
* `Pyright feature request <https://github.com/microsoft/pyright/discussions/2300>`__
* `mypy feature request <https://github.com/python/mypy/issues/11439>`__
There are similar existing third-party tools:
* `Deprecated <https://pypi.org/project/Deprecated/>`__ provides a decorator to
mark classes, functions, or methods as deprecated. Access to decorated objects
raises a runtime warning, but is not detected by type checkers.
* `flake8-deprecated <https://pypi.org/project/flake8-deprecated/>`__ is a linter
plugin that warns about use of deprecated features. However, it is limited to
a short, hard-coded list of deprecations.
Specification
=============
@ -157,8 +165,8 @@ Here is how type checkers should handle usage of this library:
import library
library.norwegian_gray(1) # error: Use of deprecated function norwegian_gray. It is pining for the fiords.
map(library.norwegian_gray, [1, 2, 3]) # error: Use of deprecated function norwegian_gray. It is pining for the fiords.
library.norwegian_blue(1) # error: Use of deprecated function norwegian_blue. It is pining for the fiords.
map(library.norwegian_blue, [1, 2, 3]) # error: Use of deprecated function norwegian_blue. It is pining for the fiords.
library.foo(1) # error: Use of deprecated overload for foo. Only str will be allowed.
library.foo("x") # no error
@ -236,9 +244,11 @@ Users might expect usage of the ``@deprecated`` decorator to issue a
thorny issues:
* When the decorator is applied to a class or an overload, the warning
would not be raised as expected.
* Users may want to control the ``warn`` call in more detail (e.g.,
changing the warning class).
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.
Users who want to use ``@deprecated`` while also issuing a runtime warning