Experimentele functies¶

In deze sectie vindt u documentatie voor nieuwe, experimentele functies in Pydantic. Deze functies kunnen worden gewijzigd of verwijderd en we zijn op zoek naar feedback en suggesties voordat we ze een permanent onderdeel van Pydantic maken.

Zie ons versiebeleid voor meer informatie over experimentele functies.

Feedback¶

We verwelkomen feedback over experimentele functies! Open een issue in de Pydantic GitHub-repository om uw gedachten, verzoeken of suggesties te delen.

We moedigen u ook aan om bestaande feedback door te lezen en uw mening toe te voegen aan bestaande problemen.

Waarschuwingen bij importeren¶

Wanneer u een experimentele functie uit de experimental module importeert, ziet u een waarschuwingsbericht dat de functie experimenteel is. U kunt deze waarschuwing als volgt uitschakelen:

import warnings

from pydantic import PydanticExperimentalWarning

warnings.filterwarnings('ignore', category=PydanticExperimentalWarning)

Pijplijn-API¶

Pydantic v2.8.0 introduceerde een experimentele "pipeline" API waarmee parsing (validatie), beperkingen en transformaties op een meer typeveilige manier kunnen worden samengesteld dan bestaande API's. Deze API kan worden gewijzigd of verwijderd. We zijn op zoek naar feedback en suggesties voordat we deze een permanent onderdeel van Pydantic maken.

??? api "API-documentatie" [pydantic.experimental.pipeline][pydantic.experimentele.pipeline]

Over het algemeen wordt de pijplijn-API gebruikt om een reeks stappen te definiëren die tijdens validatie op binnenkomende gegevens moeten worden toegepast. De pijplijn-API is ontworpen om typeveiliger en configureerbaarder te zijn dan de bestaande Pydantic API.

Elke stap in de pijplijn kan zijn:

Een validatiestap die pydantische validatie uitvoert op het opgegeven type
Een transformatiestap die de gegevens wijzigt
Een beperkingsstap waarmee de gegevens worden gecontroleerd op basis van een voorwaarde
Een predikaatstap die de gegevens aan de hand van een voorwaarde controleert en een fout genereert als deze False retourneert

Houd er rekening mee dat het volgende voorbeeld uitputtend probeert te zijn, ten koste van de complexiteit: als u merkt dat u zoveel transformaties in type-annotaties schrijft, kunt u overwegen een UserIn en UserOut model te gebruiken (voorbeeld hieronder) of iets dergelijks waarbij u de transformaties via idomatic maakt gewone Python-code. Deze API's zijn bedoeld voor situaties waarin de codebesparingen aanzienlijk zijn en de toegevoegde complexiteit relatief klein is.

from __future__ import annotations

from datetime import datetime

from typing_extensions import Annotated

from pydantic import BaseModel
from pydantic.experimental.pipeline import validate_as, validate_as_deferred


class User(BaseModel):
    name: Annotated[str, validate_as(str).str_lower()]  # (1)!
    age: Annotated[int, validate_as(int).gt(0)]  # (2)!
    username: Annotated[str, validate_as(str).str_pattern(r'[a-z]+')]  # (3)!
    password: Annotated[
        str,
        validate_as(str)
        .transform(str.lower)
        .predicate(lambda x: x != 'password'),  # (4)!
    ]
    favorite_number: Annotated[  # (5)!
        int,
        (validate_as(int) | validate_as(str).str_strip().validate_as(int)).gt(
            0
        ),
    ]
    friends: Annotated[list[User], validate_as(...).len(0, 100)]  # (6)!
    family: Annotated[  # (7)!
        list[User],
        validate_as_deferred(lambda: list[User]).transform(lambda x: x[1:]),
    ]
    bio: Annotated[
        datetime,
        validate_as(int)
        .transform(lambda x: x / 1_000_000)
        .validate_as(...),  # (8)!
    ]

Een tekenreeks in kleine letters.
Beperk een geheel getal groter dan nul.
Beperk een tekenreeks zodat deze overeenkomt met een regex-patroon.
U kunt ook de transformatie-, constrain- en predikaatmethoden op een lager niveau gebruiken.
Gebruik de | of & -operatoren om stappen te combineren (zoals een logische OR of AND).
validate_as(...) aanroepen met Ellipsis , ... zoals het eerste positionele argument impliceert validate_as(<field type>) . Gebruik validate_as(Any) om elk type te accepteren.
Voor recursieve typen kunt u validate_as_deferred gebruiken om naar het type zelf te verwijzen voordat het wordt gedefinieerd.
U kunt validate_as() voor of na andere stappen aanroepen om voor- of naverwerking uit te voeren.

Toewijzing van `BeforeValidator` , `AfterValidator` en `WrapValidator`¶

De validate_as methode is een meer typeveilige manier om BeforeValidator , AfterValidator en WrapValidator te definiëren:

from typing_extensions import Annotated

from pydantic.experimental.pipeline import transform, validate_as

# BeforeValidator
Annotated[int, validate_as(str).str_strip().validate_as(...)]  # (1)!
# AfterValidator
Annotated[int, transform(lambda x: x * 2)]  # (2)!
# WrapValidator
Annotated[
    int,
    validate_as(str)
    .str_strip()
    .validate_as(...)
    .transform(lambda x: x * 2),  # (3)!
]

Verwijder de witruimte uit een tekenreeks voordat u deze parseert als een geheel getal.
Vermenigvuldig een geheel getal met 2 nadat u het hebt geparseerd.
Verwijder de witruimte uit een tekenreeks, valideer deze als een geheel getal en vermenigvuldig deze vervolgens met 2.

Alternatieve patronen¶

Er zijn veel alternatieve patronen die u kunt gebruiken, afhankelijk van het scenario. Beschouw als voorbeeld het hierboven genoemde UserIn en UserOut patroon:

from __future__ import annotations

from pydantic import BaseModel


class UserIn(BaseModel):
    favorite_number: int | str


class UserOut(BaseModel):
    favorite_number: int


def my_api(user: UserIn) -> UserOut:
    favorite_number = user.favorite_number
    if isinstance(favorite_number, str):
        favorite_number = int(user.favorite_number.strip())

    return UserOut(favorite_number=favorite_number)


assert my_api(UserIn(favorite_number=' 1 ')).favorite_number == 1

Dit voorbeeld maakt gebruik van eenvoudige, idiomatische Python-code die wellicht gemakkelijker te begrijpen is, typecontroles uitvoert, enz. dan de bovenstaande voorbeelden. De aanpak die u kiest, moet echt afhangen van uw gebruiksscenario. U zult de breedsprakigheid, prestaties, het gemak waarmee betekenisvolle fouten naar uw gebruikers kunnen worden geretourneerd, enz. moeten vergelijken om het juiste patroon te kiezen. Houd er rekening mee dat u geen misbruik maakt van geavanceerde patronen, zoals de pijplijn-API, alleen maar omdat het kan.

本文总阅读量次