{"id":5042,"date":"2025-02-18T07:57:40","date_gmt":"2025-02-18T06:57:40","guid":{"rendered":"https:\/\/neogeo.fr\/python-evolutions-from-3-9-to-3-13-typing\/"},"modified":"2026-10-23T16:28:16","modified_gmt":"2026-10-23T14:28:16","slug":"python-evolutions-from-3-9-to-3-13-typing","status":"publish","type":"post","link":"https:\/\/neogeo.fr\/en\/python-evolutions-from-3-9-to-3-13-typing\/","title":{"rendered":"Python Evolutions from 3.9 to 3.13: Typing"},"content":{"rendered":"\n

While the Python<\/a> standard library can be considered stable, the same cannot be said for the typing component, which is currently in a state of rapid development.<\/p>\n\n

As a reminder, typing in Python is optional, which is perfectly fine for small projects and scripts. However, as soon as a project grows in scale, typing function parameters helps maintain rigor and forces one to consider the correct data flows within the program. <\/p>\n\n

Version 3.9<\/h2>\n\n

In Python version 3.9, there is only one evolution in typing, but it significantly improves readability and simplifies typing-related code: built-in types (list, dict…)<\/mark><\/em> can now be used to declare typing. \ud83c\udf89<\/p>\n\n

class Foo:\n    def add_items(self, items: list[str]) -> None:\n\t\t\t    ...<\/code><\/pre>\n\n
I do not know about you, but for me, this reduces the entry barrier for typing so much that I would not mind integrating it even into small scripts.<\/p>\n\n
Version 3.10<\/h2>\n\n
Since Python version 3.10, the | <\/strong><\/mark>operator can now be used to declare type unions (where a function accepts several different types, or to make them optional):<\/p>\n\n
class Foo:\n    def set_color(self, color: str|Color|None) -> None:\n        ...\n\n    def get_color(self) -> Color|None:\n\t\t\t    ...<\/code><\/pre>\n\n
A major effort was also made in this version to provide genericity in typing. For example, when defining a decorator, the type of the decorated function is not always known in advance. From now on, ParamSpec <\/mark><\/em>can be used to indicate an unknown type.  <\/p>\n\n
Further clarity was also introduced with the addition of TypeAlias <\/mark><\/em>, which allows giving an explicit name to a complex type.<\/p>\n\n
StrCache: TypeAlias = 'Cache[str]'<\/code><\/pre>\n\n
To create small functions that verify types (is_bool, is_string<\/em><\/mark>, etc.), TypeGuards <\/em><\/mark>were introduced. TypeGuards <\/em><\/mark>are used for a rather complex practice called type narrowing. The latter is used for functions that accept input variables with several possible types. TypeGuard<\/em><\/mark> then allows for type checking to be implemented on the function’s input variables.   <\/p>\n\n
\ud83d\udd0eThe use of TypeGuards <\/em><\/mark>is not very simple, so I invite you to look at the Python documentation<\/a> in more detail if you are interested. <\/p>\n\n
Version 3.11<\/h2>\n\n
Continuing with complex additions, version 3.11 introduced Generic <\/em><\/mark>Variadics<\/strong><\/em> <\/mark>to handle sets of elements with fixed sizes (a tensor with a fixed size, for example).<\/p>\n\n
A generic<\/strong> <\/mark><\/em>allows preserving a type between the input and output of a function. For example, if we take a function that copies a variable, it takes a variable as input which can be of any type, so we would type it as Any<\/em><\/mark>. Since the function returns a copy of the input variable, the return type of the function will be the same as that of the input variable (Any<\/em><\/mark>).  <\/p>\n\n
The problem is that with Any<\/em><\/mark>, there is no way to verify that the input and output types are the same, and this is where the generic<\/strong> <\/mark><\/em>comes into play.<\/p>\n\n
def copy_of_1(value: Any) -> Any: # Le Any d'entr\u00e9e et \n                                  # le Any de sortie \n                                  # ne sont pas forc\u00e9s \n                                  # d'\u00eatre du m\u00eame type\n    return deepcopy(value)\n\n\nT = TypeVar("T")\n\ndef copy_of_2(value: T) -> T:     # Les variables en entr\u00e9e \n                                  # et en sortie sont forc\u00e9es \n                                  # d'\u00eatre du m\u00eame type\n    return deepcopy(value)<\/code><\/pre>\n\n
Generic Variadics<\/em><\/mark>, on the other hand, are more complex and allow for handling multi-dimensional types. \ud83d\udd0eHere again, the implementation is subtle; I invite you to read the official documentation<\/a>.  <\/p>\n\n
However, among the small additions that can be useful to everyone, there are the Required <\/em><\/mark>and NotRequired <\/em><\/mark>types in TypedDict<\/em><\/mark>:<\/p>\n\n
class Shape(TypedDict):\n    x: Required[int]\n    y: Required[int]\n    color: NotRequired[int]<\/code><\/pre>\n\n
The Self<\/em> <\/mark>type was also added, which is very practical for creating a constructor:<\/p>\n\n
class Shape:\n    @classmethod\n    def new(cls, x: int, y: int) -> Self:\n        ...<\/code><\/pre>\n\n
A LiteralString <\/em><\/mark>type was also added. It can be used to indicate that a function parameter can be any type of literal string (a string hard-coded in the source, such as “Hello World!”). <\/p>\n\n
This type is primarily useful for enhancing security \ud83d\udcaa because it indicates that a variable must be hard-coded. Unlike a simple str<\/em><\/mark>, this type ensures that the value comes directly from the source code without dynamic transformation. Thus, LiteralString <\/em><\/mark>establishes an important distinction between strings explicitly defined in the code and those obtained dynamically.  <\/p>\n\n
\ud83e\uddd0 If you are the type who likes to dig deeper (or if you are simply stubborn like me), here is what I understood about how LiteralString <\/em><\/mark>works:<\/p>\n\n
The LiteralString <\/em><\/mark>allows you to add a bit of security and rigor to your code without having overly drastic typing. To better visualize this, we can take a log<\/mark><\/strong> display function as an example. <\/p>\n\n
def log(level: str, message: str):\n    if level == "Error":\n        print(message)\n\nlevel = "Error" + "\\u200b"  # "Error" avec un caract\u00e8re invisible (Zero Width Space)\nlog(level, "Ce message s'affiche !")<\/code><\/pre>\n\n
With this version of the function, we can see there is a security issue because our message will be displayed even if the level <\/em><\/mark>variable is not exactly equal to Error<\/em><\/mark>. Not a big deal, you might say. And indeed, it is not very important for a log<\/strong> function, but if it were about managing your databases…  <\/p>\n\n
Conversely, we have Literal<\/em><\/mark> at the extreme end of typing:<\/p>\n\n
from typing import Literal\n\nERROR: Literal["Error"] = "Error"\n\ndef log(level: Literal["Error"], message: str):\n    if level == ERROR:\n        print(message)\n\nlog(ERROR, "Ce message s'affiche !") # Pas d'alert sur le type\n\nlevel = "Error" + "\\u200b"  # "Erreur" avec un caract\u00e8re invisible (Zero Width Space)\nlog(level, "Ce message ne s'affichera pas !") # Une erreur de type sera indiqu\u00e9e<\/code><\/pre>\n\n
With this version of the function, we strictly control the type of the input level <\/em><\/mark>variable. However, as soon as the number of possible input types increases, the syntax becomes laborious. Similarly, it may not be possible to know all possible input types in advance (in the case of external components).  <\/p>\n\n
from typing import Literal\n\nINFO: Literal["Info"] = "Info"\nWARNING: Literal["Warning"] = "Warning"\nERROR: Literal["Error"] = "Error"\n\ndef log(external_component: ???, # Le type n'est pas connu\n        level: Literal["Info", "Warning", "Error", ...], # On pourrait avoir beaucoup de types possibles\n        message: str):\n    if level == ERROR:\n        print(message)<\/code><\/pre>\n\n
To remedy these two situations, the compromise of LiteralString <\/em><\/mark>was found:<\/p>\n\n
from typing import LiteralString, Literal\n\nINFO: Literal["Info"] = "Info"\nWARNING: Literal["Warning"] = "Warning"\nERROR: Literal["Error"] = "Error"\n\ndef log(external_component: LiteralString, level: LiteralString, message: str):\n    if level == ERROR:\n        print(message)\n\nlog(INFO, "Ce message ne s'affichera pas !") # Pas d'alert sur le type\nlog(WARNING, "Ce message ne s'affichera pas !") # Pas d'alert sur le type\nlog(ERROR, "Ce message s'affiche !") # Pas d'alert sur le type<\/code><\/pre>\n\n
It is also possible to use both Literal<\/em><\/mark> and LiteralString <\/em><\/mark>:<\/p>\n\n
from typing import LiteralString, Literal\n\nINFO: LiteralString = "Info" # On d\u00e9finit INFO avec un type moins pr\u00e9cis\nWARNING: Literal["Warning"] = "Warning"\nERROR: Literal["Error"] = "Error"\n\ndef log(external_component: LiteralString, \n        level: Literal["Warning", "Error"], # Level est soit du type Literal["Warning"] soit du type Literal["Error"]\n        message: str):\n    if level == ERROR:\n        print(message)\n\nlog(INFO, "Ce message ne s'affichera pas !") # Alerte sur le type\n\nlog(WARNING, "Ce message ne s'affichera pas !") # Pas d'alerte sur le type\nlog(ERROR, "Ce message s'affiche !") # Pas d'alerte sur le type\nlog(WARNING+ERROR, "Ce message ne s'affichera pas !") # Pas d'alerte sur le type. Pas tr\u00e8s int\u00e9ressant mais pourquoi pas ...<\/code><\/pre>\n\n
From the two previous examples, we can conclude that LiteralString <\/em><\/mark> groups all   Literal[<…>]  <\/em><\/mark><\/strong>where  <…><\/em><\/mark> <\/mark><\/strong>is a character string. Thus, we deduce that LiteralString <\/em><\/mark>is the supertype<\/strong> <\/mark>of all literal string types. <\/p>\n\n
\ud83d\udea8Therefore, any “subtype” of LiteralString <\/em><\/mark>(Literal[“Error”] <\/em><\/mark>or even Literal[“Warning”]<\/em><\/mark>) is compatible with LiteralString <\/em><\/mark>, but not the other way around (refer to the INFO<\/strong> variable in the previous example). <\/p>\n\n
\ud83d\udea8Similarly, the supertype<\/strong> LiteralString <\/em><\/mark>is itself a str<\/em><\/mark>, making str<\/em><\/mark> a super supertype<\/strong>. <\/p>\n\n
\ud83d\udea8Finally, using the same logic as before, we deduce that a str<\/em><\/mark> is not compatible with a LiteralString <\/em><\/mark>. By this, we mean that it is possible to assign a LiteralString <\/em><\/mark>to a str<\/em><\/mark>, but not vice versa.  <\/p>\n\n
literal_string: LiteralString\ns: str = literal_string                 # OK\n\nliteral_string: LiteralString = s       # Erreur : \n                                        # On attendait un\n                                        # LiteralString, \n                                        # on a un str\nliteral_string: LiteralString = "hello" # OK<\/code><\/pre>\n\n
A string created by composing LiteralString <\/em><\/mark>typed objects is, for its part, acceptable as a LiteralString <\/em><\/mark>(as with Literal<\/em><\/mark>).<\/p>\n\n
literal_string_1: LiteralString = "Hello"\nliteral_string_2: LiteralString = " World"\n\ncomposed_string: LiteralString = literal_string_1 + literal_string_2 + " !"  # Toujours un LiteralString<\/code><\/pre>\n\n
This type is useful for sensitive APIs where arbitrary user-generated strings could cause issues. <\/p>\n\n
\ud83d\udd0eFor more examples, you can refer to the official Python documentation<\/a>.<\/p>\n\n
Regarding decorators, version 3.11 adds dataclass_transform<\/em><\/mark>, which is applicable to a class, a metaclass, or a decorator. This decorator allows marking an object as providing dataclass <\/em><\/mark>-like behavior while performing type checking. <\/p>\n\n
As a reminder, the dataclass<\/em><\/mark> decorator adds generated and special methods to a class. For example, we will have methods like __init__<\/em><\/mark>, __repr__ <\/em><\/mark>or __eq__<\/em><\/mark>. <\/p>\n\n
# Le d\u00e9corateur create_model est d\u00e9fini par une biblioth\u00e8que.\n@typing.dataclass_transform()\ndef create_model(cls: Type[T]) -> Type[T]:\n    cls.__init__ = ...\n    cls.__eq__ = ...\n    cls.__ne__ = ...\n    return cls\n\n# Le d\u00e9corateur create_model peut d\u00e9sormais \u00eatre utilis\u00e9 \n# pour cr\u00e9er de nouvelles classes de mod\u00e8les :\n@create_model\nclass CustomerModel:\n    id: int\n    name: str\n\nc = CustomerModel(id=327, name="Eric Idle")<\/code><\/pre>\n\n
Version 3.12<\/h2>\n\n
Version 3.12, for its part, introduces the use of the TypedDict <\/em><\/mark>dictionary type to achieve more precise typing of arguments (**kwargs<\/em><\/mark>).<\/p>\n\n
Before this addition, **kwargs<\/em><\/mark> could be typed provided that all the keyword arguments they specified were of the same type. However, this behavior was very limiting. For example, annotating **kwargs<\/em><\/mark> with a str<\/em><\/mark> type means that the **kwargs<\/em><\/mark> type is actually a  dict[str, str]<\/em><\/mark> and therefore all keyword arguments in foo<\/em> <\/mark>are strings.  <\/p>\n\n
def foo(**kwargs: str) -> None: ...<\/code><\/pre>\n\n
Unfortunately, it often happens that keyword arguments passed via **kwargs<\/em><\/mark> have different types depending on the keyword name. In such cases, it was not possible to annotate the type of the **kwargs<\/em><\/mark>. <\/p>\n\n
Now, by using TypedDict<\/em><\/mark> to type **kwargs<\/em><\/mark>, it is possible to assign a dictionary as the type for **kwargs<\/em><\/mark>. Thus, **kwargs<\/em><\/mark> can be typed separately (by dictionary key). <\/p>\n\n
from typing import TypedDict, Unpack\n\nclass Movie(TypedDict):\n  name: str\n  year: int\n\ndef foo(**kwargs: Unpack[Movie]): ...<\/code><\/pre>\n\n
\ud83d\udd0eFor more details, I invite you to consult the official Python documentation<\/a>. <\/p>\n\n
Version 3.12 also offers a new override <\/em><\/mark>decorator that will undoubtedly be useful for a large majority. The latter indicates that a method in a subclass is intended to override a method (or an attribute) in a parent class. <\/p>\n\n
\u2728This version also brings new syntactic features to create generic classes and functions in an explicit and compact way. <\/p>\n\n
def max[T](args: Iterable[T]) -> T:\n    ...\n\nclass list[T]:\n    def __getitem__(self, index: int, \/) -> T:\n        ...\n\n    def append(self, element: T) -> None:\n        ...<\/code><\/pre>\n\n
Additionally, a new way to declare type aliases is introduced. As shown in the following example, the type <\/em><\/mark>statement is used, which creates an instance of TypeAliasType <\/em><\/mark>and makes the declaration explicit. <\/p>\n\n
type Point = tuple[float, float]<\/code><\/pre>\n\n
Version 3.13<\/h2>\n\n
With version 3.13, it is now possible to define a default value for type parameters (TypeVar, ParamSpec<\/em><\/mark>, and  TypeVarTuple<\/em><\/mark>).<\/p>\n\n
T = TypeVar("T", default=int) # Si aucun type n'est sp\u00e9cifi\u00e9, \n                              # T sera de type int\n\n@dataclass\nclass Box(Generic[T]):\n    value: T | None = None\n\nreveal_type(Box())                      # Le type est Box[int]\nreveal_type(Box(value="Hello World!"))  # Le type est Box[str]<\/code><\/pre>\n\n
It is also possible, since this version, to mark a class or a function as deprecated using the new deprecated<\/em><\/mark> decorator. Thus, developers can be informed when they use these classes and functions so they can implement the necessary migrations. <\/p>\n\n
Another very useful small addition is the ReadOnly <\/em><\/mark>qualifier for the TypedDict <\/em><\/mark>type, which allows defining certain keys as read-only. The correct use of these read-only keys is intended to be enforced only by static type checkers and not by Python itself at runtime. <\/p>\n\n
Finally, version 3.13 revisits its addition of TypeGuard <\/em><\/mark>from version 3.10. This version offers a more intuitive alternative to TypeGuard: TypeIs<\/em><\/mark>. This new form allows for the annotation of functions that can be used to refine the type of a value.  <\/p>\n\n
from typing import assert_type, final, TypeIs\n\nclass Parent: pass\nclass Child(Parent): pass\n@final\nclass Unrelated: pass\n\ndef is_parent(val: object) -> TypeIs[Parent]:\n    return isinstance(val, Parent)\n\ndef run(arg: Child | Unrelated):\n    if is_parent(arg):\n        # Le type de ``arg`` est r\u00e9duit \u00e0 l'intersection entre \n        # ``Parent`` et ``Child``, \n        # ce qui \u00e9quivaut \u00e0 ``Child``.\n        assert_type(arg, Child)\n    else:\n        # Le type de ``arg`` est r\u00e9duit pour exclure ``Parent``, \n        # de sorte qu'il ne reste que ``Unrelated``.\n        assert_type(arg, Unrelated)<\/code><\/pre>\n\n
Unlike the existing TypeGuard <\/em><\/mark>special form, TypeIs<\/em><\/mark> can refine the type in both the if <\/em><\/mark>and else <\/em><\/mark>branches of a condition. However, TypeIs<\/em><\/mark> cannot be used when the input and output types are incompatible (for example, list[object] to list[int]<\/em><\/mark>), or when the function does not return True <\/em><\/mark>for all instances of the narrowed type.  <\/p>\n\n
\ud83d\udd0eFor more details, I refer you to the official documentation<\/a>. <\/p>\n\n
Conclusion<\/h2>\n\n
\ud83d\udcc8We can see that typing in Python is in full evolution, with each version bringing its share of improvements to make it more expressive, more robust, and easier to use. <\/p>\n\n
Recent additions, such as Self, LiteralString, TypedDict<\/em><\/mark> or override<\/em><\/mark>, show a desire to make typing more intuitive and useful in concrete scenarios.<\/p>\n\n
With version 3.13, Python continues on this path by offering more flexible tools and readjusting certain decisions, such as the TypeIs<\/em><\/mark> alternative for TypeGuard<\/em><\/mark>.<\/p>\n\n
\ud83d\udc49In summary, typing in Python presents advantages (and also, sometimes, disadvantages) that deserve to be taken into account in your developments.<\/p>\n\n
\u2795 On one hand, it brings better security by reducing the risk of bugs and attacks. By imposing clear types, it also allows for better code readability, especially when structures and workflows become more complex. This facilitates not only maintenance but also the handover of code to other developers, thus making collaboration smoother.  <\/p>\n\n
\u2796 However, typing in Python also has some limitations. Certain types or features, such as TypeGuard<\/em><\/mark>, can be difficult to master. Furthermore, some types, such as LiteralString<\/em><\/mark>, do not always bring real added value considering their complexity of use. Finally, the addition of types can sometimes visually clutter the code, which can hinder its readability.   <\/p>\n\n
For my part, I believe it is essential to pay attention to typing. It contributes greatly to the understanding and maintenance of code, especially when it comes to taking over someone else’s work. In my view, it is at the very least necessary to type method prototypes, clearly specifying the types of inputs and outputs. Ultimately, the most important thing remains to discuss typing standards with your team in order to adopt a consistent approach adapted to the project’s needs.   <\/p>\n\n
Regardless, the Python language is gaining maturity, but typing remains a field of innovation. We look forward to discovering its future evolutions! <\/p>\n\n
P.S.: To learn more about Python’s evolutions (excluding typing), I invite you to consult our article entitled “Discover the major evolutions of Python from 3.9 to 3.13”.<\/em><\/p>\n\n
\n\n
Author: Mathilde Pommier<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"
While the Python standard library can be considered stable, the same cannot be said for the typing component, which is currently in a state of rapid development. As a reminder, typing in Python is optional, which is perfectly fine for small projects and scripts. However, as soon as a project grows in scale, typing function … Read more<\/a><\/p>\n","protected":false},"author":5,"featured_media":5043,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[60],"tags":[],"class_list":["post-5042","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized-en"],"yoast_head":"\nPython Typing: What Changes from 3.9 to 3.13 | NEOGEO<\/title>\n<meta name=\"description\" content=\"TypeIs, LiteralString, override, TypedDict for kwargs: the evolutions of Python typing version by version, from 3.9 to 3.13.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/neogeo.fr\/en\/python-evolutions-from-3-9-to-3-13-typing\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Python Typing: What Changes from 3.9 to 3.13 | NEOGEO\" \/>\n<meta property=\"og:description\" content=\"TypeIs, LiteralString, override, TypedDict for kwargs: the evolutions of Python typing version by version, from 3.9 to 3.13.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/neogeo.fr\/en\/python-evolutions-from-3-9-to-3-13-typing\/\" \/>\n<meta property=\"og:site_name\" content=\"NEOGEO\" \/>\n<meta property=\"article:published_time\" content=\"2025-02-18T06:57:40+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-10-23T14:28:16+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/neogeo.fr\/wp-content\/uploads\/2025\/02\/close-up-pattern-scales-1-scaled-1.webp\" \/>\n\t<meta property=\"og:image:width\" content=\"2560\" \/>\n\t<meta property=\"og:image:height\" content=\"1435\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/webp\" \/>\n<meta name=\"author\" content=\"Philippe DESTR\u00c9\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Philippe DESTR\u00c9\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"11 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/python-evolutions-from-3-9-to-3-13-typing\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/python-evolutions-from-3-9-to-3-13-typing\\\/\"},\"author\":{\"name\":\"Philippe DESTR\u00c9\",\"@id\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/#\\\/schema\\\/person\\\/69685e84302b110f77d59dc8ee6e2d40\"},\"headline\":\"Python Evolutions from 3.9 to 3.13: Typing\",\"datePublished\":\"2025-02-18T06:57:40+00:00\",\"dateModified\":\"2026-10-23T14:28:16+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/python-evolutions-from-3-9-to-3-13-typing\\\/\"},\"wordCount\":1778,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/python-evolutions-from-3-9-to-3-13-typing\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/neogeo.fr\\\/wp-content\\\/uploads\\\/2025\\\/02\\\/close-up-pattern-scales-1-scaled-1.webp\",\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/neogeo.fr\\\/en\\\/python-evolutions-from-3-9-to-3-13-typing\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/python-evolutions-from-3-9-to-3-13-typing\\\/\",\"url\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/python-evolutions-from-3-9-to-3-13-typing\\\/\",\"name\":\"Python Typing: What Changes from 3.9 to 3.13 | NEOGEO\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/python-evolutions-from-3-9-to-3-13-typing\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/python-evolutions-from-3-9-to-3-13-typing\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/neogeo.fr\\\/wp-content\\\/uploads\\\/2025\\\/02\\\/close-up-pattern-scales-1-scaled-1.webp\",\"datePublished\":\"2025-02-18T06:57:40+00:00\",\"dateModified\":\"2026-10-23T14:28:16+00:00\",\"description\":\"TypeIs, LiteralString, override, TypedDict for kwargs: the evolutions of Python typing version by version, from 3.9 to 3.13.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/python-evolutions-from-3-9-to-3-13-typing\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/neogeo.fr\\\/en\\\/python-evolutions-from-3-9-to-3-13-typing\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/python-evolutions-from-3-9-to-3-13-typing\\\/#primaryimage\",\"url\":\"https:\\\/\\\/neogeo.fr\\\/wp-content\\\/uploads\\\/2025\\\/02\\\/close-up-pattern-scales-1-scaled-1.webp\",\"contentUrl\":\"https:\\\/\\\/neogeo.fr\\\/wp-content\\\/uploads\\\/2025\\\/02\\\/close-up-pattern-scales-1-scaled-1.webp\",\"width\":2560,\"height\":1435,\"caption\":\"snake skin bright blue --ar 16:9 Job ID: 4d0ffe6a-e315-47c0-87b2-59b605c9495c\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/python-evolutions-from-3-9-to-3-13-typing\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Python Evolutions from 3.9 to 3.13: Typing\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/#website\",\"url\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/\",\"name\":\"NEOGEO\",\"description\":\"Optimisez,\u00a0valorisez,\\u2028partagez\u00a0vos\u00a0donn\u00e9es\u00a0spatiales\",\"publisher\":{\"@id\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/#organization\",\"name\":\"NEOGEO\",\"url\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/neogeo.fr\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/NEOGEO-LOGO.svg\",\"contentUrl\":\"https:\\\/\\\/neogeo.fr\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/NEOGEO-LOGO.svg\",\"width\":145,\"height\":42,\"caption\":\"NEOGEO\"},\"image\":{\"@id\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/#\\\/schema\\\/logo\\\/image\\\/\"}},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/#\\\/schema\\\/person\\\/69685e84302b110f77d59dc8ee6e2d40\",\"name\":\"Philippe DESTR\u00c9\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/b366889cd846213d38b977f63dd60b6af7e9ed5b067a024a76fe0865155ef9db?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/b366889cd846213d38b977f63dd60b6af7e9ed5b067a024a76fe0865155ef9db?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/b366889cd846213d38b977f63dd60b6af7e9ed5b067a024a76fe0865155ef9db?s=96&d=mm&r=g\",\"caption\":\"Philippe DESTR\u00c9\"},\"url\":\"https:\\\/\\\/neogeo.fr\\\/en\\\/author\\\/pdestreneogeo\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Python Typing: What Changes from 3.9 to 3.13 | NEOGEO","description":"TypeIs, LiteralString, override, TypedDict for kwargs: the evolutions of Python typing version by version, from 3.9 to 3.13.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/neogeo.fr\/en\/python-evolutions-from-3-9-to-3-13-typing\/","og_locale":"en_US","og_type":"article","og_title":"Python Typing: What Changes from 3.9 to 3.13 | NEOGEO","og_description":"TypeIs, LiteralString, override, TypedDict for kwargs: the evolutions of Python typing version by version, from 3.9 to 3.13.","og_url":"https:\/\/neogeo.fr\/en\/python-evolutions-from-3-9-to-3-13-typing\/","og_site_name":"NEOGEO","article_published_time":"2025-02-18T06:57:40+00:00","article_modified_time":"2026-10-23T14:28:16+00:00","og_image":[{"width":2560,"height":1435,"url":"https:\/\/neogeo.fr\/wp-content\/uploads\/2025\/02\/close-up-pattern-scales-1-scaled-1.webp","type":"image\/webp"}],"author":"Philippe DESTR\u00c9","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Philippe DESTR\u00c9","Est. reading time":"11 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/neogeo.fr\/en\/python-evolutions-from-3-9-to-3-13-typing\/#article","isPartOf":{"@id":"https:\/\/neogeo.fr\/en\/python-evolutions-from-3-9-to-3-13-typing\/"},"author":{"name":"Philippe DESTR\u00c9","@id":"https:\/\/neogeo.fr\/en\/#\/schema\/person\/69685e84302b110f77d59dc8ee6e2d40"},"headline":"Python Evolutions from 3.9 to 3.13: Typing","datePublished":"2025-02-18T06:57:40+00:00","dateModified":"2026-10-23T14:28:16+00:00","mainEntityOfPage":{"@id":"https:\/\/neogeo.fr\/en\/python-evolutions-from-3-9-to-3-13-typing\/"},"wordCount":1778,"commentCount":0,"publisher":{"@id":"https:\/\/neogeo.fr\/en\/#organization"},"image":{"@id":"https:\/\/neogeo.fr\/en\/python-evolutions-from-3-9-to-3-13-typing\/#primaryimage"},"thumbnailUrl":"https:\/\/neogeo.fr\/wp-content\/uploads\/2025\/02\/close-up-pattern-scales-1-scaled-1.webp","inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/neogeo.fr\/en\/python-evolutions-from-3-9-to-3-13-typing\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/neogeo.fr\/en\/python-evolutions-from-3-9-to-3-13-typing\/","url":"https:\/\/neogeo.fr\/en\/python-evolutions-from-3-9-to-3-13-typing\/","name":"Python Typing: What Changes from 3.9 to 3.13 | NEOGEO","isPartOf":{"@id":"https:\/\/neogeo.fr\/en\/#website"},"primaryImageOfPage":{"@id":"https:\/\/neogeo.fr\/en\/python-evolutions-from-3-9-to-3-13-typing\/#primaryimage"},"image":{"@id":"https:\/\/neogeo.fr\/en\/python-evolutions-from-3-9-to-3-13-typing\/#primaryimage"},"thumbnailUrl":"https:\/\/neogeo.fr\/wp-content\/uploads\/2025\/02\/close-up-pattern-scales-1-scaled-1.webp","datePublished":"2025-02-18T06:57:40+00:00","dateModified":"2026-10-23T14:28:16+00:00","description":"TypeIs, LiteralString, override, TypedDict for kwargs: the evolutions of Python typing version by version, from 3.9 to 3.13.","breadcrumb":{"@id":"https:\/\/neogeo.fr\/en\/python-evolutions-from-3-9-to-3-13-typing\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/neogeo.fr\/en\/python-evolutions-from-3-9-to-3-13-typing\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/neogeo.fr\/en\/python-evolutions-from-3-9-to-3-13-typing\/#primaryimage","url":"https:\/\/neogeo.fr\/wp-content\/uploads\/2025\/02\/close-up-pattern-scales-1-scaled-1.webp","contentUrl":"https:\/\/neogeo.fr\/wp-content\/uploads\/2025\/02\/close-up-pattern-scales-1-scaled-1.webp","width":2560,"height":1435,"caption":"snake skin bright blue --ar 16:9 Job ID: 4d0ffe6a-e315-47c0-87b2-59b605c9495c"},{"@type":"BreadcrumbList","@id":"https:\/\/neogeo.fr\/en\/python-evolutions-from-3-9-to-3-13-typing\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/neogeo.fr\/en\/"},{"@type":"ListItem","position":2,"name":"Python Evolutions from 3.9 to 3.13: Typing"}]},{"@type":"WebSite","@id":"https:\/\/neogeo.fr\/en\/#website","url":"https:\/\/neogeo.fr\/en\/","name":"NEOGEO","description":"Optimisez,\u00a0valorisez,\u2028partagez\u00a0vos\u00a0donn\u00e9es\u00a0spatiales","publisher":{"@id":"https:\/\/neogeo.fr\/en\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/neogeo.fr\/en\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/neogeo.fr\/en\/#organization","name":"NEOGEO","url":"https:\/\/neogeo.fr\/en\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/neogeo.fr\/en\/#\/schema\/logo\/image\/","url":"https:\/\/neogeo.fr\/wp-content\/uploads\/2026\/06\/NEOGEO-LOGO.svg","contentUrl":"https:\/\/neogeo.fr\/wp-content\/uploads\/2026\/06\/NEOGEO-LOGO.svg","width":145,"height":42,"caption":"NEOGEO"},"image":{"@id":"https:\/\/neogeo.fr\/en\/#\/schema\/logo\/image\/"}},{"@type":"Person","@id":"https:\/\/neogeo.fr\/en\/#\/schema\/person\/69685e84302b110f77d59dc8ee6e2d40","name":"Philippe DESTR\u00c9","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/b366889cd846213d38b977f63dd60b6af7e9ed5b067a024a76fe0865155ef9db?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/b366889cd846213d38b977f63dd60b6af7e9ed5b067a024a76fe0865155ef9db?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/b366889cd846213d38b977f63dd60b6af7e9ed5b067a024a76fe0865155ef9db?s=96&d=mm&r=g","caption":"Philippe DESTR\u00c9"},"url":"https:\/\/neogeo.fr\/en\/author\/pdestreneogeo\/"}]}},"_links":{"self":[{"href":"https:\/\/neogeo.fr\/en\/wp-json\/wp\/v2\/posts\/5042","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/neogeo.fr\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/neogeo.fr\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/neogeo.fr\/en\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/neogeo.fr\/en\/wp-json\/wp\/v2\/comments?post=5042"}],"version-history":[{"count":1,"href":"https:\/\/neogeo.fr\/en\/wp-json\/wp\/v2\/posts\/5042\/revisions"}],"predecessor-version":[{"id":5044,"href":"https:\/\/neogeo.fr\/en\/wp-json\/wp\/v2\/posts\/5042\/revisions\/5044"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/neogeo.fr\/en\/wp-json\/wp\/v2\/media\/5043"}],"wp:attachment":[{"href":"https:\/\/neogeo.fr\/en\/wp-json\/wp\/v2\/media?parent=5042"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/neogeo.fr\/en\/wp-json\/wp\/v2\/categories?post=5042"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/neogeo.fr\/en\/wp-json\/wp\/v2\/tags?post=5042"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}