Types de données et paramètres personnalisés
Définissez des types de données Pydantic personnalisés et gérez les paramètres de l’application avec le `BaseSettings` de Pydantic.
Types de données et paramètres personnalisés est une leçon FastAPI Backend Development Bootcamp gratuite sur CoddyKit. Ceci est la leçon 2 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage FastAPI Backend Development Bootcamp, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours FastAPI Backend Development Bootcamp comprend 4 leçons au total.
Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.
Welcome to Custom Types!
Pydantic is great for validating data, but sometimes you need validation beyond its built-in types.
- Custom Data Types let you define your own rules for data.
- This ensures your data adheres to specific formats or business logic.
- Think of it as extending Pydantic's power for unique needs.
`Annotated` for Custom Validation
Pydantic v2 uses Python's typing.Annotated alongside validator functions to create custom types.
Annotated: Adds metadata to a type hint.BeforeValidator: Runs a function before Pydantic's standard validation.- This allows you to transform or validate input data before it's assigned.
Crafting a `CapitalizedString`
Let's create a custom type called CapitalizedString that ensures the first letter of a string is always uppercase.
Our validator function will check this rule. If the string isn't capitalized, it will raise an error.
Using Your Custom Type
Here's how to define and use our new CapitalizedString type in a Pydantic model. Try changing the name to start with a lowercase letter to see the validation error!
from typing import Annotated
from pydantic import BaseModel, BeforeValidator, ValidationError
def validate_capitalized(v: str) -> str:
if not isinstance(v, str):
raise TypeError("String required")
if v and not v[0].isupper():
raise ValueError("Must start with uppercase")
return v
CapitalizedString = Annotated[str, BeforeValidator(validate_capitalized)]
class Product(BaseModel):
name: CapitalizedString
price: float
if __name__ == "__main__":
try:
product1 = Product(name="Laptop", price=1200.50)
print(f"Product: {product1.name}")
# This will raise a ValidationError
# product2 = Product(name="keyboard", price=75.00)
except ValidationError as e:
print(f"Validation Error: {e}")Manage Settings with `BaseSettings`
Application settings (like database URLs, API keys) often change between development and production environments.
BaseSettings, from pydantic-settings, is designed to manage these configurations easily. It automatically loads settings from:
- Environment variables
.envfiles- Default values
Default Settings in Action
Define your settings as attributes in a class inheriting from BaseSettings. Pydantic handles the rest, providing default values if nothing else is specified.
from pydantic_settings import BaseSettings
class AppConfig(BaseSettings):
app_name: str = "My FastAPI App"
debug_mode: bool = False
version: str = "1.0.0"
if __name__ == "__main__":
settings = AppConfig()
print(f"App Name: {settings.app_name}")
print(f"Debug Mode: {settings.debug_mode}")
print(f"Version: {settings.version}")Loading from Environment Variables
BaseSettings automatically looks for environment variables that match your setting names (case-insensitive).
In this example, we temporarily set an environment variable to demonstrate how Pydantic picks it up, overriding the default.
import os
from pydantic_settings import BaseSettings
class AppConfig(BaseSettings):
app_name: str = "Default App"
database_url: str = "sqlite:///./test.db"
if __name__ == "__main__":
print("--- Without env var ---")
settings_default = AppConfig()
print(f"App Name: {settings_default.app_name}")
# Simulate setting an environment variable
os.environ["APP_NAME"] = "Production App"
os.environ["DATABASE_URL"] = "postgresql://user:pass@host:5432/db"
print("\n--- With env var ---")
settings_env = AppConfig()
print(f"App Name: {settings_env.app_name}")
print(f"DB URL: {settings_env.database_url}")
# Clean up the environment variable for subsequent runs
del os.environ["APP_NAME"]
del os.environ["DATABASE_URL"]Leveraging `.env` Files
For local development, it's common to store settings in a .env file (e.g., .env) in your project root.
You can configure BaseSettings to load from this file using SettingsConfigDict(env_file='.env') in your settings class.
Example .env content:APP_NAME="Dev App"
API_KEY="your_dev_api_key"
from pydantic_settings import BaseSettings, SettingsConfigDict
class ProjectSettings(BaseSettings):
model_config = SettingsConfigDict(env_file='.env', extra='ignore')
app_name: str = "Default Project"
api_key: str = "default_key"
# To make this runnable, you would need python-dotenv installed
# and an actual .env file in the same directory as the script.
# For this lesson, we show the setup.
# Example usage (if .env existed and python-dotenv was active):
# if __name__ == "__main__":
# settings = ProjectSettings()
# print(f"App Name: {settings.app_name}")
# print(f"API Key: {settings.api_key}")
Understanding Settings Priority
When BaseSettings looks for a value, it follows a specific order of precedence:
- Environment variables (highest priority)
.envfile variables- Default values defined in the
BaseSettingsclass (lowest priority)
This ensures that environment variables can always override local .env files and class defaults, which is crucial for deployment.
Test Your Knowledge!
Which of the following are true about Pydantic's BaseSettings and custom types?
Recap: Custom Types & Settings
Great job! You've learned how to create powerful custom data types with Annotated and BeforeValidator, extending Pydantic's validation.
You also mastered BaseSettings for robust application configuration, understanding how it loads values from defaults, .env files, and environment variables with clear priority rules.
These tools are essential for building flexible and maintainable FastAPI applications!
Questions Fréquemment Posées
La leçon « Types de données et paramètres personnalisés » est-elle gratuite ?
Oui — le texte complet de « Types de données et paramètres personnalisés » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours FastAPI Backend Development Bootcamp, passe à CoddyKit PRO. Le cours FastAPI Backend Development Bootcamp comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Types de données et paramètres personnalisés » ?
Définissez des types de données Pydantic personnalisés et gérez les paramètres de l’application avec le `BaseSettings` de Pydantic. Tu pratiques FastAPI Backend Development Bootcamp avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer FastAPI Backend Development Bootcamp ?
Aucune expérience préalable n'est requise. FastAPI Backend Development Bootcamp sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 2 sur 4.
Combien de temps prend la leçon « Types de données et paramètres personnalisés » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon FastAPI Backend Development Bootcamp ?
Oui. Chaque leçon FastAPI Backend Development Bootcamp inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Validation des champs Pydantic et validateurs
- Types de données et paramètres personnalisés
- Modèles imbriqués et structures récursives
- Sérialisation avec model_dump et les alias