📝 Update docs mentioning Pydantic v1

docs/en/docs/advanced/path-operation-advanced-configuration.md

@@ -153,48 +153,16 @@ And you could do this even if the data type in the request is not JSON.
 
 For example, in this application we don't use FastAPI's integrated functionality to extract the JSON Schema from Pydantic models nor the automatic validation for JSON. In fact, we are declaring the request content type as YAML, not JSON:
 
-//// tab | Pydantic v2
-
 {* ../../docs_src/path_operation_advanced_configuration/tutorial007_py39.py hl[15:20, 22] *}
 
-////
-
-//// tab | Pydantic v1
-
-{* ../../docs_src/path_operation_advanced_configuration/tutorial007_pv1_py39.py hl[15:20, 22] *}
-
-////
-
-/// info
-
-In Pydantic version 1 the method to get the JSON Schema for a model was called `Item.schema()`, in Pydantic version 2, the method is called `Item.model_json_schema()`.
-
-///
-
 Nevertheless, although we are not using the default integrated functionality, we are still using a Pydantic model to manually generate the JSON Schema for the data that we want to receive in YAML.
 
 Then we use the request directly, and extract the body as `bytes`. This means that FastAPI won't even try to parse the request payload as JSON.
 
 And then in our code, we parse that YAML content directly, and then we are again using the same Pydantic model to validate the YAML content:
 
-//// tab | Pydantic v2
-
 {* ../../docs_src/path_operation_advanced_configuration/tutorial007_py39.py hl[24:31] *}
 
-////
-
-//// tab | Pydantic v1
-
-{* ../../docs_src/path_operation_advanced_configuration/tutorial007_pv1_py39.py hl[24:31] *}
-
-////
-
-/// info
-
-In Pydantic version 1 the method to parse and validate an object was `Item.parse_obj()`, in Pydantic version 2, the method is called `Item.model_validate()`.
-
-///
-
 /// tip
 
 Here we reuse the same Pydantic model.

docs/en/docs/advanced/settings.md

@@ -46,12 +46,6 @@ $ pip install "fastapi[all]"
 
 </div>
 
-/// info
-
-In Pydantic v1 it came included with the main package. Now it is distributed as this independent package so that you can choose to install it or not if you don't need that functionality.
-
-///
-
 ### Create the `Settings` object { #create-the-settings-object }
 
 Import `BaseSettings` from Pydantic and create a sub-class, very much like with a Pydantic model.
@@ -60,24 +54,8 @@ The same way as with Pydantic models, you declare class attributes with type ann
 
 You can use all the same validation features and tools you use for Pydantic models, like different data types and additional validations with `Field()`.
 
-//// tab | Pydantic v2
-
 {* ../../docs_src/settings/tutorial001_py39.py hl[2,5:8,11] *}
 
-////
-
-//// tab | Pydantic v1
-
-/// info
-
-In Pydantic v1 you would import `BaseSettings` directly from `pydantic` instead of from `pydantic_settings`.
-
-///
-
-{* ../../docs_src/settings/tutorial001_pv1_py39.py hl[2,5:8,11] *}
-
-////
-
 /// tip
 
 If you want something quick to copy and paste, don't use this example, use the last one below.
@@ -215,8 +193,6 @@ APP_NAME="ChimichangApp"
 
 And then update your `config.py` with:
 
-//// tab | Pydantic v2
-
 {* ../../docs_src/settings/app03_an_py39/config.py hl[9] *}
 
 /// tip
@@ -225,26 +201,6 @@ The `model_config` attribute is used just for Pydantic configuration. You can re
 
 ///
 
-////
-
-//// tab | Pydantic v1
-
-{* ../../docs_src/settings/app03_an_py39/config_pv1.py hl[9:10] *}
-
-/// tip
-
-The `Config` class is used just for Pydantic configuration. You can read more at <a href="https://docs.pydantic.dev/1.10/usage/model_config/" class="external-link" target="_blank">Pydantic Model Config</a>.
-
-///
-
-////
-
-/// info
-
-In Pydantic version 1 the configuration was done in an internal class `Config`, in Pydantic version 2 it's done in an attribute `model_config`. This attribute takes a `dict`, and to get autocompletion and inline errors you can import and use `SettingsConfigDict` to define that `dict`.
-
-///
-
 Here we define the config `env_file` inside of your Pydantic `Settings` class, and set the value to the filename with the dotenv file we want to use.
 
 ### Creating the `Settings` only once with `lru_cache` { #creating-the-settings-only-once-with-lru-cache }

docs/en/docs/how-to/migrate-from-pydantic-v1-to-pydantic-v2.md

@@ -2,21 +2,23 @@
 
 If you have an old FastAPI app, you might be using Pydantic version 1.
 
-FastAPI has had support for either Pydantic v1 or v2 since version 0.100.0.
+FastAPI version 0.100.0 had support for either Pydantic v1 or v2. It would use whichever you had installed.
 
