##  New Features  Â¶

###  PEP 695: Type Parameter Syntax  Â¶

Generic classes and functions under  [ **PEP 484**
](https://peps.python.org/pep-0484/) were declared using a verbose syntax that
left the scope of type parameters unclear and required explicit declarations
of variance.

[ **PEP 695** ](https://peps.python.org/pep-0695/) introduces a new, more
compact and explicit way to create [ generic classes
](../reference/compound_stmts.html#generic-classes) and [ functions
](../reference/compound_stmts.html#generic-functions) :

    
    
    def max[T](args: Iterable[T]) -> T:
        ...
    
    class list[T]:
        def __getitem__(self, index: int, /) -> T:
            ...
    
        def append(self, element: T) -> None:
            ...
    

In addition, the PEP introduces a new way to declare [ type aliases
](../library/typing.html#type-aliases) using the [ ` type  `
](../reference/simple_stmts.html#type) statement, which creates an instance of
[ ` TypeAliasType  ` ](../library/typing.html#typing.TypeAliasType
"typing.TypeAliasType") :

    
    
    type Point = tuple[float, float]
    

Type aliases can also be [ generic
](../reference/compound_stmts.html#generic-type-aliases) :

    
    
    type Point[T] = tuple[T, T]
    

The new syntax allows declaring [ ` TypeVarTuple  `
](../library/typing.html#typing.TypeVarTuple "typing.TypeVarTuple") and [ `
ParamSpec  ` ](../library/typing.html#typing.ParamSpec "typing.ParamSpec")
parameters, as well as [ ` TypeVar  ` ](../library/typing.html#typing.TypeVar
"typing.TypeVar") parameters with bounds or constraints:

    
    
    type IntFunc[**P] = Callable[P, int]  # ParamSpec
    type LabeledTuple[*Ts] = tuple[str, *Ts]  # TypeVarTuple
    type HashableSequence[T: Hashable] = Sequence[T]  # TypeVar with bound
    type IntOrStrSequence[T: (int, str)] = Sequence[T]  # TypeVar with constraints
    

The value of type aliases and the bound and constraints of type variables
created through this syntax are evaluated only on demand (see [ lazy
evaluation  ](../reference/executionmodel.html#lazy-evaluation) ). This means
type aliases are able to refer to other types defined later in the file.

Type parameters declared through a type parameter list are visible within the
scope of the declaration and any nested scopes, but not in the outer scope.
For example, they can be used in the type annotations for the methods of a
generic class or in the class body. However, they cannot be used in the module
scope after the class is defined. See [ Type parameter lists
](../reference/compound_stmts.html#type-params) for a detailed description of
the runtime semantics of type parameters.

In order to support these scoping semantics, a new kind of scope is
introduced, the [ annotation scope
](../reference/executionmodel.html#annotation-scopes) . Annotation scopes
behave for the most part like function scopes, but interact differently with
enclosing class scopes. In Python 3.13, [ annotations
](../glossary.html#term-annotation) will also be evaluated in annotation
scopes.

See  [ **PEP 695** ](https://peps.python.org/pep-0695/) for more details.

(PEP written by Eric Traut. Implementation by Jelle Zijlstra, Eric Traut, and
others in [ gh-103764 ](https://github.com/python/cpython/issues/103764) .)

###  PEP 701: Syntactic formalization of f-strings  Â¶

[ **PEP 701** ](https://peps.python.org/pep-0701/) lifts some restrictions on
the usage of [ f-strings  ](../glossary.html#term-f-string) . Expression
components inside f-strings can now be any valid Python expression, including
strings reusing the same quote as the containing f-string, multi-line
expressions, comments, backslashes, and unicode escape sequences. Letâs
cover these in detail:

  * Quote reuse: in Python 3.11, reusing the same quotes as the enclosing f-string raises a [ ` SyntaxError  ` ](../library/exceptions.html#SyntaxError "SyntaxError") , forcing the user to either use other available quotes (like using double quotes or tr