Drop support for Python 3.8 in CI and docs (#1695)

Co-authored-by: Yurii Motov <yurii.motov.monte@gmail.com>
Co-authored-by: Motov Yurii <109919500+YuriiMotov@users.noreply.github.com>
This commit is contained in:
Sebastián Ramírez
2025-12-26 03:03:06 -08:00
committed by GitHub
parent d7b596b1dd
commit afc0c324cf
207 changed files with 186 additions and 3738 deletions

View File

@@ -67,9 +67,7 @@ We can use these relative imports because, for example, in the file `app.py` (th
You could put all the database Models in a single Python module (a single Python file), for example `models.py`:
```Python
{!./docs_src/tutorial/code_structure/tutorial001/models.py!}
```
{* ./docs_src/tutorial/code_structure/tutorial001_py310/models.py *}
This way, you wouldn't have to deal with circular imports for other models.
@@ -79,9 +77,7 @@ And then you could import the models from this file/module in any other file/mod
Then you could put the code creating the **engine** and the function to create all the tables (if you are not using migrations) in another file `database.py`:
```Python
{!./docs_src/tutorial/code_structure/tutorial001/database.py!}
```
{* ./docs_src/tutorial/code_structure/tutorial001_py310/database.py *}
This file would also be imported by your application code, to use the shared **engine** and to get and call the function `create_db_and_tables()`.
@@ -89,9 +85,7 @@ This file would also be imported by your application code, to use the shared **e
Finally, you could put the code to create the **app** in another file `app.py`:
```Python hl_lines="3-4"
{!./docs_src/tutorial/code_structure/tutorial001/app.py!}
```
{* ./docs_src/tutorial/code_structure/tutorial001_py310/app.py hl[3:4] *}
Here we import the models, the engine, and the function to create all the tables and then we can use them all internally.
@@ -207,9 +201,7 @@ So, we can use it in an `if` block and import things inside the `if` block. And
Using that trick of `TYPE_CHECKING` we can "import" the `Team` in `hero_model.py`:
```Python hl_lines="1 5-6 16"
{!./docs_src/tutorial/code_structure/tutorial002/hero_model.py!}
```
{* ./docs_src/tutorial/code_structure/tutorial002_py310/hero_model.py hl[1,5:6,16] *}
Have in mind that now we *have* to put the annotation of `Team` as a string: `"Team"`, so that Python doesn't have errors at runtime.
@@ -217,9 +209,7 @@ Have in mind that now we *have* to put the annotation of `Team` as a string: `"T
We use the same trick in the `team_model.py` file:
```Python hl_lines="1 5-6 14"
{!./docs_src/tutorial/code_structure/tutorial002/team_model.py!}
```
{* ./docs_src/tutorial/code_structure/tutorial002_py310/team_model.py hl[1,5:6,14] *}
Now we get editor support, autocompletion, inline errors, and **SQLModel** keeps working. 🎉
@@ -227,9 +217,7 @@ Now we get editor support, autocompletion, inline errors, and **SQLModel** keeps
Now, just for completeness, the `app.py` file would import the models from both modules:
```Python hl_lines="4-5 10 12-14"
{!./docs_src/tutorial/code_structure/tutorial002/app.py!}
```
{* ./docs_src/tutorial/code_structure/tutorial002_py310/app.py hl[4:5,10,12:14] *}
And of course, all the tricks with `TYPE_CHECKING` and type annotations in strings are **only needed in the files with circular imports**.