Pydantic: Data Validation

Ciao, sono Alex di DEV STORIES DOT EU. Pydantic: Data Validation, episodio 1 di 20. La maggior parte delle librerie di data validation ti costringe a imparare un domain-specific language completamente nuovo solo per definire uno schema. Ma cosa succederebbe se la sintassi built-in di Python fosse già sufficiente per far rispettare le tue regole? La filosofia di Pydantic: Type Hints come validazione risolve proprio questo problema. Prima di vedere come funziona, dobbiamo chiarire un equivoco comune. Pydantic non è uno static type checker come mypy. Mypy analizza il tuo codice sorgente prima dell'esecuzione per individuare errori di logica. Pydantic opera a runtime. Prende dati untrusted dal mondo esterno, come un payload JSON da una richiesta API, e li obbliga a conformarsi ai tipi che hai definito, proprio mentre il tuo programma è in esecuzione. La filosofia di base qui è la semplicità. Definisci un data model usando le type annotations standard di Python. Crei una classe che rappresenta un utente e specifichi che l'user ID è un integer, e la data di registrazione è un oggetto datetime. Questo è il tuo intero schema. Non scrivi funzioni di validazione custom o importi field types proprietari. Quando un dictionary disordinato arriva da un web form, lo passi semplicemente alla tua classe. Pydantic lo intercetta e garantisce che l'oggetto risultante rispetti rigorosamente quei tipi. Ecco il punto chiave. Pydantic è fondamentalmente una libreria di parsing, non solo un rigoroso sistema di validazione. Se un utente invia un web form in cui l'user ID è la string quarantadue, Pydantic riconoscerà che il tuo modello si aspetta un integer. Converte automaticamente quella string in un integer nativo di Python. Cerca di adattare i dati al tuo schema prima di sollevare un errore. Questo gestisce la noiosa data coercion, così non devi scrivere manualmente la logica di parsing per ogni input field. Validare e convertire ogni singolo dato in ingresso a runtime sembra intrinsecamente lento, soprattutto in Python. Per risolvere questo problema, la logica di esecuzione non gira effettivamente in Python. Pydantic delega il lavoro più pesante a un core engine dedicato, scritto interamente in Rust. Questo design ti offre la veloce developer experience di scrivere in puro Python, combinata con la pura velocità di esecuzione del codice di sistema compilato. Considera un background task che fa il parsing di un enorme file JSON in cui ogni record contiene un indirizzo web. Se scrivi codice Python puro per ciclare su migliaia di dictionary, estrarre ogni string, caricare una libreria di regular expression e verificare che ogni string sia un URL valido, il tuo processo sarà lentissimo. Pydantic gestisce tutto questo in modo impeccabile. Ti basta annotare il campo address come tipo URL e dare in pasto il JSON grezzo al tuo modello. Il motore Rust sfreccia attraverso il testo, facendo il parsing e validando i formati a velocità che il Python nativo non può eguagliare. Il vero punto di forza di questo approccio è che l'autocomplete del tuo editor, i tuoi tool di analisi statica e la tua validazione a runtime condividono tutti la stessa identica source of truth, che sono i tuoi type hints standard. Se trovi utili questi episodi e vuoi supportare il podcast, puoi cercare DevStoriesEU su Patreon. Questo è tutto per questo episodio. Grazie per l'ascolto e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Pydantic: Data Validation, episodio 2 di 20. Parliamo spesso di validazione dei dati, ma se guardi da vicino Pydantic, il suo obiettivo principale in realtà è la coercion. Garantisce la struttura del tuo output, non del tuo input. L'anatomia di un BaseModel è ciò che rende possibile questa distinzione. La classe BaseModel è il fondamento di Pydantic. Per definire uno schema, crei una classe Python standard ed erediti da BaseModel. Una volta fatto, Pydantic trasforma la tua classe in un data container rigoroso. Definisci la forma dei tuoi dati usando i type hint standard di Python. Non hai bisogno di funzioni proprietarie per dichiarare una string o un numero. Ti basta scrivere il nome dell'attributo, due punti e il tipo Python previsto. Prendi ad esempio un modello User. All'interno della classe, definisci un singolo campo chiamato id, e gli assegni il tipo integer. Potresti anche aggiungere un campo name di tipo string. Questa è l'intera definizione. Ecco il punto chiave. Il vero lavoro avviene nel momento in cui istanzi il modello. Crei un'istanza passando i tuoi dati come keyword argument, facendoli corrispondere ai nomi dei campi che hai definito. Quando lo fai, Pydantic intercetta i dati prima che l'oggetto sia completamente inizializzato. Confronta i valori in ingresso con i tuoi type hint. È qui che avviene la coercion. Se passi l'integer uno due tre nel campo id, Pydantic lo accetta immediatamente. Ma supponi di ricevere dati da una web request o da un file di testo, e di passare la string "123" in quello stesso identico campo. Pydantic non lancia immediatamente un errore. Riconosce che il tipo di destinazione è un integer e tenta di convertire la string. Dato che i caratteri possono essere castati in modo sicuro a un numero, Pydantic esegue la conversione silenziosamente. L'oggetto viene creato e il campo id memorizza un vero integer Python, non una string. Questo comportamento dimostra che Pydantic è essenzialmente una libreria di parsing. Trasforma i dati in ingresso per adattarli allo schema rigoroso che hai definito. Naturalmente, questa conversione ha dei limiti logici. Se istanzi il modello User e passi la string "not an int" al campo id, Pydantic tenta la conversione e fallisce. Quando la coercion è impossibile, Pydantic solleva un ValidationError. Questo errore interrompe immediatamente l'esecuzione. Un dettaglio cruciale del ValidationError è che Pydantic valuta tutti i campi prima di sollevarlo. Se il tuo modello ha più campi con dati non validi, l'eccezione conterrà i dettagli di tutti i fallimenti, anziché fermarsi al primissimo errore. L'errore indica i campi esatti che hanno causato il problema, i valori specifici forniti e i motivi per cui il parsing è fallito. Una volta che i tuoi dati superano con successo l'istanziazione, l'oggetto risultante corrisponderà garantitamente ai tuoi type hint. Accedi ai dati esattamente come a qualsiasi oggetto Python standard, usando la dot notation. Se hai assegnato l'istanza a una variabile chiamata user, ti basta digitare user punto id per recuperare l'integer. Non sono necessari metodi getter o setter. Stai interagendo con un oggetto pulito e fortemente tipizzato. Il vero valore di ereditare da BaseModel non è solo che rifiuta gli input errati, ma che normalizza in modo sicuro dati esterni imprevedibili in uno stato interno altamente prevedibile. Grazie per l'ascolto. Un saluto a tutti.

