실험적 기능¶

이 섹션에서는 Pydantic의 새로운 실험적 기능에 대한 문서를 찾을 수 있습니다. 이러한 기능은 변경되거나 제거될 수 있으며, Pydantic의 영구적인 일부로 만들기 전에 피드백과 제안을 찾고 있습니다.

실험적 기능에 대한 자세한 내용은 버전 정책을 참조하세요.

피드백¶

실험적 기능에 대한 피드백을 환영합니다! 귀하의 생각, 요청 또는 제안을 공유하려면 Pydantic GitHub 저장소 에서 이슈를 열어주세요.

또한 기존 피드백을 읽고 기존 문제에 귀하의 생각을 추가하는 것이 좋습니다.

수입에 관한 경고¶

experimental 모듈에서 실험 기능을 가져오면 해당 기능이 실험적이라는 경고 메시지가 표시됩니다. 다음을 사용하여 이 경고를 비활성화할 수 있습니다.

import warnings

from pydantic import PydanticExperimentalWarning

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

파이프라인 API¶

Pydantic v2.8.0은 기존 API보다 유형이 더 안전한 방식으로 구문 분석(검증), 제약 조건 및 변환을 구성할 수 있는 실험적인 "파이프라인" API를 도입했습니다. 이 API는 변경되거나 제거될 수 있습니다. Pydantic의 영구적인 일부로 만들기 전에 피드백과 제안을 찾고 있습니다.

??? api "API 문서" pydantic.experimental.pipeline

일반적으로 파이프라인 API는 검증 중에 들어오는 데이터에 적용할 일련의 단계를 정의하는 데 사용됩니다. 파이프라인 API는 기존 Pydantic API보다 유형이 더 안전하고 구성 가능하도록 설계되었습니다.

파이프라인의 각 단계는 다음과 같습니다.

제공된 유형에 대해 철저한 유효성 검사를 실행하는 유효성 검사 단계
데이터를 수정하는 변환 단계
조건에 따라 데이터를 확인하는 제약 조건 단계
조건에 따라 데이터를 확인하고 False 반환하면 오류를 발생시키는 조건자 단계

다음 예는 복잡성을 희생하면서 철저하게 시도한다는 점에 유의하십시오. 유형 주석에 이렇게 많은 변환을 작성하는 경우 UserIn 및 UserOut 모델(아래 예) 또는 유사한 모델을 사용하여 idomatic을 통해 변환하는 것을 고려할 수 있습니다. 일반 파이썬 코드. 이러한 API는 코드 절감 효과가 상당하고 추가되는 복잡성이 상대적으로 작은 상황을 위한 것입니다.

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)!
    ]

문자열을 소문자로 만듭니다.
정수가 0보다 크도록 제한합니다.
정규식 패턴과 일치하도록 문자열을 제한합니다.
낮은 수준의 변환, 제한 및 조건자 방법을 사용할 수도 있습니다.
| 또는 & 연산자를 사용하여 단계를 결합합니다(예: 논리적 OR 또는 AND).
Ellipsis , ... 사용하여 validate_as(...) 첫 번째 위치 인수로 호출하는 것은 validate_as(<field type>) 의미합니다. 모든 유형을 허용하려면 validate_as(Any) 사용하세요.
재귀 유형의 경우 validate_as_deferred 사용하여 유형이 정의되기 전에 유형 자체를 참조할 수 있습니다.
사전 또는 사후 처리를 수행하기 위해 다른 단계 전후에 validate_as() 호출할 수 있습니다.

`BeforeValidator` , `AfterValidator` 및 `WrapValidator` 에서 매핑¶

validate_as 메소드는 BeforeValidator , AfterValidator 및 WrapValidator 정의하는 보다 유형 안전한 방법입니다.

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)!
]

문자열을 정수로 구문 분석하기 전에 문자열에서 공백을 제거합니다.
구문 분석 후 정수에 2를 곱합니다.
문자열에서 공백을 제거하고 정수로 검증한 다음 2를 곱합니다.

대체 패턴¶

시나리오에 따라 사용할 수 있는 대체 패턴이 많이 있습니다. 예를 들어 위에서 언급한 UserIn 및 UserOut 패턴을 고려해보세요.

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

이 예제에서는 위의 예제보다 이해하기 쉽고 유형 확인 등이 더 쉬울 수 있는 일반 관용적 Python 코드를 사용합니다. 선택하는 접근 방식은 실제로 사용 사례에 따라 달라집니다. 올바른 패턴을 선택하려면 자세한 정도, 성능, 의미 있는 오류를 사용자에게 반환하는 용이성 등을 비교해야 합니다. 파이프라인 API와 같은 고급 패턴을 남용할 수 있다는 이유만으로 주의하세요.

本文总阅读量次