github-actions[bot]
3 weeks ago
42 changed files with 243 additions and 227 deletions
@ -4,9 +4,9 @@ En poursuivant l'exemple précédent, il est courant d'avoir plusieurs modèles |
|||||
|
|
||||
C'est particulièrement vrai pour les modèles d'utilisateur, car : |
C'est particulièrement vrai pour les modèles d'utilisateur, car : |
||||
|
|
||||
* Le modèle d'entrée doit pouvoir contenir un mot de passe. |
* Le **modèle d'entrée** doit pouvoir contenir un mot de passe. |
||||
* Le modèle de sortie ne doit pas avoir de mot de passe. |
* Le **modèle de sortie** ne doit pas avoir de mot de passe. |
||||
* Le modèle de base de données devra probablement avoir un mot de passe haché. |
* Le **modèle de base de données** aurait probablement besoin d'avoir un mot de passe haché. |
||||
|
|
||||
/// danger | Danger |
/// danger | Danger |
||||
|
|
||||
@ -30,13 +30,13 @@ Voici une idée générale de l'apparence des modèles avec leurs champs de mot |
|||||
|
|
||||
Les modèles Pydantic ont une méthode `.model_dump()` qui renvoie un `dict` avec les données du modèle. |
Les modèles Pydantic ont une méthode `.model_dump()` qui renvoie un `dict` avec les données du modèle. |
||||
|
|
||||
Ainsi, si nous créons un objet Pydantic `user_in` comme : |
Ainsi, si nous créons un objet Pydantic `user_in` comme : |
||||
|
|
||||
```Python |
```Python |
||||
user_in = UserIn(username="john", password="secret", email="[email protected]") |
user_in = UserIn(username="john", password="secret", email="[email protected]") |
||||
``` |
``` |
||||
|
|
||||
et que nous appelons ensuite : |
et que nous appelons ensuite : |
||||
|
|
||||
```Python |
```Python |
||||
user_dict = user_in.model_dump() |
user_dict = user_in.model_dump() |
||||
@ -44,13 +44,13 @@ user_dict = user_in.model_dump() |
|||||
|
|
||||
nous avons maintenant un `dict` avec les données dans la variable `user_dict` (c'est un `dict` au lieu d'un objet modèle Pydantic). |
nous avons maintenant un `dict` avec les données dans la variable `user_dict` (c'est un `dict` au lieu d'un objet modèle Pydantic). |
||||
|
|
||||
Et si nous appelons : |
Et si nous appelons : |
||||
|
|
||||
```Python |
```Python |
||||
print(user_dict) |
print(user_dict) |
||||
``` |
``` |
||||
|
|
||||
nous obtiendrions un `dict` Python contenant : |
nous obtiendrions un `dict` Python contenant : |
||||
|
|
||||
```Python |
```Python |
||||
{ |
{ |
||||
@ -63,15 +63,15 @@ nous obtiendrions un `dict` Python contenant : |
|||||
|
|
||||
#### Déballer un `dict` { #unpacking-a-dict } |
#### Déballer un `dict` { #unpacking-a-dict } |
||||
|
|
||||
Si nous prenons un `dict` comme `user_dict` et que nous le passons à une fonction (ou une classe) avec `**user_dict`, Python va « déballer » ce `dict`. Il passera les clés et valeurs de `user_dict` directement comme arguments nommés. |
Si nous prenons un `dict` comme `user_dict` et que nous le passons à une fonction (ou une classe) avec `**user_dict`, Python va « déballer » ce `dict`. Il passera les clés et valeurs de `user_dict` directement comme arguments clé-valeur. |
||||
|
|
||||
Ainsi, en reprenant `user_dict` ci-dessus, écrire : |
Ainsi, en reprenant `user_dict` ci-dessus, écrire : |
||||
|
|
||||
```Python |
```Python |
||||
UserInDB(**user_dict) |
UserInDB(**user_dict) |
||||
``` |
``` |
||||
|
|
||||
aurait pour résultat quelque chose d'équivalent à : |
aurait pour résultat quelque chose d'équivalent à : |
||||
|
|
||||
```Python |
```Python |
||||
UserInDB( |
UserInDB( |
||||
@ -82,7 +82,7 @@ UserInDB( |
|||||
) |
) |
||||
``` |
``` |
||||
|
|
||||
Ou plus exactement, en utilisant `user_dict` directement, quels que soient ses contenus futurs : |
Ou plus exactement, en utilisant `user_dict` directement, quels que soient ses contenus futurs : |
||||
|
|
||||
```Python |
```Python |
||||
UserInDB( |
UserInDB( |
||||
@ -95,14 +95,14 @@ UserInDB( |
|||||
|
|
||||
#### Créer un modèle Pydantic à partir du contenu d'un autre { #a-pydantic-model-from-the-contents-of-another } |
#### Créer un modèle Pydantic à partir du contenu d'un autre { #a-pydantic-model-from-the-contents-of-another } |
||||
|
|
||||
Comme dans l'exemple ci-dessus nous avons obtenu `user_dict` depuis `user_in.model_dump()`, ce code : |
Comme dans l'exemple ci-dessus nous avons obtenu `user_dict` depuis `user_in.model_dump()`, ce code : |
||||
|
|
||||
```Python |
```Python |
||||
user_dict = user_in.model_dump() |
user_dict = user_in.model_dump() |
||||
UserInDB(**user_dict) |
UserInDB(**user_dict) |
||||
``` |
``` |
||||
|
|
||||
serait équivalent à : |
serait équivalent à : |
||||
|
|
||||
```Python |
```Python |
||||
UserInDB(**user_in.model_dump()) |
UserInDB(**user_in.model_dump()) |
||||
@ -114,13 +114,13 @@ Ainsi, nous obtenons un modèle Pydantic à partir des données d'un autre modè |
|||||
|
|
||||
#### Déballer un `dict` et ajouter des mots-clés supplémentaires { #unpacking-a-dict-and-extra-keywords } |
#### Déballer un `dict` et ajouter des mots-clés supplémentaires { #unpacking-a-dict-and-extra-keywords } |
||||
|
|
||||
Et en ajoutant ensuite l'argument nommé supplémentaire `hashed_password=hashed_password`, comme ici : |
Et en ajoutant ensuite l'argument nommé supplémentaire `hashed_password=hashed_password`, comme ici : |
||||
|
|
||||
```Python |
```Python |
||||
UserInDB(**user_in.model_dump(), hashed_password=hashed_password) |
UserInDB(**user_in.model_dump(), hashed_password=hashed_password) |
||||
``` |
``` |
||||
|
|
||||
... revient à : |
... revient à : |
||||
|
|
||||
```Python |
```Python |
||||
UserInDB( |
UserInDB( |
||||
@ -152,7 +152,7 @@ Nous pouvons déclarer un modèle `UserBase` qui sert de base à nos autres mod |
|||||
|
|
||||
Toutes les conversions de données, validations, documentation, etc., fonctionneront comme d'habitude. |
Toutes les conversions de données, validations, documentation, etc., fonctionneront comme d'habitude. |
||||
|
|
||||
De cette façon, nous pouvons ne déclarer que les différences entre les modèles (avec `password` en clair, avec `hashed_password` et sans mot de passe) : |
De cette façon, nous pouvons ne déclarer que les différences entre les modèles (avec `password` en clair, avec `hashed_password` et sans mot de passe) : |
||||
|
|
||||
{* ../../docs_src/extra_models/tutorial002_py310.py hl[7,13:14,17:18,21:22] *} |
{* ../../docs_src/extra_models/tutorial002_py310.py hl[7,13:14,17:18,21:22] *} |
||||
|
|
||||
@ -162,7 +162,7 @@ Vous pouvez déclarer qu'une réponse est l'`Union` de deux types ou plus, ce qu |
|||||
|
|
||||
Cela sera défini dans OpenAPI avec `anyOf`. |
Cela sera défini dans OpenAPI avec `anyOf`. |
||||
|
|
||||
Pour ce faire, utilisez l'annotation de type Python standard [`typing.Union`](https://docs.python.org/3/library/typing.html#typing.Union) : |
Pour ce faire, utilisez l'annotation de type Python standard [`typing.Union`](https://docs.python.org/3/library/typing.html#typing.Union) : |
||||
|
|
||||
/// note | Remarque |
/// note | Remarque |
||||
|
|
||||
@ -176,21 +176,21 @@ Lors de la définition d'une [`Union`](https://docs.pydantic.dev/latest/concepts |
|||||
|
|
||||
Dans cet exemple, nous passons `Union[PlaneItem, CarItem]` comme valeur de l'argument `response_model`. |
Dans cet exemple, nous passons `Union[PlaneItem, CarItem]` comme valeur de l'argument `response_model`. |
||||
|
|
||||
Comme nous le passons comme valeur d'un argument au lieu de l'utiliser dans une annotation de type, nous devons utiliser `Union` même en Python 3.10. |
Comme nous le passons comme **valeur à un argument** au lieu de l'utiliser dans une **annotation de type**, nous devons utiliser `Union` même en Python 3.10. |
||||
|
|
||||
S'il s'agissait d'une annotation de type, nous pourrions utiliser la barre verticale, comme : |
S'il s'agissait d'une annotation de type, nous pourrions utiliser la barre verticale, comme : |
||||
|
|
||||
```Python |
```Python |
||||
some_variable: PlaneItem | CarItem |
some_variable: PlaneItem | CarItem |
||||
``` |
``` |
||||
|
|
||||
Mais si nous écrivons cela dans l'affectation `response_model=PlaneItem | CarItem`, nous obtiendrons une erreur, car Python essaierait d'effectuer une « opération invalide » entre `PlaneItem` et `CarItem` au lieu de l'interpréter comme une annotation de type. |
Mais si nous écrivons cela dans l'affectation `response_model=PlaneItem | CarItem`, nous obtiendrons une erreur, car Python essaierait d'effectuer une **opération invalide** entre `PlaneItem` et `CarItem` au lieu de l'interpréter comme une annotation de type. |
||||
|
|
||||
## Liste de modèles { #list-of-models } |
## Liste de modèles { #list-of-models } |
||||
|
|
||||
De la même manière, vous pouvez déclarer des réponses contenant des listes d'objets. |
De la même manière, vous pouvez déclarer des réponses contenant des listes d'objets. |
||||
|
|
||||
Pour cela, utilisez le `list` Python standard : |
Pour cela, utilisez le `list` Python standard : |
||||
|
|
||||
{* ../../docs_src/extra_models/tutorial004_py310.py hl[18] *} |
{* ../../docs_src/extra_models/tutorial004_py310.py hl[18] *} |
||||
|
|
||||
@ -200,7 +200,7 @@ Vous pouvez également déclarer une réponse en utilisant un simple `dict` arbi |
|||||
|
|
||||
C'est utile si vous ne connaissez pas à l'avance les noms de champs/attributs valides (qui seraient nécessaires pour un modèle Pydantic). |
C'est utile si vous ne connaissez pas à l'avance les noms de champs/attributs valides (qui seraient nécessaires pour un modèle Pydantic). |
||||
|
|
||||
Dans ce cas, vous pouvez utiliser `dict` : |
Dans ce cas, vous pouvez utiliser `dict` : |
||||
|
|
||||
{* ../../docs_src/extra_models/tutorial005_py310.py hl[6] *} |
{* ../../docs_src/extra_models/tutorial005_py310.py hl[6] *} |
||||
|
|
||||
@ -208,4 +208,4 @@ Dans ce cas, vous pouvez utiliser `dict` : |
|||||
|
|
||||
Utilisez plusieurs modèles Pydantic et héritez librement selon chaque cas. |
Utilisez plusieurs modèles Pydantic et héritez librement selon chaque cas. |
||||
|
|
||||
Vous n'avez pas besoin d'avoir un seul modèle de données par entité si cette entité doit pouvoir avoir différents « états ». Comme pour l'« entité » utilisateur, avec un état incluant `password`, `password_hash` et sans mot de passe. |
Vous n'avez pas besoin d'avoir un seul modèle de données par entité si cette entité doit pouvoir avoir différents « états ». L'« entité » **utilisateur** est un exemple, avec des états qui incluent `password`, `password_hash`, ou aucun mot de passe. |
||||
|
|||||
Loading…
Reference in new issue