Ciao, sono Alex di DEV STORIES DOT EU. Pydantic: Data Validation, episodio 3 di 20. I type hint standard ti dicono che un field è un integer, ma non possono dirti che deve essere maggiore di zero. Quando un'età negativa o uno username di diecimila caratteri sfuggono ai limiti della tua applicazione, il type checking di base non è più sufficiente a proteggere il tuo backend. Per imporre limiti rigorosi ai tuoi dati, hai bisogno dei Field Constraint e dell'Annotated Pattern. In Pydantic, i constraint ti permettono di limitare i valori consentiti per un tipo specifico. Invece di scrivere funzioni validator custom per ogni piccola regola, puoi definire limiti matematici o strutturali direttamente sul field. Per i tipi numerici, puoi imporre limiti di maggiore o minore utilizzando parametri come g-t e l-t. Per le string, puoi limitare la dimensione dell'input utilizzando max length e min length. Per applicare queste regole, Pydantic fornisce una utility function chiamata Field. Il modo tradizionale in cui i developer applicavano questi constraint era assegnare una chiamata alla funzione Field come default value di un attributo del model. Ad esempio, dichiaravi un attributo age, gli davi un type hint come integer e lo impostavi uguale a Field, passando g-t uguale a zero. Questa struttura funziona, ma introduce attrito. Se ti serve un integer positivo in quindici model diversi, ti ritrovi a scrivere la stessa identica assegnazione di Field quindici volte. Peggio ancora, dato che la funzione Field occupa lo slot di assegnazione del default value sul model, le cose si complicano quando vuoi effettivamente assegnare un vero integer di default a quell'attributo. Ecco l'intuizione chiave. Non devi per forza legare le tue regole di validazione all'assegnazione dell'attributo. Puoi integrarle direttamente nella type definition stessa usando typing dot Annotated di Python. Annotated è una feature della standard library che ti permette di associare metadata arbitrari a un type hint di base. Pydantic è progettato specificamente per guardare all'interno di un tipo Annotated, trovare qualsiasi funzione Field che hai fornito ed estrarne automaticamente le regole di validazione. Quando usi Annotated, gli passi due informazioni distinte. Primo, fornisci il base type di Python, come un integer o una string. Secondo, fornisci i metadata, che nel nostro caso sono la funzione Field di Pydantic contenente i tuoi constraint. Costruiamo un tipo age riutilizzabile per vedere come funziona. Definisci una nuova variabile nel tuo codice chiamata PositiveInt. La assegni ad Annotated. All'interno di Annotated, passi integer come base type, seguito da una virgola, e poi la funzione Field con g-t uguale a zero. Hai appena creato un type constraint custom e riutilizzabile. Ora, ogni volta che definisci uno user model o un employee model, ti basta usare PositiveInt come type hint per il tuo field age. Non hai bisogno di chiamare la funzione Field sull'attributo del model. Questo approccio separa le tue type definition dalle strutture del tuo model. I tuoi model rimangono incredibilmente puliti, e si leggono proprio come classi Python standard senza clutter. Se in seguito la tua business logic cambia e improvvisamente hai bisogno che un field age sia maggiore di diciotto anziché zero, aggiorni la definizione di PositiveInt in un solo punto. Quel constraint aggiornato si propaga all'istante a ogni model che lo utilizza. Inoltre, dato che Annotated è una feature nativa di Python, gli static type checker capiscono perfettamente che il tuo PositiveInt custom viene infine valutato come uno standard integer. Disaccoppiando i metadata di validazione dallo slot del default value, l'Annotated Pattern trasforma i field constraint da boilerplate ripetitivo in una libreria condivisa di domain type rigorosi e riutilizzabili. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. Pydantic: Data Validation, episodio 4 di 20. Ti è mai capitato di dover chiamare una variabile Python in camel case solo per fare il parse del payload di un'API esterna? Sai che viola le naming convention standard di Python, ma il JSON in ingresso detta la chiave. La soluzione a questo problema sono i Field Alias per la validazione e la serializzazione. Quando acquisisci dei dati, le chiavi in quel payload spesso non corrispondono a come vuoi strutturare il tuo codice Python. Se un servizio di terze parti invia un profilo utente con la chiave user name con la N maiuscola, vuoi mapparla a una variabile standard in snake case chiamata user underscore name. Pydantic gestisce questo layer di traduzione usando la funzione Field, in particolare tramite i suoi argomenti alias. L'approccio più semplice è l'argomento base alias. Quando dichiari un attributo del tuo model, gli assegni un Field e imposti il parametro alias sulla string aspettata dal mondo esterno. Se imposti l'alias sulla versione camel case, Pydantic usa esattamente quella string sia in lettura che in scrittura. Durante la validazione dei dati in ingresso, cerca la chiave in camel case. Quando in seguito serializzi il model per fare il dump di nuovo in JSON, scrive la chiave in camel case. Il tuo codice Python interno opera interamente sull'attributo in snake case, completamente isolato dalla naming convention esterna. Questo gestisce i dati simmetrici, in cui il formato di input e il formato di output sono identici. Ora, la seconda parte riguarda i dati asimmetrici. Cosa succede quando consumi dati da un sistema legacy che usa una naming convention, ma devi servirli a un nuovo client che ne usa un'altra? È qui che dividi la logica usando i validation alias e i serialization alias. Sono argomenti separati che passi alla funzione Field. Un validation alias detta in modo rigoroso cosa Pydantic cerca durante la creazione del model. Se fornisci un validation alias, Pydantic lo userà per estrarre il valore dal payload in ingresso, facendo l'override di qualsiasi base alias che potresti aver impostato. Al contrario, un serialization alias controlla solo la fase di output. Quando chiami un metodo per fare il dump del model in un dictionary o in una string JSON, Pydantic usa il serialization alias come chiave di output. Ecco il punto chiave. Puoi definire un singolo field con tre identità distinte. Il validation alias intercetta la string di input disordinata dall'API legacy. L'attributo Python contiene la variabile pulita in snake case che usi nella tua business logic. Infine, il serialization alias definisce la chiave rifinita e standardizzata che viene inviata al tuo frontend. A volte il problema non è una naming convention rigida, ma una incoerente. Potresti ricevere dei payload in cui l'identificatore utente è a volte in camel case e a volte una singola parola senza spazi. Per gestire questo, Pydantic fornisce una utility chiamata alias choices. Invece di passare una singola string al validation alias, passi questa utility che contiene una lista di string. Durante la validazione, Pydantic scansiona il payload in ingresso per ogni string nell'ordine che hai fornito. Nel momento in cui trova una chiave corrispondente, estrae il valore, lo assegna al tuo attributo Python e ignora il resto. Separando il modo in cui i dati vengono parsati da come vengono esportati, gli alias disaccoppiano il design interno del tuo oggetto Python dai vincoli di naming arbitrari del mondo esterno. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Pydantic: Data Validation, episodio 5 di 20. La propensione di Pydantic a convertire la string "123" in un integer è una killer feature, finché non nasconde silenziosamente un bug di data-type nel tuo payload JSON. Ti aspetti dei numeri, ricevi delle string, e la tua applicazione va avanti felice finché un sistema downstream strict non va in crash. Il meccanismo che controlla questo comportamento è la Data Coercion, e per domarla devi capire la Strict Mode. Di default, Pydantic opera in quella che la documentazione chiama lax mode. In questa modalità, Pydantic agisce come un data parser piuttosto che come un semplice type checker. Cerca attivamente di fare coercion, ovvero convertire, i dati in ingresso nel type che hai dichiarato. Se definisci un field come integer, e il payload di input fornisce la string "123", Pydantic valuta la string, estrae il numero valido e lo trasforma in un vero e proprio integer. Questo comportamento è incredibilmente utile quando processi l'input dell'utente da web form o query parameter, dove ogni valore in ingresso è fondamentalmente una string. Tuttavia, quando sviluppi API machine-to-machine, la conversione silenziosa è spesso pericolosa. Se un client promette di inviare un integer ma invia invece una string, sta violando l'API contract. La lax mode maschera questa violazione. È qui che entra in gioco la strict mode. La strict mode disabilita la type coercion automatica. Quando la attivi, Pydantic richiede che il data type in ingresso corrisponda esattamente alla tua type annotation. Passa la string "123" a un field integer strict, e Pydantic la rifiuta immediatamente con un validation error. Forza la data source a rispettare lo schema. Hai due modi per applicare la strict mode: globalmente su tutto un model, o localmente su field specifici. Per forzarla globalmente, modifichi la configurazione del model. Impostando il configuration flag strict a true, ogni singolo field all'interno di quel model smette di fare coercion dei type. Un field boolean accetterà solo un valore boolean true o false, non la string "true" o l'integer uno. Un field integer accetterà solo integer. Ecco il punto chiave. La strictness globale è spesso troppo rigida per le applicazioni reali, dove i dati arrivano da fonti miste. Di solito vuoi blindare alcuni identifier critici, lasciando flessibile il resto del model. Per ottenere questo risultato, Pydantic permette la strictness locale. Puoi forzare la strict mode su un singolo field usando dei type specializzati forniti dalla library, come StrictInt, StrictStr o StrictBool. Se definisci un field user ID usando StrictInt, quel field specifico rifiuterà le rappresentazioni string dei numeri, mentre il resto del tuo model continuerà a operare in lax mode. Puoi ottenere questo risultato anche passando un flag strict direttamente nella funzione di definizione del field per qualsiasi type standard. Considera un service che processa un payload JSON per una transazione finanziaria. Il payload contiene un account ID. Se definito come un normale integer, un payload che invia l'account ID come string "123" passa senza problemi. Pydantic corregge il data type in memoria. Se aggiorni quel field per usare StrictInt, lo stesso identico payload JSON fallisce la validation. Il client riceve un errore esplicito che indica che l'input deve essere un integer valido, intercettando la violazione del contract al boundary del sistema prima che inquini il tuo database. La strict mode trasforma Pydantic da un utile parser che ripulisce input disordinati in un rigido enforcer che garantisce i data contract. Grazie per l'ascolto. Un saluto a tutti.

