Skip to content

Commit

Permalink
pythongh-95913: Copyedit, link & format Typing Features section in 3.…
Browse files Browse the repository at this point in the history
…11 What's New (pythonGH-96097)

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

Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
  • Loading branch information
CAM-Gerlach authored and miss-islington committed Sep 19, 2022
1 parent 3bf8e0f commit e678672
Showing 1 changed file with 50 additions and 23 deletions.
73 changes: 50 additions & 23 deletions Doc/whatsnew/3.11.rst
Original file line number Diff line number Diff line change
Expand Up @@ -203,22 +203,28 @@ Irit Katriel in :issue:`45607`.)


.. _new-feat-related-type-hints-311:
.. _whatsnew311-typing-features:

New Features Related to Type Hints
==================================

This section covers major changes affecting :pep:`484` type hints and
the :mod:`typing` module.


.. _whatsnew311-pep646:

PEP 646: Variadic generics
--------------------------

:pep:`484` introduced :data:`~typing.TypeVar`, enabling creation
of generics parameterised with a single type. :pep:`646` introduces
:pep:`484` previously introduced :data:`~typing.TypeVar`, enabling creation
of generics parameterised with a single type. :pep:`646` adds
:data:`~typing.TypeVarTuple`, enabling parameterisation
with an *arbitrary* number of types. In other words,
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 numerical computing libraries such as NumPy and TensorFlow to be
parameterised with the array *shape*. Static type checkers will now
Expand All @@ -230,26 +236,30 @@ See :pep:`646` for more details.
Serhiy Storchaka and Jelle Zijlstra. PEP written by Mark Mendoza, Matthew
Rahtz, Pradeep Kumar Srinivasan, and Vincent Siles.)


.. _whatsnew311-pep655:

PEP 655: Marking individual ``TypedDict`` items as required or not-required
---------------------------------------------------------------------------

:data:`~typing.Required` and :data:`~typing.NotRequired` provide 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.

Fields are still required by default, unless the ``total=False``
parameter is set.
For example, the following specifies a dictionary with one required and
one not-required key::
All fields are still required by default,
unless the *total* parameter is set to ``False``,
in which case all fields are still not-required by default.
For example, the following specifies a :class:`!TypedDict`
with one required and one not-required key::

class Movie(TypedDict):
title: str
year: NotRequired[int]

m1: Movie = {"title": "Black Panther", "year": 2018} # ok
m2: Movie = {"title": "Star Wars"} # ok (year is not required)
m3: Movie = {"year": 2022} # error (missing required field title)
m1: Movie = {"title": "Black Panther", "year": 2018} # OK
m2: Movie = {"title": "Star Wars"} # OK (year is not required)
m3: Movie = {"year": 2022} # ERROR (missing required field title)

The following definition is equivalent::

Expand All @@ -262,15 +272,20 @@ See :pep:`655` for more details.
(Contributed by David Foster and Jelle Zijlstra in :issue:`47087`. PEP
written by David Foster.)


.. _whatsnew311-pep673:

PEP 673: ``Self`` type
----------------------

The new :data:`~typing.Self` annotation provides a simple and intuitive
way to annotate methods that return an instance of their class. This
behaves the same as the :data:`~typing.TypeVar`-based approach specified
in :pep:`484` but is more concise and easier to follow.
behaves the same as the :class:`~typing.TypeVar`-based approach
: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``::

class MyLock:
Expand All @@ -295,6 +310,9 @@ See :pep:`673` for more details.
(Contributed by James Hilton-Balfe in :issue:`46534`. PEP written by
Pradeep Kumar Srinivasan and James Hilton-Balfe.)


.. _whatsnew311-pep675:

PEP 675: Arbitrary literal string type
--------------------------------------

Expand Down Expand Up @@ -329,14 +347,17 @@ See :pep:`675` for more details.
(Contributed by Jelle Zijlstra in :issue:`47088`. PEP written by Pradeep
Kumar Srinivasan and Graham Bleaney.)


.. _whatsnew311-pep681:

PEP 681: Data Class Transforms
------------------------------

:data:`~typing.dataclass_transform` may be used to
decorate a class, metaclass, or a function that is itself a decorator.
The presence of ``@dataclass_transform()`` tells a static type checker that the
decorated object performs runtime "magic" that
transforms a class, giving it :func:`dataclasses.dataclass`-like behaviors.
decorated object performs runtime "magic" that transforms a class,
giving it :func:`dataclass <dataclasses.dataclass>`-like behaviors.

For example::

Expand All @@ -348,26 +369,32 @@ For example::
cls.__ne__ = ...
return cls

# The create_model decorator can now be used to create new model
# classes, like this:
# The create_model decorator can now be used to create new model classes:
@create_model
class CustomerModel:
id: int
name: str

c = CustomerModel(id=327, name="John Smith")
c = CustomerModel(id=327, name="Eric Idle")

See :pep:`681` for more details.

(Contributed by Jelle Zijlstra in :gh:`91860`. PEP written by
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``
that was planned for this release has been indefinitely postponed.
See `this message <https://mail.python.org/archives/list/python-dev@python.org/message/VIZEBX5EYMSYIJNDBF6DMUMZOCWHARSO/>`_ for more information.
:pep:`563` Postponed Evaluation of Annotations
(the ``from __future__ import annotations`` :ref:`future statement <future>`)
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.


Windows py.exe launcher improvements
------------------------------------
Expand Down

0 comments on commit e678672

Please sign in to comment.