Stowage/cpython
2
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2026-01-06 15:32:22 +00:00
Code Issues Projects Releases Packages Wiki Activity

Noted my recent contributions in "What's New In Python 3.10". (#25771)

Browse source 
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.
This commit is contained in:
larryhastings 2021-04-30 22:55:21 -07:00 • committed by GitHub
parent c24199184b
commit 99f71aea5c
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 33 additions and 20 deletions
Download patch file Download diff file Expand all files Collapse all files

53
Doc/whatsnew/3.10.rst
View file

@ -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