Ciao, sono Alex di DEV STORIES DOT EU. Pydantic: Validazione dei dati, episodio 6 di 20. Quando un payload complesso fallisce la validazione in produzione, lo stack trace standard da solo raramente ti dice esattamente perché i dati sono stati rifiutati. Sai che una request è fallita, ma sei completamente cieco sui reali valori in ingresso che hanno causato il crash. Questo è esattamente il problema che risolve la Real-World Observability con Logfire. Logfire è una piattaforma di observability sviluppata dal team di Pydantic, e offre un'integrazione diretta con Pydantic stesso. L'obiettivo è darti visibilità su cosa sta effettivamente facendo il tuo layer di validazione dei dati in produzione. Invece di trattare la validazione come una black box che ogni tanto lancia delle exception, questa integrazione trasforma ogni controllo di validazione in telemetry tracciata. Prendi come esempio un background worker che elabora i signup degli utenti da una message queue. Arrivano centinaia di eventi al secondo. All'improvviso, un signup fallisce con un validation error. Senza un'adeguata instrumentation, i tuoi log mostrano un crash generico. Devi andare a caccia del payload grezzo della queue per capire che l'utente ha inserito un'età di meno cinque. Per risolvere questo problema, importi il package Logfire e chiami una singola funzione che si chiama instrument underscore pydantic. La inserisci subito dopo aver inizializzato il tuo client Logfire. Da quel momento in poi, i tuoi modelli Pydantic sono completamente observable. Non devi cambiare il modo in cui definisci i tuoi modelli o come li istanzi. Ecco il punto chiave. Una volta instrumentato, ogni volta che Pydantic valida dei dati, Logfire crea automaticamente uno span. Uno span è semplicemente una registrazione temporizzata di un'operazione. Se il payload di signup è perfettamente valido, Logfire registra uno span di successo che mostra esattamente quanto tempo ha richiesto la validazione. Questo è estremamente utile se hai dei custom validator complessi e devi monitorare i performance bottleneck. Se il payload non è valido, Pydantic lancia un validation error. Logfire intercetta questo evento e allega i dettagli alla trace. Cattura lo specifico modello coinvolto e i campi esatti che hanno scatenato il fallimento. Quando guardi la tua observability dashboard, non vedi solo un messaggio di errore generico. Vedi gli esatti valori rifiutati, come quell'età negativa o una stringa email malformata. Il setup è completamente hands-off. Primo, configura il client. Secondo, chiama la funzione instrument. Terzo, lascia che il tuo worker elabori i dati. Quando il worker tenta di fare il parsing di una bad JSON string nel tuo signup model, la telemetry cattura automaticamente il contesto del fallimento. Non devi scrivere assolutamente nessun blocco di custom exception per loggare il bad input. Dato che Logfire capisce Pydantic nativamente, rispetta le tue strutture dati. Conosce la differenza tra un campo mancante e un type mismatch, e formatta quella telemetry in modo che tu possa farci delle query in seguito. Puoi filtrare le tue metriche per scoprire esattamente quante volte il campo email ha fallito la validazione in tutto il tuo worker cluster oggi. Il vero valore di questa integrazione è che eleva la validazione dei dati da un semplice code check a un evento di observability di prima classe, trasformando le rejection silenziose dei dati in telemetry strutturata e actionable. Se vuoi supportare lo show, puoi trovarci cercando DevStoriesEU su Patreon. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Pydantic: Data Validation, episodio 7 di 20. A volte hai solo bisogno di validare una semplice lista di string che arriva da una richiesta API, ma creare un'intera classe model solo per contenere quella singola lista sembra un'esagerazione. Non vuoi un oggetto wrapper, vuoi solo la lista validata. La soluzione è validare tipi arbitrari con TypeAdapter. In Pydantic, il workflow standard ruota attorno alla definizione di una classe che eredita dal base model. Quel model ti dà accesso a metodi potenti per il parsing e la serializzazione dei dati. Ma Pydantic è perfettamente in grado di validare i tipi Python standard, come un semplice dizionario, un intero a sé stante, una dataclass standard o un typed dict. L'intoppo è che questi tipi standard non possiedono nativamente i metodi di validazione di Pydantic. Non puoi chiamare validate su una lista Python standard. È qui che entra in gioco il TypeAdapter. Agisce come un ponte, facendo il wrapping di qualsiasi tipo Python arbitrario ed esponendo tutti i metodi del model che già conosci. Considera un endpoint web che accetta un array JSON raw di string. In passato, magari avresti creato un model fittizio con un singolo campo chiamato items, solo per potergli passare il payload JSON. Questo forza il client a inviare un oggetto JSON con una chiave items, o ti costringe a fare l'unpack del model validato in un secondo momento. Con un TypeAdapter, salti completamente il model fittizio. Per prima cosa, istanzi l'adapter e gli passi l'esatta definizione del tipo che ti aspetti. In questo caso, passi il type hint Python per una lista di string. Questo crea un oggetto adapter configurato specificamente per quell'esatta struttura. Ora hai accesso ai metodi di validazione standard. Prendi il payload JSON raw dal tuo endpoint e lo passi al metodo validate json sull'istanza del tuo adapter. Pydantic fa il parsing della byte string raw, verifica che sia un array JSON, controlla che ogni elemento al suo interno sia una string e restituisce una lista Python standard. Se il payload contiene un intero o un booleano, solleva un validation error esattamente come farebbe un model normale. Ecco il punto chiave. L'adapter non si limita alla semplice validazione. Rispecchia completamente la core API di un model standard. Questo significa che puoi usarlo anche per serializzare i dati. Se hai un dizionario complesso o una dataclass Python standard e devi riconvertirli in una JSON string, passi quei dati al metodo dump json sul tuo adapter. Applica tutte le stesse regole di serializzazione, custom encoder e formattazione che Pydantic applica ai model normali. Questa feature è particolarmente utile quando lavori con i typed dict. Un typed dict fornisce lo structural typing per i dizionari Python standard, ma non esegue alcuna validazione a runtime. Passando un typed dict a un adapter, ottieni il pieno enforcement a runtime della struttura del dizionario. Garantisce che tutte le chiavi richieste siano presenti e che i valori corrispondano ai tipi previsti, senza convertire il dizionario in un'istanza di oggetto. L'output rimane un semplice dizionario. Istanziare un adapter richiede a Pydantic di costruire dei validation schema interni. Dato che questo processo di setup richiede un po' di tempo di calcolo, dovresti creare le tue istanze dell'adapter a livello di modulo, anziché ricostruirle all'interno di una funzione ogni volta che viene chiamato un endpoint. Definisci l'adapter una sola volta all'inizio del tuo file, e riutilizzalo su più richieste. Il TypeAdapter ti dà tutta la potenza del core validation engine per qualsiasi tipo Python standard, mantenendo le tue strutture dati pulite e libere da classi wrapper non necessarie. Questo è tutto per oggi. Grazie per aver ascoltato, vai a creare qualcosa di fantastico.