-If you had installed Pydantic v2, it would use it. If instead you had Pydantic v1, it would use that.
+FastAPI version 0.119.0 introduced partial support for Pydantic v1 from inside of Pydantic v2 (as `pydantic.v1`), to facilitate the migration to v2.
 
-Pydantic v1 is now deprecated and support for it will be removed in the next versions of FastAPI, you should **migrate to Pydantic v2**. This way you will get the latest features, improvements, and fixes.
+FastAPI 0.126.0 dropped support for Pydantic v1, while still supporting `pydantic.v1` for a little while.
 
 /// warning
 
-Also, the Pydantic team stopped support for Pydantic v1 for the latest versions of Python, starting with **Python 3.14**.
+The Pydantic team stopped support for Pydantic v1 for the latest versions of Python, starting with **Python 3.14**.
+
+This includes `pydantic.v1`, which is no longer supported in Python 3.14 and above.
 
 If you want to use the latest features of Python, you will need to make sure you use Pydantic v2.
 
 ///
 
-If you have an old FastAPI app with Pydantic v1, here I'll show you how to migrate it to Pydantic v2, and the **new features in FastAPI 0.119.0** to help you with a gradual migration.
+If you have an old FastAPI app with Pydantic v1, here I'll show you how to migrate it to Pydantic v2, and the **features in FastAPI 0.119.0** to help you with a gradual migration.
 
 ## Official Guide { #official-guide }
 
@@ -44,7 +46,7 @@ After this, you can run the tests and check if everything works. If it does, you
 
 ## Pydantic v1 in v2 { #pydantic-v1-in-v2 }
 
-Pydantic v2 includes everything from Pydantic v1 as a submodule `pydantic.v1`.
+Pydantic v2 includes everything from Pydantic v1 as a submodule `pydantic.v1`. But this is no longer supported in versions above Python 3.13.
 
 This means that you can install the latest version of Pydantic v2 and import and use the old Pydantic v1 components from this submodule, as if you had the old Pydantic v1 installed.
 

docs/en/docs/tutorial/body-updates.md

@@ -50,14 +50,6 @@ If you want to receive partial updates, it's very useful to use the parameter `e
 
 Like `item.model_dump(exclude_unset=True)`.
 
-/// info
-
-In Pydantic v1 the method was called `.dict()`, it was deprecated (but still supported) in Pydantic v2, and renamed to `.model_dump()`.
-
-The examples here use `.dict()` for compatibility with Pydantic v1, but you should use `.model_dump()` instead if you can use Pydantic v2.
-
-///
-
 That would generate a `dict` with only the data that was set when creating the `item` model, excluding default values.
 
 Then you can use this to generate a `dict` with only the data that was set (sent in the request), omitting default values:
