diff options
author | larryhastings <larry@hastings.org> | 2021-05-01 05:55:21 (GMT) |
---|---|---|
committer | GitHub <noreply@github.com> | 2021-05-01 05:55:21 (GMT) |
commit | 99f71aea5c5ddfdd13dc99e4253a7e3a6d10aead (patch) | |
tree | 0bc1b50e2cc8559707b0a743a03324917223a1b2 /Doc | |
parent | c24199184bea0c851c1a7296ae54aaf18ee56752 (diff) | |
download | cpython-99f71aea5c5ddfdd13dc99e4253a7e3a6d10aead.zip cpython-99f71aea5c5ddfdd13dc99e4253a7e3a6d10aead.tar.gz cpython-99f71aea5c5ddfdd13dc99e4253a7e3a6d10aead.tar.bz2 |
Noted my recent contributions in "What's New In Python 3.10". (#25771)
Noted my recent contributions in "What's New In Python 3.10". Also made some edits clarifying "annotations" vs "type hints", and some other edits for correctness.
Diffstat (limited to 'Doc')
-rw-r--r-- | Doc/whatsnew/3.10.rst | 53 |
1 files changed, 33 insertions, 20 deletions
diff --git a/Doc/whatsnew/3.10.rst b/Doc/whatsnew/3.10.rst index 9c8e296..797e1e3 100644 --- a/Doc/whatsnew/3.10.rst +++ b/Doc/whatsnew/3.10.rst @@ -659,10 +659,10 @@ are added to enable the warning. See :ref:`io-text-encoding` for more information. -New Features Related to Type Annotations -======================================== +New Features Related to Type Hints +================================== -This section covers major changes affecting :pep:`484` type annotations and +This section covers major changes affecting :pep:`484` type hints and the :mod:`typing` module. @@ -671,7 +671,7 @@ PEP 604: New Type Union Operator A new type union operator was introduced which enables the syntax ``X | Y``. This provides a cleaner way of expressing 'either type X or type Y' instead of -using :data:`typing.Union`, especially in type hints (annotations). +using :data:`typing.Union`, especially in type hints. In previous versions of Python, to apply a type hint for functions accepting arguments of multiple types, :data:`typing.Union` was used:: @@ -722,8 +722,8 @@ See :class:`typing.Callable`, :class:`typing.ParamSpec`, Zijlstra in :issue:`43783`. PEP written by Mark Mendoza.) -PEP 613: TypeAlias Annotation ------------------------------ +PEP 613: TypeAlias +------------------ :pep:`484` introduced the concept of type aliases, only requiring them to be top-level unannotated assignments. This simplicity sometimes made it difficult @@ -733,8 +733,8 @@ especially when forward references or invalid types were involved. Compare:: StrCache = 'Cache[str]' # a type alias LOG_PREFIX = 'LOG[DEBUG]' # a module constant -Now the :mod:`typing` module has a special annotation :data:`TypeAlias` to -declare type aliases more explicitly:: +Now the :mod:`typing` module has a special value :data:`TypeAlias` +which lets you declare type aliases more explicitly:: StrCache: TypeAlias = 'Cache[str]' # a type alias LOG_PREFIX = 'LOG[DEBUG]' # a module constant @@ -805,6 +805,10 @@ Other Language Changes defined by :pep:`526`) no longer cause any runtime effects with ``from __future__ import annotations``. (Contributed by Batuhan Taskaya in :issue:`42737`.) +* Class and module objects now lazy-create empty annotations dicts on demand. + The annotations dicts are stored in the object’s ``__dict__`` for + backwards compatibility. + (Contributed by Larry Hastings in :issue:`43901`.) New Modules =========== @@ -987,10 +991,18 @@ inspect When a module does not define ``__loader__``, fall back to ``__spec__.loader``. (Contributed by Brett Cannon in :issue:`42133`.) -Added *globalns* and *localns* parameters in :func:`~inspect.signature` and -:meth:`inspect.Signature.from_callable` to retrieve the annotations in given -local and global namespaces. -(Contributed by Batuhan Taskaya in :issue:`41960`.) +Added :func:`inspect.get_annotations`, which safely computes the annotations +defined on an object. It works around the quirks of accessing the annotations +on various types of objects, and makes very few assumptions about the object +it examines. :func:`inspect.get_annotations` can also correctly un-stringize +stringized annotations. :func:`inspect.get_annotations` is now considered +best practice for accessing the annotations dict defined on any Python object. +Relatedly, :func:`inspect.signature`, +:func:`inspect.Signature.from_callable`, and ``inspect.Signature.from_function`` +now call :func:`inspect.get_annotations` to retrieve annotations. This means +:func:`inspect.signature` and :func:`inspect.Signature.from_callable` can +also now un-stringize stringized annotations. +(Contributed by Larry Hastings in :issue:`43817`.) linecache --------- @@ -1155,7 +1167,7 @@ of types readily interpretable by type checkers. typing ------ -For major changes, see `New Features Related to Type Annotations`_. +For major changes, see `New Features Related to Type Hints`_. The behavior of :class:`typing.Literal` was changed to conform with :pep:`586` and to match the behavior of static type checkers specified in the PEP. @@ -1255,11 +1267,12 @@ Optimizations faster, lzma decompression 1.20x ~ 1.32x faster, ``GzipFile.read(-1)`` 1.11x ~ 1.18x faster. (Contributed by Ma Lin, reviewed by Gregory P. Smith, in :issue:`41486`) -* Function parameters and their annotations are no longer computed at runtime, - but rather at compilation time. They are stored as a tuple of strings at the - bytecode level. It is now around 2 times faster to create a function with - parameter annotations. (Contributed by Yurii Karabas and Inada Naoki - in :issue:`42202`) +* When using stringized annotations, annotations dicts for functions are no longer + created when the function is created. Instead, they're stored as a tuple of + strings, and the function object lazily converts this into the annotations dict + on demand. This optimization cuts the CPU time needed to define an annotated + function by half. + (Contributed by Yurii Karabas and Inada Naoki in :issue:`42202`) * Substring search functions such as ``str1 in str2`` and ``str2.find(str1)`` now sometimes use Crochemore & Perrin's "Two-Way" string searching @@ -1569,8 +1582,8 @@ Changes in the Python API CPython bytecode changes ======================== -* The ``MAKE_FUNCTION`` instruction accepts tuple of strings as annotations - instead of dictionary. +* The ``MAKE_FUNCTION`` instruction now accepts either a dict or a tuple of + strings as the function's annotations. (Contributed by Yurii Karabas and Inada Naoki in :issue:`42202`) Build Changes |