Ciao, sono Alex di DEV STORIES DOT EU. Pydantic: Data Validation, episodio 8 di 20. Quando un field è annotato come Union di una string o di un integer, e passi l'integer 123, quale validazione tenta Pydantic per prima? Se presumi che legga semplicemente il tuo codice da sinistra a destra, potresti rimanere sorpreso quando i tuoi dati si comportano in modo diverso dal previsto. Questo ci porta agli Union Types e alla Smart Validation. Un Union type permette a un singolo field di accettare più data types distinti. Validare le Union è intrinsecamente complesso perché Pydantic cerca attivamente di applicare la coercion ai dati nel type richiesto. Un integer può facilmente diventare una string, e una string che contiene cifre può essere parsata in un integer. Se il validation engine prendesse semplicemente il primo match che trova, il tuo output cambierebbe interamente in base all'ordine arbitrario in cui hai elencato i types nel tuo codice. Questo comportamento rigido esiste, ed è chiamato Left to Right mode. In questa modalità, il sistema valuta l'input rispetto al primo type definito nella Union. Se la validazione ha successo, si ferma immediatamente. Se fallisce, passa al secondo type. Se il tuo field è tipizzato come string o integer, in quest'ordine, e passi l'integer 123, la Left to Right mode valuta prima la condizione della string. Dato che l'integer 123 può essere convertito tramite coercion senza problemi nella string "123", la validazione passa. Il tuo integer viene convertito silenziosamente in una string solo perché string è stata scritta per prima. Ecco il punto chiave. Di default, Pydantic evita questa trappola usando la Smart Mode. Invece di fermarsi al primo match accettabile, la Smart Mode valuta l'input rispetto a tutti i types possibili nella Union. Poi confronta le validazioni andate a buon fine e sceglie il match migliore in base a specifici criteri di punteggio. Il criterio principale per i types semplici è l'esattezza. La Smart Mode penalizza pesantemente la data coercion. Tornando al nostro scenario precedente con un field tipizzato come string o integer. Quando passi l'integer 123, la Smart Mode testa entrambe le opzioni. Riconosce che l'input può essere convertito tramite coercion in una string valida, ma vede anche che l'input è già un match perfetto ed esatto per un integer. Dato che un match esatto ottiene sempre un punteggio superiore rispetto a un match con coercion, la Smart Mode restituisce correttamente l'integer 123, indipendentemente da quale type sia stato scritto per primo nella Union. Quando la tua Union contiene data models complessi anziché types di base, la Smart Mode si affida a una metrica diversa. Conta il numero di fields validi impostati. L'engine valuta il dictionary di input rispetto a ogni model nella Union. Calcola quanti fields nell'input mappano esattamente sui fields definiti di ciascun model. Il model che assorbe con successo il maggior numero di fields di input senza lanciare validation errors viene dichiarato vincitore. Questo impedisce a un model più piccolo e meno specifico di inghiottire dati che erano chiaramente destinati a un model più grande e dettagliato nella stessa Union. La Smart Validation assicura che i tuoi dati mantengano la loro forma originale precisa ogni volta che è possibile, proteggendoti da errori di coercion silenziosi che sono notoriamente difficili da individuare in production. Grazie per l'ascolto, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. Pydantic: Data Validation, episodio 9 di 20. Validare un payload in ingresso contro venti data model diversi procedendo per tentativi è un incubo per le performance. Quando il tuo sistema riceve un evento generico, indovinare quale schema applicare spreca cicli di CPU e genera messaggi di errore estremamente confusi quando la validazione fallisce. Puoi evitare completamente di andare a tentativi usando un vero e proprio power tool: le Discriminated Union. Una union standard dice a Pydantic che un field potrebbe essere uno tra diversi model. Di default, Pydantic prende i dati in ingresso e li testa contro il primo model. Se fallisce, prova col secondo, e così via. Questo parsing sequenziale è inefficiente. Le Discriminated Union risolvono il problema usando un tag esplicito. Supponi di costruire una pipeline di analytics che riceve diversi tipi di evento, come un evento click, un evento scroll e un evento purchase. Ogni evento richiede field diversi. Il model click potrebbe aver bisogno di un element ID, mentre il model purchase ha bisogno dell'importo della transazione. Per configurare una Discriminated Union, aggiungi un field condiviso a ogni singolo model di quel gruppo. Potresti chiamare questo field event type. Poi, assegni a questo field un tipo literal string. Il model click impone che l'event type sia esattamente la string click. Il model purchase impone rigorosamente la string purchase. Dopodiché, crei il tuo model principale per il payload. Questo model ha un singolo field event, definito come una union dei tuoi model di evento specifici. È qui che configuri il discriminator. Racchiudi la definizione della union in una configurazione field di Pydantic, e assegni la string event type all'argomento discriminator. Ecco il punto chiave. Quando arriva un payload, Pydantic non testa più i model uno per uno. Guarda direttamente la key event type nei dati in ingresso. Se il valore è purchase, Pydantic instrada immediatamente l'intero payload al model purchase. È un lookup diretto. Se manca l'importo della transazione, il messaggio di errore dice chiaramente che manca un field obbligatorio per un evento purchase, invece di generare un enorme muro di testo che spiega come i dati non abbiano fatto match con tutti i possibili event type. Questo copre una struttura pulita in cui ogni payload condivide una key di primo livello. A volte ti trovi a gestire dati non strutturati di terze parti, dove il tag identificativo è annidato dentro un altro oggetto, oppure il model corretto dipende dalla presenza di key specifiche anziché da un singolo valore dedicato. Per queste situazioni, Pydantic fornisce dei callable discriminator. Invece di passare il nome di un field string all'argomento discriminator, passi una funzione custom. Questa funzione riceve i dati di input raw e non validati. Scrivi la logica all'interno di questa funzione per ispezionare il dictionary raw, trovare qualsiasi indizio determini il tipo di dato, e restituire un semplice tag string che rappresenta il model corretto. Pydantic esegue prima la tua funzione, ottiene indietro il tag string, e lo usa per instradare i dati al model preciso nella union. Usare una Discriminated Union trasforma la validazione da un gioco di tentativi sequenziali a un lookup preciso in tempo costante. Grazie per l'ascolto, buona giornata a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. Pydantic: Validazione dei dati, episodio 10 di 20. A volte i tuoi dati in ingresso sono così incasinati che il parsing standard fallisce nel momento stesso in cui toccano il tuo model. Devi intercettare e sanificare l'input grezzo prima ancora che il framework provi a leggerlo. Questo è esattamente ciò che ti permette di fare il pre-processing con i validator Before e Wrap. Di solito Pydantic fa un ottimo lavoro nel fare la coercion automatica dei dati nel tipo corretto. Ma se la forma fondamentale dei dati è completamente sbagliata, la coercion fallisce immediatamente. Un validator Before è pensato proprio per questo problema. È una funzione attaccata a un field che viene eseguita prima che Pydantic faccia qualsiasi type checking o conversione. Riceve l'input grezzo e intatto, esattamente come è stato passato al model. Immagina uno scenario in cui il tuo model definisce un field che richiede rigorosamente una list di interi. Tuttavia, stai consumando un'API esterna che invia per errore questi dati come un'unica string continua di numeri separati da virgole, come ad esempio la string uno virgola due virgola tre. Pydantic si aspetta un array, vede una singola string e la rifiuta con un validation error. Puoi risolvere la cosa scrivendo un validator Before. All'interno della tua funzione validator, guardi l'input grezzo. Controlli se il valore è una string. Se lo è, fai uno split di quella string ad ogni virgola, il che crea una list di singoli caratteri string. Non devi convertire tu a mano questi caratteri in interi. Ti basta restituire la list appena creata. Da lì in poi ci pensa Pydantic. Vede la list che si aspettava, esegue la sua coercion interna standard e trasforma quei valori string in interi per te. Dovevi solo sistemare la forma strutturale dei dati. Questo copre gli input che girano prima della logica principale. Il livello di controllo successivo è il validator Wrap. I validator Wrap sono il tool di validazione più flessibile che Pydantic offra. Invece di girare semplicemente prima dello step di validazione, un validator Wrap circonda letteralmente il motore di validazione interno di Pydantic per quel field. Quando scrivi un validator Wrap, la tua funzione riceve due argomenti. Il primo sono i dati di input grezzi, proprio come nel validator Before. Il secondo argomento è una funzione handler. Questo handler rappresenta la logica core di validazione e coercion di Pydantic. Ed è qui che la cosa si fa interessante. Sei tu a decidere esattamente quando, o persino se, quella funzione handler deve essere eseguita. Il flusso logico è interamente nelle tue mani. Puoi ispezionare l'input grezzo e modificarlo. Poi, chiami esplicitamente l'handler, passandogli i tuoi dati puliti. Pydantic esegue il suo type checking interno su ciò che gli hai fornito e restituisce il valore completamente parsato al tuo validator. A quel punto puoi modificare di nuovo quel valore parsato prima di passarlo al model finale. Dato che controlli tu quando l'handler viene eseguito, puoi inserirlo all'interno di un blocco try except standard. Se la validazione interna di Pydantic lancia un errore, lo catturi direttamente lì nel validator Wrap. Puoi loggare l'errore, alterare i dati e riprovare, oppure semplicemente restituire un valore di default sicuro. Puoi persino scrivere una logica che salta completamente l'handler per certi input specifici, bypassando del tutto la validazione standard. I validator Before sanificano le forme di input errate in modo che Pydantic possa leggerle, mentre i validator Wrap ti danno autorità totale sull'intero ciclo di vita della validazione attorno a un singolo field. Questo è tutto per questo episodio. Grazie per l'ascolto e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Pydantic: Data Validation, episodio 11 di 20. Verificare se una string ha il formato di un indirizzo email è semplice. Verificare che i dati rispettino una business logic rigorosa, come fare cross-referencing con un sistema esterno o applicare regole matematiche specifiche, richiede un ambiente sicuro in cui eseguire codice custom. Questo è esattamente ciò che offre il post-processing con i validator After e Plain. Quando definisci un field in un model Pydantic, la libreria controlla automaticamente l'input rispetto al type hint. I type, però, ti portano solo fino a un certo punto. Un integer è un integer, che sia uno o un milione. Per applicare regole che vanno oltre i type di base, aggiungi delle funzioni di validazione custom. Pydantic ti permette di iniettare queste funzioni nel validation lifecycle. L'injection point più comune è l'After validator. Come suggerisce il nome, questo viene eseguito dopo che Pydantic ha terminato il suo parsing interno e la type coercion. Ecco il punto chiave. Quando la tua funzione custom riceve i dati in un After validator, Pydantic garantisce che i dati corrispondano già al field type. Non devi scrivere codice boilerplate per gestire la type conversion o intercettare data type imprevisti. Considera uno scenario in cui devi assicurarti che un field integer sia un numero pari. Definisci un model con un field tipizzato come integer. Quindi, scrivi una funzione custom che accetta un valore come argomento. Dato che configuri questa funzione come After validator, sai che il valore è assolutamente un integer. Ti basta usare l'operatore modulo per verificare se la divisione del valore per due lascia un resto. Se il resto non è zero, sollevi un ValueError standard di Python con un messaggio custom. Se il resto è zero, restituisci il valore. Pydantic prende il valore restituito e lo assegna al model. La divisione del lavoro è chiara. Pydantic impone il type, e tu imponi la business rule. A volte il default parsing di Pydantic ti è d'intralcio. È qui che entra in gioco il Plain validator. Un Plain validator sostituisce completamente la validazione interna di Pydantic per un field specifico. Pydantic si fa da parte e passa il raw input, non validato, direttamente alla tua funzione custom. Usi un Plain validator quando le regole di coercion standard non sono adatte al tuo use case, oppure quando hai a che fare con una data structure altamente custom che Pydantic non comprende nativamente. In questo scenario, la tua funzione è responsabile di tutto. Riceve il raw input, esegue tutto il type checking necessario, converte i dati e applica la business logic. Se qualcosa fallisce, la tua funzione deve sollevare un ValueError o un AssertionError. Se ha successo, restituisce il valore finale e pulito per il model. Associ entrambi questi validator ai field utilizzando i decorator di Pydantic sui class method, oppure aggiungendoli come metadata direttamente all'interno del type hint tramite annotation. La scelta tra i due dipende da quanto lavoro vuoi fare tu stesso. Usa un After validator quando vuoi che Pydantic faccia il lavoro pesante della type conversion, e scegli un Plain validator solo quando hai bisogno del controllo assoluto sul parsing del raw input da zero. Grazie per l'ascolto, ci sentiamo alla prossima.

