@@ -231,22 +231,28 @@ All releases of Python since 3.5 have included this in their 32-bit builds.
231
231
232
232
233
233
.. _new-feat-related-type-hints-311 :
234
+ .. _whatsnew311-typing-features :
234
235
235
236
New Features Related to Type Hints
236
237
==================================
237
238
238
239
This section covers major changes affecting :pep: `484 ` type hints and
239
240
the :mod: `typing ` module.
240
241
242
+
243
+ .. _whatsnew311-pep646 :
244
+
241
245
PEP 646: Variadic generics
242
246
--------------------------
243
247
244
- :pep: `484 ` introduced :data: `~typing.TypeVar `, enabling creation
245
- of generics parameterised with a single type. :pep: `646 ` introduces
248
+ :pep: `484 ` previously introduced :data: `~typing.TypeVar `, enabling creation
249
+ of generics parameterised with a single type. :pep: `646 ` adds
246
250
:data: `~typing.TypeVarTuple `, enabling parameterisation
247
251
with an *arbitrary * number of types. In other words,
248
252
a :data: `~typing.TypeVarTuple ` is a *variadic * type variable,
249
- enabling *variadic * generics. This enables a wide variety of use cases.
253
+ enabling *variadic * generics.
254
+
255
+ This enables a wide variety of use cases.
250
256
In particular, it allows the type of array-like structures
251
257
in numerical computing libraries such as NumPy and TensorFlow to be
252
258
parameterised with the array *shape *. Static type checkers will now
@@ -258,26 +264,30 @@ See :pep:`646` for more details.
258
264
Serhiy Storchaka and Jelle Zijlstra. PEP written by Mark Mendoza, Matthew
259
265
Rahtz, Pradeep Kumar Srinivasan, and Vincent Siles.)
260
266
267
+
268
+ .. _whatsnew311-pep655 :
269
+
261
270
PEP 655: Marking individual ``TypedDict `` items as required or not-required
262
271
---------------------------------------------------------------------------
263
272
264
273
:data: `~typing.Required ` and :data: `~typing.NotRequired ` provide a
265
274
straightforward way to mark whether individual items in a
266
- :data : `~typing.TypedDict ` must be present. Previously this was only possible
275
+ :class : `~typing.TypedDict ` must be present. Previously, this was only possible
267
276
using inheritance.
268
277
269
- Fields are still required by default, unless the ``total=False ``
270
- parameter is set.
271
- For example, the following specifies a dictionary with one required and
272
- one not-required key::
278
+ All fields are still required by default,
279
+ unless the *total * parameter is set to ``False ``,
280
+ in which case all fields are still not-required by default.
281
+ For example, the following specifies a :class: `!TypedDict `
282
+ with one required and one not-required key::
273
283
274
284
class Movie(TypedDict):
275
285
title: str
276
286
year: NotRequired[int]
277
287
278
- m1: Movie = {"title": "Black Panther", "year": 2018} # ok
279
- m2: Movie = {"title": "Star Wars"} # ok (year is not required)
280
- m3: Movie = {"year": 2022} # error (missing required field title)
288
+ m1: Movie = {"title": "Black Panther", "year": 2018} # OK
289
+ m2: Movie = {"title": "Star Wars"} # OK (year is not required)
290
+ m3: Movie = {"year": 2022} # ERROR (missing required field title)
281
291
282
292
The following definition is equivalent::
283
293
@@ -290,15 +300,20 @@ See :pep:`655` for more details.
290
300
(Contributed by David Foster and Jelle Zijlstra in :issue: `47087 `. PEP
291
301
written by David Foster.)
292
302
303
+
304
+ .. _whatsnew311-pep673 :
305
+
293
306
PEP 673: ``Self `` type
294
307
----------------------
295
308
296
309
The new :data: `~typing.Self ` annotation provides a simple and intuitive
297
310
way to annotate methods that return an instance of their class. This
298
- behaves the same as the :data: `~typing.TypeVar `-based approach specified
299
- in :pep: `484 ` but is more concise and easier to follow.
311
+ behaves the same as the :class: `~typing.TypeVar `-based approach
312
+ :pep: `specified in PEP 484 <484#annotating-instance-and-class-methods >`,
313
+ but is more concise and easier to follow.
300
314
301
- Common use cases include alternative constructors provided as classmethods
315
+ Common use cases include alternative constructors provided as
316
+ :func: `classmethod <classmethod> `\s ,
302
317
and :meth: `~object.__enter__ ` methods that return ``self ``::
303
318
304
319
class MyLock:
@@ -323,6 +338,9 @@ See :pep:`673` for more details.
323
338
(Contributed by James Hilton-Balfe in :issue: `46534 `. PEP written by
324
339
Pradeep Kumar Srinivasan and James Hilton-Balfe.)
325
340
341
+
342
+ .. _whatsnew311-pep675 :
343
+
326
344
PEP 675: Arbitrary literal string type
327
345
--------------------------------------
328
346
@@ -357,14 +375,17 @@ See :pep:`675` for more details.
357
375
(Contributed by Jelle Zijlstra in :issue: `47088 `. PEP written by Pradeep
358
376
Kumar Srinivasan and Graham Bleaney.)
359
377
378
+
379
+ .. _whatsnew311-pep681 :
380
+
360
381
PEP 681: Data Class Transforms
361
382
------------------------------
362
383
363
384
:data: `~typing.dataclass_transform ` may be used to
364
385
decorate a class, metaclass, or a function that is itself a decorator.
365
386
The presence of ``@dataclass_transform() `` tells a static type checker that the
366
- decorated object performs runtime "magic" that
367
- transforms a class, giving it :func: `dataclasses.dataclass `-like behaviors.
387
+ decorated object performs runtime "magic" that transforms a class,
388
+ giving it :func: `dataclass < dataclasses.dataclass> `-like behaviors.
368
389
369
390
For example::
370
391
@@ -376,26 +397,32 @@ For example::
376
397
cls.__ne__ = ...
377
398
return cls
378
399
379
- # The create_model decorator can now be used to create new model
380
- # classes, like this:
400
+ # The create_model decorator can now be used to create new model classes:
381
401
@create_model
382
402
class CustomerModel:
383
403
id: int
384
404
name: str
385
405
386
- c = CustomerModel(id=327, name="John Smith ")
406
+ c = CustomerModel(id=327, name="Eric Idle ")
387
407
388
408
See :pep: `681 ` for more details.
389
409
390
410
(Contributed by Jelle Zijlstra in :gh: `91860 `. PEP written by
391
411
Erik De Bonte and Eric Traut.)
392
412
393
- PEP 563 May Not Be the Future
413
+
414
+ .. _whatsnew311-pep563-deferred :
415
+
416
+ PEP 563 may not be the future
394
417
-----------------------------
395
418
396
- * :pep: `563 ` Postponed Evaluation of Annotations, ``__future__.annotations ``
397
- that was planned for this release has been indefinitely postponed.
398
- See `
this message <
https://mail.python.org/archives/list/[email protected] /message/VIZEBX5EYMSYIJNDBF6DMUMZOCWHARSO/ >`_ for more information.
419
+ :pep: `563 ` Postponed Evaluation of Annotations
420
+ (the ``from __future__ import annotations `` :ref: `future statement <future >`)
421
+ that was originally planned for release in Python 3.10
422
+ has been put on hold indefinitely.
423
+ See `
this message from the Steering Council <
https://mail.python.org/archives/list/[email protected] /message/VIZEBX5EYMSYIJNDBF6DMUMZOCWHARSO/ >`__
424
+ for more information.
425
+
399
426
400
427
Other Language Changes
401
428
======================
0 commit comments