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