Ciao, sono Alex di DEV STORIES DOT EU. Pydantic: Data Validation, episodio 12 di 20. La validazione dei field in isolamento funziona perfettamente, fino al momento in cui la tua business logic impone che il field B possa essere impostato solo se il field A ha un valore specifico. Quando l'integrità dei dati dipende dall'interazione di più field, hai bisogno dei Model-Level Validation Hook. In Pydantic, gestisci i field interdipendenti usando il decoratore model validator. A differenza dei field validator che si concentrano su un singolo dato in ingresso, un model validator analizza l'intera struttura dati in una volta sola. Pydantic offre tre modalità per questo decoratore: before, after e wrap. Determinano esattamente quando la tua logica custom viene eseguita durante il ciclo di vita di parsing. Applichiamo questo a un model standard di registrazione utente. Hai due field: password e password repeat. Un controllo a livello di field può verificare la lunghezza o la complessità, ma non può confrontare i due. Per questo, usi un model validator in modalità after. La modalità after viene eseguita una volta che Pydantic ha fatto il parsing e validato con successo tutti i singoli field. A questo punto, la tua funzione di validazione riceve l'istanza del model stesso. Scrivi semplicemente una logica che verifica se l'attributo password del model è uguale al suo attributo password repeat. Se differiscono, sollevi un ValueError. Ecco il punto chiave. Quando usi la modalità after, la tua funzione deve restituire esplicitamente l'istanza del model, di solito chiamata self, alla fine del metodo. Se dimentichi di restituire self, Pydantic scarterà i tuoi dati validati e non restituirà nulla. A volte hai bisogno di intercettare i dati prima. È qui che entra in gioco la modalità before. Un model validator in modalità before viene eseguito prima che Pydantic tenti qualsiasi parsing o type coercion. Invece di un'istanza del model tipizzata, la tua funzione riceve l'input raw, che in genere è un dictionary. Usi questa modalità quando la struttura dei dati raw è disordinata e ha bisogno di aggiustamenti prima ancora che la validazione standard possa iniziare. Per esempio, se delle request API legacy inviano configurazioni della password in un dictionary annidato, un validator before può estrarre quelle stringhe e appiattirle nelle chiavi top-level che il tuo model Pydantic si aspetta. La funzione poi restituisce il dictionary modificato, passandolo lungo la chain. La terza modalità è wrap. Questa serve per avere il controllo totale sul ciclo di vita della validazione. Un validator wrap prende i dati di input raw e una funzione di handler. Esegui la tua logica di pre-processing, chiami esplicitamente l'handler per innescare la validazione interna di Pydantic, e poi esegui il post-processing sul risultato. Usi questo quando hai bisogno di intercettare gli errori di validazione interni di Pydantic, loggarli su un sistema esterno, e magari restituire un messaggio di errore modificato o un oggetto di fallback di default. Scegliere la modalità giusta è solo una questione di tempistica. Usa before per modellare l'input raw, after per confrontare field fortemente tipizzati, e wrap per controllare l'esecuzione della validazione stessa. Se trovi utili questi episodi e vuoi supportare lo show, puoi cercare DevStoriesEU su Patreon. Per questo episodio è tutto. Ci vediamo alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. Pydantic: Validazione dei dati, episodio 13 di 20. Inserire dati validi nel tuo sistema è solo metà del lavoro. Quando arriva il momento di restituire quei dati a un frontend, spesso ti accorgi che i tuoi payload sono pieni di campi vuoti e valori di default che l'utente non ha mai effettivamente fornito. La serializzazione, ovvero fare il dump dei dati in modo sicuro, è il modo in cui ripulisci questo flusso in uscita. Una volta che i tuoi dati sono al sicuro all'interno di un model Pydantic, prima o poi devi estrarli per inviarli altrove. Hai due modi principali per farlo. Il primo è chiamare model dump. Questo metodo legge il tuo model e restituisce un semplice dictionary Python. Il secondo è chiamare model dump json. Questo metodo salta il passaggio del dictionary e restituisce una string JSON completamente formattata, pronta per essere inviata in rete. La differenza tra questi due metodi va un po' oltre la semplice differenza tra un dictionary e una string. Riguarda le modalità di serializzazione. Di default, model dump opera in Python mode. Se il tuo model contiene un tipo complesso, come un oggetto datetime, il dictionary risultante conterrà comunque un oggetto datetime di Python. D'altra parte, model dump json opera in JSON mode. JSON non sa cosa sia un oggetto datetime di Python, quindi Pydantic lo converte automaticamente in una rappresentazione a string standard. Ecco il punto chiave. Puoi effettivamente forzare l'output del dictionary a utilizzare il JSON mode. Se chiami model dump e passi l'argomento mode impostato su json, Pydantic restituisce un dictionary in cui tutti i tipi complessi sono già stati tradotti in formati di base JSON-safe, come string e integer. Questo gestisce i tipi, ma devi comunque gestire la forma del payload. Prendi un model di profilo utente che restituisce dati a un frontend. Il model potrebbe definire venti possibili campi. Un nuovo utente si registra e fornisce solo il suo nome e la sua email. Gli altri diciotto campi assumono come fallback string vuote, null o URL di default per l'avatar. Se fai il dump di quel model normalmente, invii tutti e venti i campi al frontend. Per risolvere questo problema, Pydantic fornisce tre keyword argument specifici che puoi passare a entrambi i metodi di dump. Il più preciso è exclude unset. Quando imposti exclude unset su true, Pydantic fa il tracking esatto di quali campi sono stati popolati al momento della creazione del model. Farà il dump solo di nome ed email. I diciotto campi di default vengono completamente esclusi dal dictionary o dalla string JSON. Questo ti assicura di non fare mai leak di dati di fallback che l'utente non ha effettivamente inviato. Se vuoi un comportamento leggermente diverso, puoi usare exclude defaults. Questo flag dice a Pydantic di omettere qualsiasi campo che attualmente corrisponde al suo valore di default. Non gli importa se l'utente ha inviato esplicitamente quel valore di default o se il sistema lo ha compilato automaticamente. Se il valore corrisponde al default, viene rimosso dall'output. Infine, c'è exclude none. Impostalo su true e Pydantic rimuoverà qualsiasi campo il cui valore è attualmente none. Questo è puramente un controllo sul valore e ignora completamente il tracking dei default o degli unset. Questi flag di esclusione ti offrono un controllo rigoroso sul tuo traffico di rete e sulle response delle API. Mantieni i tuoi model interni completamente esaustivi, ma usa i tuoi metodi di dump per assicurarti che i tuoi payload esterni rimangano esattamente snelli quanto serve. Grazie per averci seguito. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. Pydantic: Data Validation, episodio 14 di 20. Cosa succede se salvi una data internamente come oggetto datetime di Python, ma l'API contract del tuo frontend richiede un Unix timestamp intero raw? Potresti fare un loop sui tuoi dati subito prima di inviarli, ma è una soluzione caotica e soggetta a errori. Il modo più pulito è personalizzare la serialization logic direttamente all'interno dei tuoi model Pydantic. Pydantic ti offre dei decorator per intercettare il momento esatto in cui un model viene riconvertito in un dict o in JSON. Iniziamo con i field serializer. Un field serializer punta a un attributo specifico. Per crearne uno, scrivi un normale metodo all'interno della classe del tuo model e ci metti sopra il decorator field serializer. Passi al decorator il nome del field che vuoi modificare. Prendiamo come esempio quello scenario con datetime. Hai un model con un attributo chiamato created at, tipizzato come un normale datetime di Python. All'interno del model, crei un metodo chiamato serialize created at. Il nome del metodo non importa. Sopra di esso, posizioni il decorator field serializer, che punta al field created at. Il metodo prende il valore datetime come input. All'interno del metodo, chiami la funzione timestamp standard su quel datetime e restituisci l'intero risultante. Ora, ogni volta che il model fa il dump dei suoi dati, Pydantic intercetta il field created at, esegue il tuo metodo custom e restituisce un intero pulito invece di una stringa in formato ISO. Ecco il punto chiave. I serializer operano in due modalità distinte: plain e wrap. La modalità plain è quella di default. Quando un serializer è in modalità plain, Pydantic scarta completamente la sua logica interna per quel field ed esegue solo il tuo codice custom. È un override completo. Ma a volte hai bisogno di eseguire prima la logica di default, e poi modificare il risultato. O magari vuoi intercettare degli errori legati al comportamento di default. È in questi casi che usi la modalità wrap. Per abilitarla, passi mode equals wrap al decorator. In modalità wrap, il tuo metodo riceve un secondo argomento chiamato handler. Questo handler è una reference alla serialization logic interna di Pydantic. Puoi chiamare l'handler per ottenere l'output di default, ispezionarlo, modificarlo o usarlo come fallback se la tua logica custom fallisce. Questo copre i singoli field. Se hai bisogno di cambiare la struttura dell'intero output, usi un model serializer. Il setup è quasi identico, ma il decorator va sopra un metodo che opera sull'intera istanza del model. Invece di ricevere il valore di un singolo field, il metodo accede agli attributi del model stesso. Se metti un model serializer in modalità plain, restituisci una struttura dict completamente nuova partendo da zero. Se lo metti in modalità wrap, il tuo metodo prende un argomento handler, proprio come il field serializer. Chiami l'handler per ottenere prima il dict standard del model. Poi puoi aggiungere nuove chiavi top-level, rimuovere dati privati o appiattire strutture annidate prima di restituire il dict finale. L'aspetto più potente di questi decorator è che disaccoppiano i tuoi tipi Python interni dai tuoi API contract esterni, mantenendo una validazione rigorosa in ingresso e una formattazione precisa in uscita. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Pydantic: Data Validation, episodio 15 di 20. Se gli schemi delle tue API sono già rigorosamente tipizzati in Python, dover mantenere un file YAML separato per la tua documentazione OpenAPI è un'enorme perdita di tempo. Finisci per mantenere due source of truth che inevitabilmente si disallineano. Generare il JSON Schema direttamente dai tuoi model risolve questo problema di sincronizzazione. Ogni model Pydantic include un metodo chiamato model json schema. Quando chiami questo metodo, Pydantic analizza il tuo model. Legge i field, i tipi, i valori di default e i vincoli di validazione. Quindi traduce tutta questa logica interna di Python in un dictionary JSON Schema standard. Nello specifico, Pydantic genera il Draft 2020-12 della specifica JSON Schema. Questa è la parte che conta. Dato che l'output aderisce a questo standard ampiamente accettato, è nativamente compatibile con OpenAPI. Definisci le tue regole di validazione rigorose una sola volta in Python, e il framework fornisce automaticamente l'esatta definizione dello schema di cui i tuoi consumer esterni hanno bisogno. Non è richiesta alcuna traduzione manuale. La generazione standard dello schema gestisce perfettamente i tipi e i vincoli di base. Ma a volte hai bisogno di comunicare logiche di business o formati specifici che non possono essere dedotti solo da un type hint di Python. Considera uno scenario in cui stai creando un model Configuration per un nuovo servizio. Il model contiene un field che accetta un dictionary di impostazioni custom. Il team frontend deve sapere esattamente che aspetto ha un payload valido, invece di sapere solo che si tratta di un object generico. Per risolvere questo problema, usi una feature chiamata json schema extra. Questo parametro ti permette di iniettare metadati custom arbitrari direttamente nel JSON Schema generato. Puoi usarlo per aggiungere esempi mock, descrizioni custom, o marker di keyword specifici che il tuo API gateway potrebbe richiedere. Puoi applicare json schema extra a due livelli distinti. Puoi associarlo a un singolo field, oppure puoi applicarlo all'intero model. Per fornire un esempio mock per quello specifico field settings, definisci il tuo model Configuration. Per l'attributo settings complesso, gli assegni una funzione Field. All'interno di quella funzione Field, passi l'argomento json schema extra. Gli passi un dictionary che contiene la chiave standard di JSON Schema chiamata examples. Il valore mappato a quella chiave è una list che contiene l'esatto payload della tua configurazione mock. In alternativa, se vuoi documentare l'intero model invece di un singolo field, definisci un dictionary model config sulla classe. All'interno di quel dictionary di configurazione, fornisci json schema extra con un esempio a livello di schema. Questo approccio è utilissimo quando vuoi mostrare come più field interagiscono tra loro in un request body completo. Quando esegui model json schema sul tuo model Configuration, Pydantic costruisce l'albero dello schema standard. Quando raggiunge i tuoi field o la configurazione del model, fa il merge del tuo dictionary di esempi custom direttamente nello standard output. I tool di frontend leggono questo schema, fanno il parsing della proprietà examples, e mostrano immediatamente il payload mock agli sviluppatori. Sanno esattamente cosa inviare, e il tuo codice Python rimane l'unica source of truth. La vera potenza della generazione di schema di Pydantic è che qualsiasi tool esterno creato per l'ecosistema JSON Schema può consumare immediatamente le tue regole di validazione Python senza integrazioni custom. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. Pydantic: Data Validation, episodio 16 di 20. I model standard presuppongono che il tuo payload JSON in ingresso sia un object mappato con chiavi e valori. Ma cosa succede quando un endpoint deve accettare direttamente un array top-level, o semplicemente una string standalone, senza doverla racchiudere in un dictionary? È proprio questo che RootModel: Quando il tuo payload non è un dictionary è progettato per gestire. Quando usi un base model standard, Pydantic mappa gli attributi della tua classe alle chiavi JSON. Se invii a uno standard model una raw list, come un array JSON di numeri, la validazione fallisce. Si aspetta una struttura a dictionary. Per aggirare questo problema, gli sviluppatori spesso costringono il client a modificare il payload. Creano una dummy key, magari chiamata items, e racchiudono l'array in un object. Finisci per stravolgere il design della tua API solo per far felice la tua libreria di validazione. RootModel elimina questa frizione. È un model speciale di Pydantic, progettato specificamente per i payload in cui la struttura più esterna è una list, una tuple, o un tipo primitivo come un integer o una string. Prendi ad esempio un endpoint di bulk-delete. Vuoi che il client invii un raw JSON array contenente degli user ID di tipo integer, nient'altro. Per gestirlo, importi RootModel da Pydantic. Definisci una nuova classe, magari chiamata UserIdList, e la fai ereditare da RootModel. Parametrizzi questa ereditarietà con una list di integer. Quando il raw JSON array arriva al server, lo passi direttamente al metodo model validate sulla tua classe UserIdList. Pydantic accetta l'array top-level in modo nativo. Itera sul payload, si assicura che ogni singolo item sia un integer valido, e restituisce un'istanza del model completamente validata. Ecco il punto chiave. Anche se valida una flat list, un RootModel fornisce esattamente la stessa interfaccia di un model normale. Hai ancora accesso ai metodi standard. Puoi chiamare model dump per convertire i dati di nuovo in object Python, oppure model dump json per generare una raw string. Poiché non ci sono campi con nome nel tuo payload, ti serve un modo per accedere ai dati una volta validati. Pydantic memorizza i dati parsati in un singolo attributo chiamato esattamente root. Se vuoi fare un loop su quegli user ID validati, ti basta iterare sull'attributo root nella tua istanza del model. Questo meccanismo non è limitato alle list. Puoi definire un RootModel per una singola string o un integer. Se ricevi un payload string standalone ma devi passarlo attraverso controlli rigorosi sulla lunghezza o pattern matching, definirlo come un RootModel di tipo string ti permette di allegare quelle regole di validazione in modo nativo. I dati rimangono una semplice string nel payload, ma ottengono la protezione completa del motore di validazione. Ogni volta che ti ritrovi a inventare una dictionary key solo perché Pydantic abbia qualcosa da parsare, stai usando il tool sbagliato. Usa RootModel per adattare il tuo validation layer al tuo API contract, anziché alterare il tuo API contract per soddisfare il tuo validation layer. Grazie per l'ascolto. Un saluto a tutti.

