mirrors/cpython
1
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2025-10-03 13:45:29 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 8

gh-95913: Copyedit, link & format Typing Features section in 3.11 What's New (GH-96097)

Browse source 
Co-authored-by: Ezio Melotti <ezio.melotti@gmail.com>
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
(cherry picked from commit 558768ff22)

Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
This commit is contained in:
Miss Islington (bot) 2022-09-19 06:51:08 -07:00 • committed by Pablo Galindo
parent 2a1e9b01d1
commit 837c1206b2
No known key found for this signature in database
GPG key ID: FFE87404168BD847
1 changed files with 50 additions and 23 deletions
Download patch file Download diff file Expand all files Collapse all files

73
Doc/whatsnew/3.11.rst
View file

@ -231,6 +231,7 @@ All releases of Python since 3.5 have included this in their 32-bit builds.
.. _new-feat-related-type-hints-311: .. _new-feat-related-type-hints-311:
.. _whatsnew311-typing-features:
New Features Related to Type Hints New Features Related to Type Hints
================================== ==================================
@ -238,15 +239,20 @@ New Features Related to Type Hints
This section covers major changes affecting :pep:`484` type hints and This section covers major changes affecting :pep:`484` type hints and
the :mod:`typing` module. the :mod:`typing` module.
.. _whatsnew311-pep646:
PEP 646: Variadic generics PEP 646: Variadic generics
-------------------------- --------------------------
:pep:`484` introduced :data:`~typing.TypeVar`, enabling creation :pep:`484` previously introduced :data:`~typing.TypeVar`, enabling creation
of generics parameterised with a single type. :pep:`646` introduces of generics parameterised with a single type. :pep:`646` adds
:data:`~typing.TypeVarTuple`, enabling parameterisation :data:`~typing.TypeVarTuple`, enabling parameterisation
with an *arbitrary* number of types. In other words, with an *arbitrary* number of types. In other words,
a :data:`~typing.TypeVarTuple` is a *variadic* type variable, a :data:`~typing.TypeVarTuple` is a *variadic* type variable,
enabling *variadic* generics. This enables a wide variety of use cases. enabling *variadic* generics.
This enables a wide variety of use cases.
In particular, it allows the type of array-like structures In particular, it allows the type of array-like structures
in numerical computing libraries such as NumPy and TensorFlow to be in numerical computing libraries such as NumPy and TensorFlow to be
parameterised with the array *shape*. Static type checkers will now parameterised with the array *shape*. Static type checkers will now
@ -258,26 +264,30 @@ See :pep:`646` for more details.
Serhiy Storchaka and Jelle Zijlstra. PEP written by Mark Mendoza, Matthew Serhiy Storchaka and Jelle Zijlstra. PEP written by Mark Mendoza, Matthew
Rahtz, Pradeep Kumar Srinivasan, and Vincent Siles.) Rahtz, Pradeep Kumar Srinivasan, and Vincent Siles.)
.. _whatsnew311-pep655:
PEP 655: Marking individual ``TypedDict`` items as required or not-required PEP 655: Marking individual ``TypedDict`` items as required or not-required
--------------------------------------------------------------------------- ---------------------------------------------------------------------------
:data:`~typing.Required` and :data:`~typing.NotRequired` provide a :data:`~typing.Required` and :data:`~typing.NotRequired` provide a
straightforward way to mark whether individual items in a straightforward way to mark whether individual items in a
:data:`~typing.TypedDict` must be present. Previously this was only possible :class:`~typing.TypedDict` must be present. Previously, this was only possible
using inheritance. using inheritance.
Fields are still required by default, unless the ``total=False`` All fields are still required by default,
parameter is set. unless the *total* parameter is set to ``False``,
For example, the following specifies a dictionary with one required and in which case all fields are still not-required by default.
one not-required key:: For example, the following specifies a :class:`!TypedDict`
with one required and one not-required key::
class Movie(TypedDict): class Movie(TypedDict):
title: str title: str
year: NotRequired[int] year: NotRequired[int]
m1: Movie = {"title": "Black Panther", "year": 2018} # ok m1: Movie = {"title": "Black Panther", "year": 2018} # OK
m2: Movie = {"title": "Star Wars"} # ok (year is not required) m2: Movie = {"title": "Star Wars"} # OK (year is not required)
m3: Movie = {"year": 2022} # error (missing required field title) m3: Movie = {"year": 2022} # ERROR (missing required field title)
The following definition is equivalent:: The following definition is equivalent::
@ -290,15 +300,20 @@ See :pep:`655` for more details.
(Contributed by David Foster and Jelle Zijlstra in :issue:`47087`. PEP (Contributed by David Foster and Jelle Zijlstra in :issue:`47087`. PEP
written by David Foster.) written by David Foster.)
.. _whatsnew311-pep673:
PEP 673: ``Self`` type PEP 673: ``Self`` type
---------------------- ----------------------
The new :data:`~typing.Self` annotation provides a simple and intuitive The new :data:`~typing.Self` annotation provides a simple and intuitive
way to annotate methods that return an instance of their class. This way to annotate methods that return an instance of their class. This
behaves the same as the :data:`~typing.TypeVar`-based approach specified behaves the same as the :class:`~typing.TypeVar`-based approach
in :pep:`484` but is more concise and easier to follow. :pep:`specified in PEP 484 <484#annotating-instance-and-class-methods>`,
but is more concise and easier to follow.
Common use cases include alternative constructors provided as classmethods Common use cases include alternative constructors provided as
:func:`classmethod <classmethod>`\s,
and :meth:`~object.__enter__` methods that return ``self``:: and :meth:`~object.__enter__` methods that return ``self``::
class MyLock: class MyLock:
@ -323,6 +338,9 @@ See :pep:`673` for more details.
(Contributed by James Hilton-Balfe in :issue:`46534`. PEP written by (Contributed by James Hilton-Balfe in :issue:`46534`. PEP written by
Pradeep Kumar Srinivasan and James Hilton-Balfe.) Pradeep Kumar Srinivasan and James Hilton-Balfe.)
.. _whatsnew311-pep675:
PEP 675: Arbitrary literal string type PEP 675: Arbitrary literal string type
-------------------------------------- --------------------------------------
@ -357,14 +375,17 @@ See :pep:`675` for more details.
(Contributed by Jelle Zijlstra in :issue:`47088`. PEP written by Pradeep (Contributed by Jelle Zijlstra in :issue:`47088`. PEP written by Pradeep
Kumar Srinivasan and Graham Bleaney.) Kumar Srinivasan and Graham Bleaney.)
.. _whatsnew311-pep681:
PEP 681: Data Class Transforms PEP 681: Data Class Transforms
------------------------------ ------------------------------
:data:`~typing.dataclass_transform` may be used to :data:`~typing.dataclass_transform` may be used to
decorate a class, metaclass, or a function that is itself a decorator. decorate a class, metaclass, or a function that is itself a decorator.
The presence of ``@dataclass_transform()`` tells a static type checker that the The presence of ``@dataclass_transform()`` tells a static type checker that the
decorated object performs runtime "magic" that decorated object performs runtime "magic" that transforms a class,
transforms a class, giving it :func:`dataclasses.dataclass`-like behaviors. giving it :func:`dataclass <dataclasses.dataclass>`-like behaviors.
For example:: For example::
@ -376,26 +397,32 @@ For example::
cls.__ne__ = ... cls.__ne__ = ...
return cls return cls
# The create_model decorator can now be used to create new model # The create_model decorator can now be used to create new model classes:
# classes, like this:
@create_model @create_model
class CustomerModel: class CustomerModel:
id: int id: int
name: str name: str
c = CustomerModel(id=327, name="John Smith") c = CustomerModel(id=327, name="Eric Idle")
See :pep:`681` for more details. See :pep:`681` for more details.
(Contributed by Jelle Zijlstra in :gh:`91860`. PEP written by (Contributed by Jelle Zijlstra in :gh:`91860`. PEP written by
Erik De Bonte and Eric Traut.) Erik De Bonte and Eric Traut.)
PEP 563 May Not Be the Future
.. _whatsnew311-pep563-deferred:
PEP 563 may not be the future
----------------------------- -----------------------------
* :pep:`563` Postponed Evaluation of Annotations, ``__future__.annotations`` :pep:`563` Postponed Evaluation of Annotations
that was planned for this release has been indefinitely postponed. (the ``from __future__ import annotations`` :ref:`future statement <future>`)
See `this message <https://mail.python.org/archives/list/python-dev@python.org/message/VIZEBX5EYMSYIJNDBF6DMUMZOCWHARSO/>`_ for more information. that was originally planned for release in Python 3.10
has been put on hold indefinitely.
See `this message from the Steering Council <https://mail.python.org/archives/list/python-dev@python.org/message/VIZEBX5EYMSYIJNDBF6DMUMZOCWHARSO/>`__
for more information.
Other Language Changes Other Language Changes
====================== ======================