Python 3.10 developments

Python 3.10 is available. The most daring developers are encouraged to test their code with this version, taking the necessary precautions (for example, using a virtual environment). This iteration has few major new features, but one called structural pattern matching or pattern matching is arguably the most significant addition to the language syntax since async.

Here’s a recap of all the latest major features in Python 3.10, and how they help improve the code.

Filtering or pattern matching

The addition of pattern matching comes after several failed attempts to add switch/case-like syntax to Python. This pattern matching, also called pattern matching, matches variables against a set of possible values ​​(as with switch/case in other languages). But it also maps to value patterns – for example, an object that has a certain property that has a certain value. The function greatly expands the range of possibilities and makes it possible to write code that quickly encompasses many scenarios.

For example :

command = input() correspond à command.split() :

case [“quit”] :

quit()

case [“load”, filename] :

load_from(filename)

case [“save”, filename] :

save_to(filename)

case _ :

print (f “Command ‘{command}’ not understood”)

More accurate error reporting

Python’s error reporting has long been subject to the whims of its parser. Already, Python 3.9 welcomed a whole new parser – faster, more robust, easier for the Python team to maintain, and with fewer internal hacks. The latest parser notably delivers much more accurate and useful error messages to developers. In Python 3.8, the following code generates a syntax error.

print (“Hello”

print (“What’s going on?”)

File “.test.py”, line 2

print (“What’s going on?”)

^

SyntaxError: invalid syntax

Which isn’t very helpful, because the real problem is one line above. Python 3.10 throws a much more useful error:

File “.test.py”, line 1

print (“Hello”

^

SyntaxError : ‘(‘ was never closed

Many errors produced by the parser have been improved in this direction, providing not only more precise information about the error, but also about where the error actually occurs.

Capturing Parameter Variables

Python’s typing module, used to annotate code with type information, is used to describe the types of a callable, callables, (eg, a function). But this type information cannot be propagated between callables. This makes it difficult to annotate things like function decorators. Two new additions to typing, typing.ParamSpec and typing.Concatenate, allow callables to be annotated with more abstract type definition information.

Here is an example from the PEP document on this feature.

from typing import Await Awaitable, Callable, TypeVar

R = TypeVar(“R”)

def add_logging(f : Callable[…, R]) -> Callable[…, Awaitable[R]]:

async def inner(*args : objet, **kwargs : objet) -> R :

await log_to_database()

return f(*args, **kwargs)

return inner

@add_logging

def takes_int_str(x : int, y : str) -> int :

return x + 7

await takes_int_str(1, “A”)

await takes_int_str(“B”, 2) # fails at runtime

Because it is not possible to provide the linter with proper details about the types passed to functions that are processed by the decorator, the linter cannot catch invalid types in the second instance of takes_int_str.

Here’s how this code would work with a parameter’s variable capture syntax.

from typing import Await Awaitable, Callable, ParamSpec, TypeVar

P = ParamSpec(“P”)

R = TypeVar(“R”)

def add_logging(f : Callable[P, R]) -> Callable[P, Awaitable[R]]:

async def inner(*args : P.args, **kwargs : P.kwargs) -> R :

await log_to_database(

return f(*args, **kwargs)

return inner

@add_logging

def takes_int_str(x : int, y : str) -> int :

return x + 7

await takes_int_str(1, “A”) # Accepted

await takes_int_str(“B”, 2) # Correctly rejected by the type checker

ParamSpec is used to indicate where to capture positional arguments and keywords. Concatenate can be used to indicate how arguments are added or removed, which is commonly done with decorators.

Other Major Python 3.10 Changes

– Unions of types can now be expressed as X|Y, instead of Union[X,Y], for brevity (PEP 604).

– The built-in zip, which combines the results of multiple iterables together, now has a strict keyword. When the result is True, zip throws an exception if one of the iterables is exhausted before the others (PEP 618), so as to add an optional length check in zip.

– With statements now support multi-line parenthetical syntax (BPO-12782). The function allows context managers to be grouped with parentheses.

– Variables can now be declared as explicit type aliases, to allow defining direct references, more robust errors involving types, and better distinctions between type declarations in fields (PEP 613).

– OpenSSL API 1.1.1 or newer is now required to build CPython. This requirement helps modernize one of CPython’s key dependencies (PEP 644).