From 71ee259a2058c7512f0c504941ede57c686f1147 Mon Sep 17 00:00:00 2001 From: Inada Naoki Date: Wed, 2 Apr 2025 18:08:27 +0900 Subject: [PATCH] pep 781: add deprecation and a rejected idea --- peps/pep-0781.rst | 25 ++++++++++++++++++++++--- 1 file changed, 22 insertions(+), 3 deletions(-) diff --git a/peps/pep-0781.rst b/peps/pep-0781.rst index 4c4c796ee04..8521ca6887c 100644 --- a/peps/pep-0781.rst +++ b/peps/pep-0781.rst @@ -63,9 +63,14 @@ Static type checkers must treat ``TYPE_CHECKING`` as ``True``, similar to :data:`typing.TYPE_CHECKING`. If this PEP is accepted, the new ``TYPE_CHECKING`` constant will be -the preferred approach, instead of the existing ``typing.TYPE_CHECKING``. -However, ``typing.TYPE_CHECKING`` will not be deprecated in the foreseeable -future. +the preferred approach and importing ``typing.TYPE_CHECKING`` will be +deprecated. +To minimize the runtime impact of typing, this deprecation will generate +``DeprecationWarning`` no sooner than Python 3.13's end of life, scheduled +for October 2029. + +Instead, type checkers may warn about such deprecated usage when the target +version of the checked program is signalled to be Python 3.14 or newer. Backwards Compatibility @@ -115,6 +120,20 @@ Benefit from eliminating type-checking-only code is estimated to be not enough to justify the complexity. +Optimize ``import typing`` +-------------------------- + +Future optimizations may eliminate the need to avoid importing the ``typing`` +module for startup time. + +Even with such optimizations, there will still be use cases where minimizing +imports is beneficial, such as running Python on embedded systems or +in browsers. + +Therefore, defining a constant for skipping type-checking-only code outside +the ``typing`` module remains valuable. + + Copyright =========