The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Liz arrived at PyBay about an hour before her scheduled talk, ready to give an expanded version of a Pydantic presentation she had delivered at smaller meetups. But an unread email had asked speakers to check in two hours before their slot. By the time she reached the check-in table, her speaking slot had gone to an alternate. Her story links that painful conference mistake to the technical idea her talk was meant to explain: how validation can catch bad input before it causes trouble.
What happened when Liz missed the speaker check-in
Liz had spoken at PyBay before and was excited to present a longer version of her Pydantic talk. She had prepared slides and a Jupyter notebook, rehearsed, and planned to arrive about an hour before her slot. She missed an email instructing speakers to check in two hours ahead. At the conference, she learned that an alternate had already received her slot.
She later found the email unread in her inbox and noticed a missed call. Liz believed unreliable phone signal while crossing the Bay Bridge contributed to her missing the call. Those details, including the organizers’ policy and the decision to reassign the slot, come from Liz’s recollection rather than an independently published conference record. She says the organizers had adopted the policy after earlier issues and that she understood why they enforced it.
A friend was with her, and an organizer offered comfort. Rather than leave, Liz stayed, attended another talk, and sat with her disappointment and embarrassment. She also reflected on the kindness she received and on the need to offer herself some of the same compassion. The mistake was consequential, but it did not erase the preparation she had put into the talk or the people who supported her.
#1 Best Overall
What the Pydantic talk was going to explain
Liz titled her talk “Seeking validation.” Its central point was that Pydantic is not limited to checking whether a value already has the desired Python type. In the “parse it” approach she described, a model can accept an input in another form and convert it when possible. For example, in lax mode, the string "14" can be parsed as an integer. If a value cannot be parsed or otherwise satisfies the model’s constraints, Pydantic can raise a ValidationError.
Liz attributes the idea “don’t just validate, parse it” to software engineer Alexis King. The phrase captures the distinction: validation may involve transforming acceptable input into the model’s expected form, not merely rejecting everything that does not arrive in that form.
From model definition to validation result
The post’s examples define a Pug model with constrained fields, then show conversion of a string to an integer and structured errors for an invalid name and an unparseable age. Pydantic uses Python-facing model definitions and type annotations; the post explains that it generates a core schema and uses pydantic-core for validation and serialization. Liz describes that engine as implemented in Rust, but the article does not establish a benchmark or quantify its speed.
Structured validation errors are useful because they can identify which field failed and why, rather than leaving an application to discover a malformed value later in its workflow. The model therefore acts as a defined boundary between incoming data and code that expects particular fields and types.
Why validate before an API request?
Liz’s practical example comes from the Vonage Python SDK and Verify service. The post describes Pydantic models catching invalid input before an API request is made. That can make the failure easier to understand and avoid sending a request that was malformed from the outset. It is an example of where input validation belongs in an application, not a guarantee that every error can be caught locally: remote services can still reject requests for reasons beyond the model’s checks.
The post notes that its sample tests make real API calls and may incur costs. Treat them as live-service code, not as harmless local demonstrations; inspect the current test code and service behavior before running anything that could contact an API.
Rank #4
The connection between the missed talk and its subject
Liz’s account gives the technical topic an unexpectedly fitting illustration. A prepared speaker can still miss an important input—in this case, the check-in instructions—and the conference’s process responds by assigning the slot to someone else. In the talk, a model similarly defines what input is acceptable and what happens when it is not. The analogy is not exact: a person is not a data object, and an organizer’s decision is not a software validation result. But both stories turn on clear expectations, a failure at a boundary, and what happens next.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchLiz’s response was to stay, accept support, and reflect rather than let one missed email define the entire conference. As she put it, “I guess that’s actually a really meta demonstration of Pydantic.”
Read Liz’s full account
The original first-person post, including its code examples and conference recollection, is available on DEV Community.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
