📝 Update documentation to refer to list instead of List

docs/tutorial/code-structure.md

@@ -183,7 +183,7 @@ And this ends up *requiring* the same **circular imports** that are not supporte
 
 But these **type annotations** we want to declare are not needed at *runtime*.
 
-In fact, remember that we used `List["Hero"]`, with a `"Hero"` in a string?
+In fact, remember that we used `list["Hero"]`, with a `"Hero"` in a string?
 
 For Python, at runtime, that is **just a string**.
 

docs/tutorial/fastapi/response-model.md

@@ -38,7 +38,7 @@ For example, we can pass the same `Hero` **SQLModel** class (because it is also
 
 We can also use other type annotations, the same way we can use with Pydantic fields. For example, we can pass a list of `Hero`s.
 
-First, we import `List` from `typing` and then we declare the `response_model` with `List[Hero]`:
+To do so, we declare the `response_model` with `list[Hero]`:
 
 {* ./docs_src/tutorial/fastapi/response_model/tutorial001_py310.py ln[40:44] hl[40] *}
 

docs/tutorial/many-to-many/create-models-with-link.md

@@ -28,7 +28,7 @@ Let's see the `Team` model, it's almost identical as before, but with a little c
 
 {* ./docs_src/tutorial/many_to_many/tutorial001_py310.py ln[9:14] hl[14] *}
 
-The **relationship attribute `heroes`** is still a list of heroes, annotated as `List["Hero"]`. Again, we use `"Hero"` in quotes because we haven't declared that class yet by this point in the code (but as you know, editors and **SQLModel** understand that).
+The **relationship attribute `heroes`** is still a list of heroes, annotated as `list["Hero"]`. Again, we use `"Hero"` in quotes because we haven't declared that class yet by this point in the code (but as you know, editors and **SQLModel** understand that).
 
 We use the same **`Relationship()`** function.
 
@@ -46,7 +46,7 @@ We **removed** the previous `team_id` field (column) because now the relationshi
 
 The relationship attribute is now named **`teams`** instead of `team`, as now we support multiple teams.
 
-It is no longer an `Optional[Team]` but a list of teams, annotated as **`List[Team]`**.
+It is no longer an `Optional[Team]` but a list of teams, annotated as **`list[Team]`**.
 
 We are using the **`Relationship()`** here too.
 

docs/tutorial/relationship-attributes/define-relationships-attributes.md

@@ -86,7 +86,7 @@ And in the `Team` class, the `heroes` attribute is annotated as a list of `Hero`
 
 /// tip
 
-There's a couple of things we'll check again in some of the next chapters, about the `List["Hero"]` and the `back_populates`.
+There's a couple of things we'll check again in some of the next chapters, about the `list["Hero"]` and the `back_populates`.
 
 But for now, let's first see how to use these relationship attributes.
 

docs/tutorial/relationship-attributes/type-annotation-strings.md

@@ -1,10 +1,10 @@
-## About the String in `List["Hero"]`
+## About the String in `list["Hero"]`
 
-In the first Relationship attribute, we declare it with `List["Hero"]`, putting the `Hero` in quotes instead of just normally there:
+In the first Relationship attribute, we declare it with `list["Hero"]`, putting the `Hero` in quotes instead of just normally there:
 
 {* ./docs_src/tutorial/relationship_attributes/define_relationship_attributes/tutorial001_py310.py ln[1:19] hl[9] *}
 
-What's that about? Can't we just write it normally as `List[Hero]`?
+What's that about? Can't we just write it normally as `list[Hero]`?
 
 By that point, in that line in the code, the Python interpreter **doesn't know of any class `Hero`**, and if we put it just there, it would try to find it unsuccessfully, and then fail. 😭
 

docs/tutorial/code-structure.md

@@ -183,7 +183,7 @@ And this ends up *requiring* the same **circular imports** that are not supporte
 
 But these **type annotations** we want to declare are not needed at *runtime*.
 
-In fact, remember that we used `List["Hero"]`, with a `"Hero"` in a string?
+In fact, remember that we used `list["Hero"]`, with a `"Hero"` in a string?
 
 For Python, at runtime, that is **just a string**.
 

docs/tutorial/fastapi/response-model.md

@@ -38,7 +38,7 @@ For example, we can pass the same `Hero` **SQLModel** class (because it is also
 
 We can also use other type annotations, the same way we can use with Pydantic fields. For example, we can pass a list of `Hero`s.
 
-First, we import `List` from `typing` and then we declare the `response_model` with `List[Hero]`:
+To do so, we declare the `response_model` with `list[Hero]`:
 
 {* ./docs_src/tutorial/fastapi/response_model/tutorial001_py310.py ln[40:44] hl[40] *}
 

docs/tutorial/many-to-many/create-models-with-link.md

@@ -28,7 +28,7 @@ Let's see the `Team` model, it's almost identical as before, but with a little c
 
 {* ./docs_src/tutorial/many_to_many/tutorial001_py310.py ln[9:14] hl[14] *}
 
-The **relationship attribute `heroes`** is still a list of heroes, annotated as `List["Hero"]`. Again, we use `"Hero"` in quotes because we haven't declared that class yet by this point in the code (but as you know, editors and **SQLModel** understand that).
+The **relationship attribute `heroes`** is still a list of heroes, annotated as `list["Hero"]`. Again, we use `"Hero"` in quotes because we haven't declared that class yet by this point in the code (but as you know, editors and **SQLModel** understand that).
 
 We use the same **`Relationship()`** function.
 
@@ -46,7 +46,7 @@ We **removed** the previous `team_id` field (column) because now the relationshi
 
 The relationship attribute is now named **`teams`** instead of `team`, as now we support multiple teams.
 
-It is no longer an `Optional[Team]` but a list of teams, annotated as **`List[Team]`**.
+It is no longer an `Optional[Team]` but a list of teams, annotated as **`list[Team]`**.
 
 We are using the **`Relationship()`** here too.
 

docs/tutorial/relationship-attributes/define-relationships-attributes.md

@@ -86,7 +86,7 @@ And in the `Team` class, the `heroes` attribute is annotated as a list of `Hero`
 
 /// tip
 
-There's a couple of things we'll check again in some of the next chapters, about the `List["Hero"]` and the `back_populates`.
+There's a couple of things we'll check again in some of the next chapters, about the `list["Hero"]` and the `back_populates`.
 
 But for now, let's first see how to use these relationship attributes.
 

docs/tutorial/relationship-attributes/type-annotation-strings.md

@@ -1,10 +1,10 @@
-## About the String in `List["Hero"]`
+## About the String in `list["Hero"]`
 
-In the first Relationship attribute, we declare it with `List["Hero"]`, putting the `Hero` in quotes instead of just normally there:
+In the first Relationship attribute, we declare it with `list["Hero"]`, putting the `Hero` in quotes instead of just normally there:
 
 {* ./docs_src/tutorial/relationship_attributes/define_relationship_attributes/tutorial001_py310.py ln[1:19] hl[9] *}
 
-What's that about? Can't we just write it normally as `List[Hero]`?
+What's that about? Can't we just write it normally as `list[Hero]`?
 
 By that point, in that line in the code, the Python interpreter **doesn't know of any class `Hero`**, and if we put it just there, it would try to find it unsuccessfully, and then fail. 😭
 

docs/tutorial/code-structure.md

@@ -183,7 +183,7 @@ And this ends up *requiring* the same **circular imports** that are not supporte
 
 But these **type annotations** we want to declare are not needed at *runtime*.
 
-In fact, remember that we used `List["Hero"]`, with a `"Hero"` in a string?
+In fact, remember that we used `list["Hero"]`, with a `"Hero"` in a string?
 
 For Python, at runtime, that is **just a string**.
 

docs/tutorial/fastapi/response-model.md

@@ -38,7 +38,7 @@ For example, we can pass the same `Hero` **SQLModel** class (because it is also
 
 We can also use other type annotations, the same way we can use with Pydantic fields. For example, we can pass a list of `Hero`s.
 
-First, we import `List` from `typing` and then we declare the `response_model` with `List[Hero]`:
+To do so, we declare the `response_model` with `list[Hero]`:
 
 {* ./docs_src/tutorial/fastapi/response_model/tutorial001_py310.py ln[40:44] hl[40] *}
 

docs/tutorial/many-to-many/create-models-with-link.md

@@ -28,7 +28,7 @@ Let's see the `Team` model, it's almost identical as before, but with a little c
 
 {* ./docs_src/tutorial/many_to_many/tutorial001_py310.py ln[9:14] hl[14] *}
 
-The **relationship attribute `heroes`** is still a list of heroes, annotated as `List["Hero"]`. Again, we use `"Hero"` in quotes because we haven't declared that class yet by this point in the code (but as you know, editors and **SQLModel** understand that).
+The **relationship attribute `heroes`** is still a list of heroes, annotated as `list["Hero"]`. Again, we use `"Hero"` in quotes because we haven't declared that class yet by this point in the code (but as you know, editors and **SQLModel** understand that).
 
 We use the same **`Relationship()`** function.
 
@@ -46,7 +46,7 @@ We **removed** the previous `team_id` field (column) because now the relationshi
 
 The relationship attribute is now named **`teams`** instead of `team`, as now we support multiple teams.
 
-It is no longer an `Optional[Team]` but a list of teams, annotated as **`List[Team]`**.
+It is no longer an `Optional[Team]` but a list of teams, annotated as **`list[Team]`**.
 
 We are using the **`Relationship()`** here too.
 

docs/tutorial/relationship-attributes/define-relationships-attributes.md

@@ -86,7 +86,7 @@ And in the `Team` class, the `heroes` attribute is annotated as a list of `Hero`
 
 /// tip
 
-There's a couple of things we'll check again in some of the next chapters, about the `List["Hero"]` and the `back_populates`.
+There's a couple of things we'll check again in some of the next chapters, about the `list["Hero"]` and the `back_populates`.
 
 But for now, let's first see how to use these relationship attributes.
 

docs/tutorial/relationship-attributes/type-annotation-strings.md

@@ -1,10 +1,10 @@
-## About the String in `List["Hero"]`
+## About the String in `list["Hero"]`
 
-In the first Relationship attribute, we declare it with `List["Hero"]`, putting the `Hero` in quotes instead of just normally there:
+In the first Relationship attribute, we declare it with `list["Hero"]`, putting the `Hero` in quotes instead of just normally there:
 
 {* ./docs_src/tutorial/relationship_attributes/define_relationship_attributes/tutorial001_py310.py ln[1:19] hl[9] *}
 
-What's that about? Can't we just write it normally as `List[Hero]`?
+What's that about? Can't we just write it normally as `list[Hero]`?
 
 By that point, in that line in the code, the Python interpreter **doesn't know of any class `Hero`**, and if we put it just there, it would try to find it unsuccessfully, and then fail. 😭
 

docs/tutorial/code-structure.md

@@ -183,7 +183,7 @@ And this ends up *requiring* the same **circular imports** that are not supporte
 
 But these **type annotations** we want to declare are not needed at *runtime*.
 
-In fact, remember that we used `List["Hero"]`, with a `"Hero"` in a string?
+In fact, remember that we used `list["Hero"]`, with a `"Hero"` in a string?
 
 For Python, at runtime, that is **just a string**.
 

docs/tutorial/fastapi/response-model.md

@@ -38,7 +38,7 @@ For example, we can pass the same `Hero` **SQLModel** class (because it is also
 
 We can also use other type annotations, the same way we can use with Pydantic fields. For example, we can pass a list of `Hero`s.
 
-First, we import `List` from `typing` and then we declare the `response_model` with `List[Hero]`:
+To do so, we declare the `response_model` with `list[Hero]`:
 
 {* ./docs_src/tutorial/fastapi/response_model/tutorial001_py310.py ln[40:44] hl[40] *}
 

docs/tutorial/many-to-many/create-models-with-link.md

@@ -28,7 +28,7 @@ Let's see the `Team` model, it's almost identical as before, but with a little c
 
 {* ./docs_src/tutorial/many_to_many/tutorial001_py310.py ln[9:14] hl[14] *}
 
-The **relationship attribute `heroes`** is still a list of heroes, annotated as `List["Hero"]`. Again, we use `"Hero"` in quotes because we haven't declared that class yet by this point in the code (but as you know, editors and **SQLModel** understand that).
+The **relationship attribute `heroes`** is still a list of heroes, annotated as `list["Hero"]`. Again, we use `"Hero"` in quotes because we haven't declared that class yet by this point in the code (but as you know, editors and **SQLModel** understand that).
 
 We use the same **`Relationship()`** function.
 
@@ -46,7 +46,7 @@ We **removed** the previous `team_id` field (column) because now the relationshi
 
 The relationship attribute is now named **`teams`** instead of `team`, as now we support multiple teams.
 
-It is no longer an `Optional[Team]` but a list of teams, annotated as **`List[Team]`**.
+It is no longer an `Optional[Team]` but a list of teams, annotated as **`list[Team]`**.
 
 We are using the **`Relationship()`** here too.
 

docs/tutorial/relationship-attributes/define-relationships-attributes.md

@@ -86,7 +86,7 @@ And in the `Team` class, the `heroes` attribute is annotated as a list of `Hero`
 
 /// tip
 
-There's a couple of things we'll check again in some of the next chapters, about the `List["Hero"]` and the `back_populates`.
+There's a couple of things we'll check again in some of the next chapters, about the `list["Hero"]` and the `back_populates`.
 
 But for now, let's first see how to use these relationship attributes.
 

docs/tutorial/relationship-attributes/type-annotation-strings.md

@@ -1,10 +1,10 @@
-## About the String in `List["Hero"]`
+## About the String in `list["Hero"]`
 
-In the first Relationship attribute, we declare it with `List["Hero"]`, putting the `Hero` in quotes instead of just normally there:
+In the first Relationship attribute, we declare it with `list["Hero"]`, putting the `Hero` in quotes instead of just normally there:
 
 {* ./docs_src/tutorial/relationship_attributes/define_relationship_attributes/tutorial001_py310.py ln[1:19] hl[9] *}
 
-What's that about? Can't we just write it normally as `List[Hero]`?
+What's that about? Can't we just write it normally as `list[Hero]`?
 
 By that point, in that line in the code, the Python interpreter **doesn't know of any class `Hero`**, and if we put it just there, it would try to find it unsuccessfully, and then fail. 😭
 

docs/tutorial/code-structure.md

@@ -183,7 +183,7 @@ And this ends up *requiring* the same **circular imports** that are not supporte
 
 But these **type annotations** we want to declare are not needed at *runtime*.
 
-In fact, remember that we used `List["Hero"]`, with a `"Hero"` in a string?
+In fact, remember that we used `list["Hero"]`, with a `"Hero"` in a string?
 
 For Python, at runtime, that is **just a string**.
 

docs/tutorial/fastapi/response-model.md

@@ -38,7 +38,7 @@ For example, we can pass the same `Hero` **SQLModel** class (because it is also
 
 We can also use other type annotations, the same way we can use with Pydantic fields. For example, we can pass a list of `Hero`s.
 
-First, we import `List` from `typing` and then we declare the `response_model` with `List[Hero]`:
+To do so, we declare the `response_model` with `list[Hero]`:
 
 {* ./docs_src/tutorial/fastapi/response_model/tutorial001_py310.py ln[40:44] hl[40] *}
 

docs/tutorial/many-to-many/create-models-with-link.md

@@ -28,7 +28,7 @@ Let's see the `Team` model, it's almost identical as before, but with a little c
 
 {* ./docs_src/tutorial/many_to_many/tutorial001_py310.py ln[9:14] hl[14] *}
 
-The **relationship attribute `heroes`** is still a list of heroes, annotated as `List["Hero"]`. Again, we use `"Hero"` in quotes because we haven't declared that class yet by this point in the code (but as you know, editors and **SQLModel** understand that).
+The **relationship attribute `heroes`** is still a list of heroes, annotated as `list["Hero"]`. Again, we use `"Hero"` in quotes because we haven't declared that class yet by this point in the code (but as you know, editors and **SQLModel** understand that).
 
 We use the same **`Relationship()`** function.
 
@@ -46,7 +46,7 @@ We **removed** the previous `team_id` field (column) because now the relationshi
 
 The relationship attribute is now named **`teams`** instead of `team`, as now we support multiple teams.
 
-It is no longer an `Optional[Team]` but a list of teams, annotated as **`List[Team]`**.
+It is no longer an `Optional[Team]` but a list of teams, annotated as **`list[Team]`**.
 
 We are using the **`Relationship()`** here too.
 

docs/tutorial/relationship-attributes/define-relationships-attributes.md

@@ -86,7 +86,7 @@ And in the `Team` class, the `heroes` attribute is annotated as a list of `Hero`
 
 /// tip
 
-There's a couple of things we'll check again in some of the next chapters, about the `List["Hero"]` and the `back_populates`.
+There's a couple of things we'll check again in some of the next chapters, about the `list["Hero"]` and the `back_populates`.
 
 But for now, let's first see how to use these relationship attributes.
 

docs/tutorial/relationship-attributes/type-annotation-strings.md

@@ -1,10 +1,10 @@
-## About the String in `List["Hero"]`
+## About the String in `list["Hero"]`
 
-In the first Relationship attribute, we declare it with `List["Hero"]`, putting the `Hero` in quotes instead of just normally there:
+In the first Relationship attribute, we declare it with `list["Hero"]`, putting the `Hero` in quotes instead of just normally there:
 
 {* ./docs_src/tutorial/relationship_attributes/define_relationship_attributes/tutorial001_py310.py ln[1:19] hl[9] *}
 
-What's that about? Can't we just write it normally as `List[Hero]`?
+What's that about? Can't we just write it normally as `list[Hero]`?
 
 By that point, in that line in the code, the Python interpreter **doesn't know of any class `Hero`**, and if we put it just there, it would try to find it unsuccessfully, and then fail. 😭
 

docs/tutorial/code-structure.md

@@ -183,7 +183,7 @@ And this ends up *requiring* the same **circular imports** that are not supporte
 
 But these **type annotations** we want to declare are not needed at *runtime*.
 
-In fact, remember that we used `List["Hero"]`, with a `"Hero"` in a string?
+In fact, remember that we used `list["Hero"]`, with a `"Hero"` in a string?
 
 For Python, at runtime, that is **just a string**.
 

docs/tutorial/fastapi/response-model.md

@@ -38,7 +38,7 @@ For example, we can pass the same `Hero` **SQLModel** class (because it is also
 
 We can also use other type annotations, the same way we can use with Pydantic fields. For example, we can pass a list of `Hero`s.
 
-First, we import `List` from `typing` and then we declare the `response_model` with `List[Hero]`:
+To do so, we declare the `response_model` with `list[Hero]`:
 
 {* ./docs_src/tutorial/fastapi/response_model/tutorial001_py310.py ln[40:44] hl[40] *}
 

docs/tutorial/many-to-many/create-models-with-link.md

@@ -28,7 +28,7 @@ Let's see the `Team` model, it's almost identical as before, but with a little c
 
 {* ./docs_src/tutorial/many_to_many/tutorial001_py310.py ln[9:14] hl[14] *}
 
-The **relationship attribute `heroes`** is still a list of heroes, annotated as `List["Hero"]`. Again, we use `"Hero"` in quotes because we haven't declared that class yet by this point in the code (but as you know, editors and **SQLModel** understand that).
+The **relationship attribute `heroes`** is still a list of heroes, annotated as `list["Hero"]`. Again, we use `"Hero"` in quotes because we haven't declared that class yet by this point in the code (but as you know, editors and **SQLModel** understand that).
 
 We use the same **`Relationship()`** function.
 
@@ -46,7 +46,7 @@ We **removed** the previous `team_id` field (column) because now the relationshi
 
 The relationship attribute is now named **`teams`** instead of `team`, as now we support multiple teams.
 
-It is no longer an `Optional[Team]` but a list of teams, annotated as **`List[Team]`**.
+It is no longer an `Optional[Team]` but a list of teams, annotated as **`list[Team]`**.
 
 We are using the **`Relationship()`** here too.
 

docs/tutorial/relationship-attributes/define-relationships-attributes.md

@@ -86,7 +86,7 @@ And in the `Team` class, the `heroes` attribute is annotated as a list of `Hero`
 
 /// tip
 
-There's a couple of things we'll check again in some of the next chapters, about the `List["Hero"]` and the `back_populates`.
+There's a couple of things we'll check again in some of the next chapters, about the `list["Hero"]` and the `back_populates`.
 
 But for now, let's first see how to use these relationship attributes.
 

docs/tutorial/relationship-attributes/type-annotation-strings.md

@@ -1,10 +1,10 @@
-## About the String in `List["Hero"]`
+## About the String in `list["Hero"]`
 
-In the first Relationship attribute, we declare it with `List["Hero"]`, putting the `Hero` in quotes instead of just normally there:
+In the first Relationship attribute, we declare it with `list["Hero"]`, putting the `Hero` in quotes instead of just normally there:
 
 {* ./docs_src/tutorial/relationship_attributes/define_relationship_attributes/tutorial001_py310.py ln[1:19] hl[9] *}
 
-What's that about? Can't we just write it normally as `List[Hero]`?
+What's that about? Can't we just write it normally as `list[Hero]`?
 
 By that point, in that line in the code, the Python interpreter **doesn't know of any class `Hero`**, and if we put it just there, it would try to find it unsuccessfully, and then fail. 😭
 

docs/tutorial/code-structure.md

@@ -183,7 +183,7 @@ And this ends up *requiring* the same **circular imports** that are not supporte
 
 But these **type annotations** we want to declare are not needed at *runtime*.
 
-In fact, remember that we used `List["Hero"]`, with a `"Hero"` in a string?
+In fact, remember that we used `list["Hero"]`, with a `"Hero"` in a string?
 
 For Python, at runtime, that is **just a string**.
 

docs/tutorial/fastapi/response-model.md

@@ -38,7 +38,7 @@ For example, we can pass the same `Hero` **SQLModel** class (because it is also
 
 We can also use other type annotations, the same way we can use with Pydantic fields. For example, we can pass a list of `Hero`s.
 
-First, we import `List` from `typing` and then we declare the `response_model` with `List[Hero]`:
+To do so, we declare the `response_model` with `list[Hero]`:
 
 {* ./docs_src/tutorial/fastapi/response_model/tutorial001_py310.py ln[40:44] hl[40] *}
 

docs/tutorial/many-to-many/create-models-with-link.md

@@ -28,7 +28,7 @@ Let's see the `Team` model, it's almost identical as before, but with a little c
 
 {* ./docs_src/tutorial/many_to_many/tutorial001_py310.py ln[9:14] hl[14] *}
 
-The **relationship attribute `heroes`** is still a list of heroes, annotated as `List["Hero"]`. Again, we use `"Hero"` in quotes because we haven't declared that class yet by this point in the code (but as you know, editors and **SQLModel** understand that).
+The **relationship attribute `heroes`** is still a list of heroes, annotated as `list["Hero"]`. Again, we use `"Hero"` in quotes because we haven't declared that class yet by this point in the code (but as you know, editors and **SQLModel** understand that).
 
 We use the same **`Relationship()`** function.
 
@@ -46,7 +46,7 @@ We **removed** the previous `team_id` field (column) because now the relationshi
 
 The relationship attribute is now named **`teams`** instead of `team`, as now we support multiple teams.
 
-It is no longer an `Optional[Team]` but a list of teams, annotated as **`List[Team]`**.
+It is no longer an `Optional[Team]` but a list of teams, annotated as **`list[Team]`**.
 
 We are using the **`Relationship()`** here too.
 

docs/tutorial/relationship-attributes/define-relationships-attributes.md

@@ -86,7 +86,7 @@ And in the `Team` class, the `heroes` attribute is annotated as a list of `Hero`
 
 /// tip
 
-There's a couple of things we'll check again in some of the next chapters, about the `List["Hero"]` and the `back_populates`.
+There's a couple of things we'll check again in some of the next chapters, about the `list["Hero"]` and the `back_populates`.
 
 But for now, let's first see how to use these relationship attributes.
 

docs/tutorial/relationship-attributes/type-annotation-strings.md

@@ -1,10 +1,10 @@
-## About the String in `List["Hero"]`
+## About the String in `list["Hero"]`
 
-In the first Relationship attribute, we declare it with `List["Hero"]`, putting the `Hero` in quotes instead of just normally there:
+In the first Relationship attribute, we declare it with `list["Hero"]`, putting the `Hero` in quotes instead of just normally there:
 
 {* ./docs_src/tutorial/relationship_attributes/define_relationship_attributes/tutorial001_py310.py ln[1:19] hl[9] *}
 
-What's that about? Can't we just write it normally as `List[Hero]`?
+What's that about? Can't we just write it normally as `list[Hero]`?
 
 By that point, in that line in the code, the Python interpreter **doesn't know of any class `Hero`**, and if we put it just there, it would try to find it unsuccessfully, and then fail. 😭
 

docs/tutorial/code-structure.md

@@ -183,7 +183,7 @@ And this ends up *requiring* the same **circular imports** that are not supporte
 
 But these **type annotations** we want to declare are not needed at *runtime*.
 
-In fact, remember that we used `List["Hero"]`, with a `"Hero"` in a string?
+In fact, remember that we used `list["Hero"]`, with a `"Hero"` in a string?
 
 For Python, at runtime, that is **just a string**.
 

docs/tutorial/fastapi/response-model.md

@@ -38,7 +38,7 @@ For example, we can pass the same `Hero` **SQLModel** class (because it is also
 
 We can also use other type annotations, the same way we can use with Pydantic fields. For example, we can pass a list of `Hero`s.
 
-First, we import `List` from `typing` and then we declare the `response_model` with `List[Hero]`:
+To do so, we declare the `response_model` with `list[Hero]`:
 
 {* ./docs_src/tutorial/fastapi/response_model/tutorial001_py310.py ln[40:44] hl[40] *}
 

docs/tutorial/many-to-many/create-models-with-link.md

@@ -28,7 +28,7 @@ Let's see the `Team` model, it's almost identical as before, but with a little c
 
 {* ./docs_src/tutorial/many_to_many/tutorial001_py310.py ln[9:14] hl[14] *}
 
-The **relationship attribute `heroes`** is still a list of heroes, annotated as `List["Hero"]`. Again, we use `"Hero"` in quotes because we haven't declared that class yet by this point in the code (but as you know, editors and **SQLModel** understand that).
+The **relationship attribute `heroes`** is still a list of heroes, annotated as `list["Hero"]`. Again, we use `"Hero"` in quotes because we haven't declared that class yet by this point in the code (but as you know, editors and **SQLModel** understand that).
 
 We use the same **`Relationship()`** function.
 
@@ -46,7 +46,7 @@ We **removed** the previous `team_id` field (column) because now the relationshi
 
 The relationship attribute is now named **`teams`** instead of `team`, as now we support multiple teams.
 
-It is no longer an `Optional[Team]` but a list of teams, annotated as **`List[Team]`**.
+It is no longer an `Optional[Team]` but a list of teams, annotated as **`list[Team]`**.
 
 We are using the **`Relationship()`** here too.
 

docs/tutorial/relationship-attributes/define-relationships-attributes.md

@@ -86,7 +86,7 @@ And in the `Team` class, the `heroes` attribute is annotated as a list of `Hero`
 
 /// tip
 
-There's a couple of things we'll check again in some of the next chapters, about the `List["Hero"]` and the `back_populates`.
+There's a couple of things we'll check again in some of the next chapters, about the `list["Hero"]` and the `back_populates`.
 
 But for now, let's first see how to use these relationship attributes.
 

docs/tutorial/relationship-attributes/type-annotation-strings.md

@@ -1,10 +1,10 @@
-## About the String in `List["Hero"]`
+## About the String in `list["Hero"]`
 
-In the first Relationship attribute, we declare it with `List["Hero"]`, putting the `Hero` in quotes instead of just normally there:
+In the first Relationship attribute, we declare it with `list["Hero"]`, putting the `Hero` in quotes instead of just normally there:
 
 {* ./docs_src/tutorial/relationship_attributes/define_relationship_attributes/tutorial001_py310.py ln[1:19] hl[9] *}
 
-What's that about? Can't we just write it normally as `List[Hero]`?
+What's that about? Can't we just write it normally as `list[Hero]`?
 
 By that point, in that line in the code, the Python interpreter **doesn't know of any class `Hero`**, and if we put it just there, it would try to find it unsuccessfully, and then fail. 😭