@@ -68,14 +60,6 @@ Then you can use this to generate a `dict` with only the data that was set (sent
 
 Now, you can create a copy of the existing model using `.model_copy()`, and pass the `update` parameter with a `dict` containing the data to update.
 
-/// info
-
-In Pydantic v1 the method was called `.copy()`, it was deprecated (but still supported) in Pydantic v2, and renamed to `.model_copy()`.
-
-The examples here use `.copy()` for compatibility with Pydantic v1, but you should use `.model_copy()` instead if you can use Pydantic v2.
-
-///
-
 Like `stored_item_model.model_copy(update=update_data)`:
 
 {* ../../docs_src/body_updates/tutorial002_py310.py hl[33] *}

docs/en/docs/tutorial/body.md

@@ -128,14 +128,6 @@ Inside of the function, you can access all the attributes of the model object di
 
 {* ../../docs_src/body/tutorial002_py310.py *}
 
-/// info
-
-In Pydantic v1 the method was called `.dict()`, it was deprecated (but still supported) in Pydantic v2, and renamed to `.model_dump()`.
-
-The examples here use `.dict()` for compatibility with Pydantic v1, but you should use `.model_dump()` instead if you can use Pydantic v2.
-
-///
-
 ## Request body + path parameters { #request-body-path-parameters }
 
 You can declare path parameters and request body at the same time.

docs/en/docs/tutorial/extra-models.md

@@ -22,22 +22,13 @@ Here's a general idea of how the models could look like with their password fiel
 
 {* ../../docs_src/extra_models/tutorial001_py310.py hl[7,9,14,20,22,27:28,31:33,38:39] *}
 
+### About `**user_in.model_dump()` { #about-user-in-dict }
 
-/// info
+#### Pydantic's `.model_dump()` { #pydantics-dict }
-
-In Pydantic v1 the method was called `.dict()`, it was deprecated (but still supported) in Pydantic v2, and renamed to `.model_dump()`.
-
-The examples here use `.dict()` for compatibility with Pydantic v1, but you should use `.model_dump()` instead if you can use Pydantic v2.
-
-///
-
-### About `**user_in.dict()` { #about-user-in-dict }
-
-#### Pydantic's `.dict()` { #pydantics-dict }
 
 `user_in` is a Pydantic model of class `UserIn`.
 
-Pydantic models have a `.dict()` method that returns a `dict` with the model's data.
+Pydantic models have a `.model_dump()` method that returns a `dict` with the model's data.
 
 So, if we create a Pydantic object `user_in` like:
 
@@ -48,7 +39,7 @@ user_in = UserIn(username="john", password="secret", email="[email protected]
 and then we call:
 
 ```Python
-user_dict = user_in.dict()
+user_dict = user_in.model_dump()
 ```
 
 we now have a `dict` with the data in the variable `user_dict` (it's a `dict` instead of a Pydantic model object).
@@ -104,20 +95,20 @@ UserInDB(
 
 #### A Pydantic model from the contents of another { #a-pydantic-model-from-the-contents-of-another }
 
-As in the example above we got `user_dict` from `user_in.dict()`, this code:
+As in the example above we got `user_dict` from `user_in.model_dump()`, this code:
 
 ```Python
-user_dict = user_in.dict()
+user_dict = user_in.model_dump()
 UserInDB(**user_dict)
 ```
 
 would be equivalent to:
 
 ```Python
-UserInDB(**user_in.dict())
+UserInDB(**user_in.model_dump())
 ```
 
-...because `user_in.dict()` is a `dict`, and then we make Python "unpack" it by passing it to `UserInDB` prefixed with `**`.
+...because `user_in.model_dump()` is a `dict`, and then we make Python "unpack" it by passing it to `UserInDB` prefixed with `**`.
 
 So, we get a Pydantic model from the data in another Pydantic model.
 
@@ -126,7 +117,7 @@ So, we get a Pydantic model from the data in another Pydantic model.
 And then adding the extra keyword argument `hashed_password=hashed_password`, like in:
 
 ```Python
-UserInDB(**user_in.dict(), hashed_password=hashed_password)
+UserInDB(**user_in.model_dump(), hashed_password=hashed_password)
 ```
 
 ...ends up being like:
@@ -181,7 +172,6 @@ When defining a <a href="https://docs.pydantic.dev/latest/concepts/types/#unions
 
 {* ../../docs_src/extra_models/tutorial003_py310.py hl[1,14:15,18:20,33] *}
 
-
 ### `Union` in Python 3.10 { #union-in-python-3-10 }
 
 In this example we pass `Union[PlaneItem, CarItem]` as the value of the argument `response_model`.
@@ -204,7 +194,6 @@ For that, use the standard Python `typing.List` (or just `list` in Python 3.9 an
 
 {* ../../docs_src/extra_models/tutorial004_py39.py hl[18] *}
 
-
 ## Response with arbitrary `dict` { #response-with-arbitrary-dict }
 
 You can also declare a response using a plain arbitrary `dict`, declaring just the type of the keys and values, without using a Pydantic model.
@@ -215,7 +204,6 @@ In this case, you can use `typing.Dict` (or just `dict` in Python 3.9 and above)
 
 {* ../../docs_src/extra_models/tutorial005_py39.py hl[6] *}
 
-
 ## Recap { #recap }
 
 Use multiple Pydantic models and inherit freely for each case.

docs/en/docs/tutorial/query-params-str-validations.md

@@ -206,20 +206,6 @@ If you feel lost with all these **"regular expression"** ideas, don't worry. The
 
 Now you know that whenever you need them you can use them in **FastAPI**.
 
-### Pydantic v1 `regex` instead of `pattern` { #pydantic-v1-regex-instead-of-pattern }
-
-Before Pydantic version 2 and before FastAPI 0.100.0, the parameter was called `regex` instead of `pattern`, but it's now deprecated.
-
-You could still see some code using it:
-
-//// tab | Pydantic v1
-
-{* ../../docs_src/query_params_str_validations/tutorial004_regex_an_py310.py hl[11] *}
-
-////
-
-But know that this is deprecated and it should be updated to use the new parameter `pattern`. 🤓
-
 ## Default values { #default-values }
 
 You can, of course, use default values other than `None`.

docs/en/docs/tutorial/response-model.md

@@ -252,20 +252,6 @@ So, if you send a request to that *path operation* for the item with ID `foo`, t
 
 /// info
 
-In Pydantic v1 the method was called `.dict()`, it was deprecated (but still supported) in Pydantic v2, and renamed to `.model_dump()`.
-
-The examples here use `.dict()` for compatibility with Pydantic v1, but you should use `.model_dump()` instead if you can use Pydantic v2.
-
-///
-
-/// info
-
-FastAPI uses Pydantic model's `.dict()` with <a href="https://docs.pydantic.dev/1.10/usage/exporting_models/#modeldict" class="external-link" target="_blank">its `exclude_unset` parameter</a> to achieve this.
-
-///
-
-/// info
-
 You can also use:
 
 * `response_model_exclude_defaults=True`