@@ -203,22 +203,28 @@ Irit Katriel in :issue:`45607`.)
203
203
204
204
205
205
.. _new-feat-related-type-hints-311 :
206
+ .. _whatsnew311-typing-features :
206
207
207
208
New Features Related to Type Hints
208
209
==================================
209
210
210
211
This section covers major changes affecting :pep: `484 ` type hints and
211
212
the :mod: `typing ` module.
212
213
214
+
215
+ .. _whatsnew311-pep646 :
216
+
213
217
PEP 646: Variadic generics
214
218
--------------------------
215
219
216
- :pep: `484 ` introduced :data: `~typing.TypeVar `, enabling creation
217
- of generics parameterised with a single type. :pep: `646 ` introduces
220
+ :pep: `484 ` previously introduced :data: `~typing.TypeVar `, enabling creation
221
+ of generics parameterised with a single type. :pep: `646 ` adds
218
222
:data: `~typing.TypeVarTuple `, enabling parameterisation
219
223
with an *arbitrary * number of types. In other words,
220
224
a :data: `~typing.TypeVarTuple ` is a *variadic * type variable,
221
- enabling *variadic * generics. This enables a wide variety of use cases.
225
+ enabling *variadic * generics.
226
+
227
+ This enables a wide variety of use cases.
222
228
In particular, it allows the type of array-like structures
223
229
in numerical computing libraries such as NumPy and TensorFlow to be
224
230
parameterised with the array *shape *. Static type checkers will now
@@ -230,26 +236,30 @@ See :pep:`646` for more details.
230
236
Serhiy Storchaka and Jelle Zijlstra. PEP written by Mark Mendoza, Matthew
231
237
Rahtz, Pradeep Kumar Srinivasan, and Vincent Siles.)
232
238
239
+
240
+ .. _whatsnew311-pep655 :
241
+
233
242
PEP 655: Marking individual ``TypedDict `` items as required or not-required
234
243
---------------------------------------------------------------------------
235
244
236
245
:data: `~typing.Required ` and :data: `~typing.NotRequired ` provide a
237
246
straightforward way to mark whether individual items in a
238
- :data : `~typing.TypedDict ` must be present. Previously this was only possible
247
+ :class : `~typing.TypedDict ` must be present. Previously, this was only possible
239
248
using inheritance.
240
249
241
- Fields are still required by default, unless the ``total=False ``
242
- parameter is set.
243
- For example, the following specifies a dictionary with one required and
244
- one not-required key::
250
+ All fields are still required by default,
251
+ unless the *total * parameter is set to ``False ``,
252
+ in which case all fields are still not-required by default.
253
+ For example, the following specifies a :class: `!TypedDict `
254
+ with one required and one not-required key::
245
255
246
256
class Movie(TypedDict):
247
257
title: str
248
258
year: NotRequired[int]
249
259
250
- m1: Movie = {"title": "Black Panther", "year": 2018} # ok
251
- m2: Movie = {"title": "Star Wars"} # ok (year is not required)
252
- m3: Movie = {"year": 2022} # error (missing required field title)
260
+ m1: Movie = {"title": "Black Panther", "year": 2018} # OK
261
+ m2: Movie = {"title": "Star Wars"} # OK (year is not required)
262
+ m3: Movie = {"year": 2022} # ERROR (missing required field title)
253
263
254
264
The following definition is equivalent::
255
265
@@ -262,15 +272,20 @@ See :pep:`655` for more details.
262
272
(Contributed by David Foster and Jelle Zijlstra in :issue: `47087 `. PEP
263
273
written by David Foster.)
264
274
275
+
276
+ .. _whatsnew311-pep673 :
277
+
265
278
PEP 673: ``Self `` type
266
279
----------------------
267
280
268
281
The new :data: `~typing.Self ` annotation provides a simple and intuitive
269
282
way to annotate methods that return an instance of their class. This
270
- behaves the same as the :data: `~typing.TypeVar `-based approach specified
271
- in :pep: `484 ` but is more concise and easier to follow.
283
+ behaves the same as the :class: `~typing.TypeVar `-based approach
284
+ :pep: `specified in PEP 484 <484#annotating-instance-and-class-methods >`,
285
+ but is more concise and easier to follow.
272
286
273
- Common use cases include alternative constructors provided as classmethods
287
+ Common use cases include alternative constructors provided as
288
+ :func: `classmethod <classmethod> `\s ,
274
289
and :meth: `~object.__enter__ ` methods that return ``self ``::
275
290
276
291
class MyLock:
@@ -295,6 +310,9 @@ See :pep:`673` for more details.
295
310
(Contributed by James Hilton-Balfe in :issue: `46534 `. PEP written by
296
311
Pradeep Kumar Srinivasan and James Hilton-Balfe.)
297
312
313
+
314
+ .. _whatsnew311-pep675 :
315
+
298
316
PEP 675: Arbitrary literal string type
299
317
--------------------------------------
300
318
@@ -329,14 +347,17 @@ See :pep:`675` for more details.
329
347
(Contributed by Jelle Zijlstra in :issue: `47088 `. PEP written by Pradeep
330
348
Kumar Srinivasan and Graham Bleaney.)
331
349
350
+
351
+ .. _whatsnew311-pep681 :
352
+
332
353
PEP 681: Data Class Transforms
333
354
------------------------------
334
355
335
356
:data: `~typing.dataclass_transform ` may be used to
336
357
decorate a class, metaclass, or a function that is itself a decorator.
337
358
The presence of ``@dataclass_transform() `` tells a static type checker that the
338
- decorated object performs runtime "magic" that
339
- transforms a class, giving it :func: `dataclasses.dataclass `-like behaviors.
359
+ decorated object performs runtime "magic" that transforms a class,
360
+ giving it :func: `dataclass < dataclasses.dataclass> `-like behaviors.
340
361
341
362
For example::
342
363
@@ -348,26 +369,32 @@ For example::
348
369
cls.__ne__ = ...
349
370
return cls
350
371
351
- # The create_model decorator can now be used to create new model
352
- # classes, like this:
372
+ # The create_model decorator can now be used to create new model classes:
353
373
@create_model
354
374
class CustomerModel:
355
375
id: int
356
376
name: str
357
377
358
- c = CustomerModel(id=327, name="John Smith ")
378
+ c = CustomerModel(id=327, name="Eric Idle ")
359
379
360
380
See :pep: `681 ` for more details.
361
381
362
382
(Contributed by Jelle Zijlstra in :gh: `91860 `. PEP written by
363
383
Erik De Bonte and Eric Traut.)
364
384
365
- PEP 563 May Not Be the Future
385
+
386
+ .. _whatsnew311-pep563-deferred :
387
+
388
+ PEP 563 may not be the future
366
389
-----------------------------
367
390
368
- * :pep: `563 ` Postponed Evaluation of Annotations, ``__future__.annotations ``
369
- that was planned for this release has been indefinitely postponed.
370
- See `
this message <
https://mail.python.org/archives/list/[email protected] /message/VIZEBX5EYMSYIJNDBF6DMUMZOCWHARSO/ >`_ for more information.
391
+ :pep: `563 ` Postponed Evaluation of Annotations
392
+ (the ``from __future__ import annotations `` :ref: `future statement <future >`)
393
+ that was originally planned for release in Python 3.10
394
+ has been put on hold indefinitely.
395
+ See `
this message from the Steering Council <
https://mail.python.org/archives/list/[email protected] /message/VIZEBX5EYMSYIJNDBF6DMUMZOCWHARSO/ >`__
396
+ for more information.
397
+
371
398
372
399
Windows py.exe launcher improvements
373
400
------------------------------------
0 commit comments