Ciao, sono Alex di DEV STORIES DOT EU. Pydantic: Data Validation, episodio 17 di 20. Hai una codebase enorme costruita interamente sulle dataclass standard di Python e ti rendi conto di aver disperatamente bisogno di validazione a runtime. Potresti pensare di dover riscrivere tutto per ereditare da un BaseModel. Non è così. Oggi mettiamo a confronto le dataclass standard con le dataclass di Pydantic. La standard library di Python fornisce un decoratore dataclass che è eccellente per ridurre il boilerplate. Scrive per te i metodi di inizializzazione, rappresentazione e uguaglianza. Tuttavia, si fida ciecamente dei tuoi input. Se dichiari un attributo age come integer e gli passi una string, la dataclass standard accetta semplicemente la string. Fornisce type hint per l'analisi statica, ma offre zero sicurezza a runtime. Pydantic risolve questo problema con il suo decoratore dataclass. È progettato specificamente come drop-in replacement per la versione della standard library. Mantieni esattamente la stessa struttura della classe. Non devi aggiungere alcuna base class. Ti basta modificare l'import per prendere il decoratore dal modulo pydantic dot dataclasses anziché dalla standard library. Considera quella codebase legacy basata sulle dataclass standard. Trovi una dataclass che gestisce un oggetto di configurazione. Sostituisci il decoratore standard con il decoratore di Pydantic. All'istante, ogni volta che la tua applicazione crea quell'oggetto di configurazione, Pydantic intercetta l'inizializzazione. Legge i tuoi type hint esistenti e li fa rispettare. Se viene passato un tipo non valido, Pydantic tenta di fare coercion. Se la coercion fallisce, lancia immediatamente un ValidationError. Ottieni assegnazioni rigorose e type-checked con zero modifiche strutturali al tuo inheritance tree. Ecco il punto chiave. Se entrambe le opzioni ti forniscono la validazione, devi capire la differenza tra una dataclass di Pydantic e un BaseModel standard. Gestiscono i dati sottostanti in modo diverso. Un BaseModel è fondamentalmente costruito attorno al parsing di dizionari e fornisce un'ampia gamma di metodi built-in per l'esportazione dei dati. Una dataclass di Pydantic rimane essenzialmente una classe Python standard, mantenendo il suo tradizionale memory footprint e il suo comportamento. Proprio perché rimane una classe standard, il modo in cui Pydantic applica la validazione cambia. Quando istanzi una dataclass di Pydantic, gli argomenti vengono copiati. I dati passano attraverso il validation engine principale di Pydantic, che fa il parsing e costruisce nuovi oggetti per corrispondere ai tuoi type hint. Non si limita a fare riferimento agli input mutabili originali che hai fornito. Se passi una list a una dataclass di Pydantic, il validator la elabora, valida gli elementi interni e assegna una list completamente nuova all'istanza. La list di input originale e l'attributo sulla tua dataclass non sono più lo stesso oggetto in memoria. Questo comportamento di copia garantisce che i tuoi dati aderiscano rigorosamente allo schema senza mutare le variabili di input originali. L'utilità principale della dataclass di Pydantic è quella di colmare il divario tra i paradigmi standard di Python e una validazione rigorosa. Se hai bisogno di un migration path pulito per del codice legacy che utilizza già le dataclass standard, ti basta sostituire il decoratore per ottenere una type safety immediata, preservando al contempo tutta la semantica della tua classe esistente. Se ti piace il podcast e vuoi contribuire a supportare lo show, puoi cercare DevStoriesEU su Patreon. Questo è tutto per questo episodio. Grazie per l'ascolto e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Pydantic: Data Validation, episodio 18 di 20. Di default, Pydantic ignora silenziosamente qualsiasi key JSON extra che gli invii. In un'API rigorosa, accettare dati sconosciuti senza alcun avviso è un enorme rischio per la sicurezza. Per risolvere questo problema, devi fare il fine-tuning della configurazione del model. Per cambiare il comportamento globale di un model, definisci un attributo di classe chiamato model config. Gli assegni un ConfigDict, che è un dictionary tipizzato importato direttamente da Pydantic. Metti questa assegnazione direttamente dentro il tuo model, insieme alle definizioni dei tuoi field. Dato che ConfigDict è tipizzato, il tuo code editor rileverà eventuali errori di battitura se provi a passare un'opzione di configurazione non valida. Qualsiasi regola metti in questo dictionary determinerà come l'intero model fa il parsing, valida e salva i dati. Costruiamo un model di impostazioni di sicurezza rigorose per un'applicazione. Un client malevolo potrebbe inviare un payload JSON con field imprevisti, magari cercando di iniettare un admin flag o di sovrascrivere un parametro nascosto. Di default, Pydantic imposta il comportamento degli extra field su ignore. Legge i field che si aspetta, scarta silenziosamente tutti i dati sconosciuti e crea il model. Per chiudere questa falla, aggiungi il parametro extra al tuo ConfigDict e imposti il suo valore sulla string forbid. Ora, se un client invia una key inattesa, Pydantic lancia immediatamente un validation error. La richiesta fallisce su tutta la linea, rifiutando esplicitamente il payload non valido prima ancora che la tua application logic lo elabori. Questo gestisce il confine tra il mondo esterno e il tuo sistema. Ma cosa succede all'interno del tuo sistema dopo che il model è stato creato? Pydantic normalmente valida i dati solo durante l'inizializzazione. Se un altro sviluppatore scrive del codice che modifica un attributo su un'istanza del model esistente in un secondo momento, Pydantic non interviene. Potresti accidentalmente assegnare una raw string a un integer field, e il model la accetterebbe. Per evitare questo, puoi impostare validate assignment a true all'interno del tuo ConfigDict. Con questa opzione abilitata, ogni volta che un attributo viene modificato in memoria, Pydantic intercetta la modifica ed esegue esattamente la stessa validation logic che usa durante la creazione. A volte, anche validare le mutazioni è troppo permissivo per le configurazioni di sicurezza. Potresti volere la garanzia assoluta che le impostazioni non possano essere modificate in memoria da nessuna parte del tuo codice una volta superato il controllo iniziale. È qui che la cosa si fa interessante. Puoi impostare il parametro frozen a true nella configurazione del tuo model. Questo rende l'intera istanza del model immutabile. Se una qualsiasi funzione a valle tenta di aggiornare un field, Pydantic lancia un errore. Un frozen model si comporta esattamente come una tuple Python. Dato che non può cambiare, un frozen model è completamente sicuro da condividere tra diverse parti della tua applicazione, e può persino essere usato in modo sicuro come key in un dictionary Python o in una in-memory cache. Combinando queste opzioni di configurazione all'interno del tuo ConfigDict, trasformi un model da un data parser flessibile a un confine assoluto e inflessibile. Questo è tutto per questo episodio. Grazie per aver ascoltato, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Pydantic: Data Validation, episodio 19 di 20. Smettila di estrarre string dal sistema operativo e incrociare le dita sperando che vengano castate correttamente a un integer. Probabilmente hai scritto decine di file di utility che wrappano le chiamate standard alle variabili d'ambiente, solo per evitare che un valore di configurazione mancante mandi in crash la tua applicazione a runtime. L'Application Configuration con Pydantic Settings sostituisce tutto questo boilerplate. Mentre Pydantic standard gestisce la data validation generale, gestire le variabili d'ambiente richiede l'installazione del package separato pydantic-settings. Questo package fornisce una classe specifica chiamata BaseSettings. Invece di recuperare manualmente le variabili e scrivere logica di parsing custom, dichiari una classe che eredita da BaseSettings. Definisci i tuoi field di configurazione esattamente come un model Pydantic standard, completo di type hint Python e valori di default. Quando istanzi questa classe, Pydantic legge automaticamente le variabili d'ambiente di sistema. Mappa i nomi delle variabili agli attributi della tua classe, in modo case-insensitive di default. Se hai definito un field timeout del database come integer, e la variabile d'ambiente fornisce una string, Pydantic converte quella string in un vero e proprio oggetto integer. Se la variabile d'ambiente contiene testo arbitrario anziché un numero, Pydantic solleva un chiaro validation error immediatamente allo startup dell'applicazione. Il tuo programma va in fail fast, anziché crashare in modo imprevedibile più tardi durante una chiamata attiva al database. In ambienti più grandi, i nomi delle variabili globali spesso vanno in collisione. Potresti avere più servizi in esecuzione sullo stesso host, tutti alla ricerca di una variabile chiamata semplicemente database URL. BaseSettings risolve questo problema permettendoti di definire un environment prefix nella configurazione del model. Se imposti il prefisso su app underscore, Pydantic smette di cercare match esatti con i nomi dei field. Invece, per popolare un field chiamato database URL, punta specificamente alla variabile d'ambiente app underscore database URL. Il codice della tua applicazione Python accede comunque alla property semplicemente come database URL, nascondendo completamente il prefisso del sistema operativo alla tua business logic. Ecco il punto chiave. Non devi appiattire i tuoi oggetti Python solo per leggere le variabili d'ambiente. La configurazione spesso diventa complessa, richiedendo strutture dati nested. Potresti avere una classe settings principale che include un sub-model dedicato per i settings del database, e un altro per il logging. Pydantic supporta la risoluzione di queste strutture nested usando la convenzione del double underscore. Se la tua classe settings principale ha un field chiamato database, che a sua volta punta a un model contenente un field timeout, Pydantic cercherà una variabile d'ambiente chiamata database double underscore timeout. Se stai usando un prefisso, naturalmente antepone anche quello, risultando in qualcosa come app underscore database double underscore timeout. Questo meccanismo ti permette di mantenere oggetti di configurazione gerarchici e strettamente tipizzati nel tuo source code, mappandoli comunque in modo pulito a variabili d'ambiente standard e flat. Il vero valore di BaseSettings non è solo eliminare il codice boilerplate, ma garantire che, se la tua applicazione si avvia con successo, il suo intero stato di configurazione sia completamente presente, esplicitamente tipizzato e totalmente sicuro da consumare. Grazie per l'ascolto, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. Pydantic: Data Validation, episodio 20 di 20. Importi una libreria rigida e non documentata da un altro team, e devi far passare i suoi oggetti attraverso la tua rigorosa pipeline di validazione. L'oggetto non ha la minima idea di cosa sia Pydantic, e non puoi toccare il suo source code. Quando le annotation e i semplici validator non bastano, devi parlare direttamente con l'engine, e questo significa aprire il cofano per scrivere dei core schema custom. Normalmente, Pydantic capisce come validare i tuoi dati leggendo i type hint. Quando gli passi un oggetto alieno, sbatte contro un muro. Per risolvere questo problema, definisci un metodo chiamato dunder get pydantic core schema. Questo metodo fa da layer di traduzione diretta. Bypassa i wrapper Python di alto livello e invia le istruzioni direttamente a Pydantic Core, l'engine Rust sottostante che gestisce la vera e propria logica di validazione. Quando implementi questo metodo, riceve il source type e un handler. L'handler funziona esattamente come un middleware in un web framework. Non devi scrivere l'intero validation schema da zero. Puoi chiedere all'handler di generare lo schema di default per un tipo specifico, e poi wrappare la tua logica custom attorno a quell'output. Prendi come esempio il wrapper della connessione al database legacy. Supponi che l'unico modo per inizializzare questo oggetto sia passargli un intero specifico, come un connection ID. Vuoi che Pydantic accetti un intero da una richiesta API, lo validi e ti restituisca l'oggetto di connessione completamente istanziato. Dato che non puoi modificare direttamente la classe legacy, definisci un custom type usando le annotation di Python. All'interno di quell'annotation, fornisci il tuo metodo core schema custom. Ecco il punto chiave. Invece di scrivere dizionari raw, usi il modulo core schema di Pydantic, che fornisce delle helper function per costruire queste strutture in modo sicuro. Per prima cosa, chiedi all'handler di creare uno schema standard per gli interi. Successivamente, costruisci un chain schema. Istruisci l'engine a eseguire prima la validazione standard per gli interi. Se l'input è effettivamente un intero, l'engine lo passa a una funzione Python custom che hai fornito. Questa funzione prende il connection ID, inizializza il wrapper del database legacy e restituisce l'oggetto. Infine, aggiungi un instance check schema alla chain, assicurandoti che l'output finale sia esattamente la classe legacy che ti aspetti. È qui che la cosa si fa interessante. Restituisci questa struttura annidata a Pydantic. Sotto il cofano, Pydantic prende queste definizioni di dizionari annidati e le compila in un execution graph nativo in Rust. Hai programmato l'engine Rust da Python, dicendogli passo dopo passo come ingerire un intero raw, validarlo e costruire in modo sicuro un oggetto alieno alla massima velocità. Questo rappresenta il livello più basso in assoluto di integrazione offerto da Pydantic, garantendoti il controllo totale sul validation tree senza sacrificare le performance. Dato che questo è il nostro ultimo episodio, ti incoraggio vivamente a tuffarti nella documentazione ufficiale di Pydantic e a provare a costruire un core schema custom hands-on. È il modo migliore per consolidare come pensa realmente l'engine. Puoi anche visitare dev stories dot eu per suggerire argomenti che vorresti venissero trattati nelle serie future. Questo è tutto per oggi. Grazie per l'ascolto, vai a costruire qualcosa di fantastico.