Nuno Bispo (aka Developer Service)

`model_dump()` is not just for serialization. It's for control. Most developers discover `model_dump()` when they need to send a Pydantic model to an API or store it in a database. Convert to dict, done. But it does a lot more than that - and the options are worth knowing. `exclude` strips fields you never want to expose. `include` lets you whitelist exactly what goes out. `exclude_none` and `exclude_unset` clean up sparse models before serialization. `mode="json"` ensures types like datetime and UUID are serialized correctly without manual conversion. Together, these give you precise control over what leaves your model - without creating a separate response class for every endpoint. One model. Multiple views of the same data. The logic stays in one place, and you stop copying fields between classes just to hide or reshape them for different consumers. That's `model_dump()` doing real work - not just converting a model to a dict, but enforcing what each caller is allowed to see. Practical Pydantic covers this and other serialization patterns for real production systems. leanpub.com/practical-pydant… Control what goes out. Not just what comes in. #Python #Pydantic #BackendDevelopment #SoftwareDevelopment #PythonDeveloper

Pydantic is helpful by default. Sometimes too helpful. When you pass "42" into an int field, Pydantic doesn't complain, it just converts it. String becomes integer. No error. No warning. That's type coercion, and it's on by default. For many use cases, it's exactly what you want. Parsing a CSV, reading query parameters, handling form data, coercion saves you a lot of manual conversion. But in some systems, silent conversion is the last thing you want. If your internal services are passing "42" where they should be passing 42, that's a bug, not a feature. Coercion hides it. Strict mode surfaces it. Now the model refuses to guess. You get an error immediately, at the boundary, with a clear message. The contract is enforced, not worked around. Strict mode isn't the right default for every project. But knowing it exists, and when to reach for it, is what separates a model that accepts data from one that actually validates it. 👉 leanpub.com/practical-pydant… Helpful by default. Strict when it matters.

Your app has secrets. Don't scatter them across the codebase. Most Python projects manage configuration with raw os.getenv() calls, which are sometimes sprinkled across files, untyped, unvalidated. You only discover a missing variable when the app crashes in production. BaseSettings from Pydantic fixes this at the root. One class. That's your entire configuration layer. Pydantic reads from environment variables automatically, coerces types, and raises a clear error at startup if anything required is missing. And because it's just a Pydantic model, you can add validators, nested settings, and per-environment overrides - all in the same place. One import. One instance. One place to look when something's misconfigured. This pattern alone justifies adding pydantic-settings to any serious Python project. It's covered in depth in Practical Pydantic, along with patterns for managing settings across environments, secrets, and production services. 👉 leanpub.com/practical-pydant… Configure once. Trust everywhere. #Python #Pydantic #Settings #Security

Don't flatten what naturally has structure. It's tempting to model everything in a single class. Easy to write, easy to read, at least until your data grows. This is where most codebases start, with just one model. But with model composition, each model has a single responsibility. And Pydantic handles nested validation automatically. Structure your models the way your domain is actually structured. The code gets cleaner, the errors get clearer, and reuse becomes obvious. This and other real-world modelling patterns are covered in Practical Pydantic: 👉 leanpub.com/practical-pydant… Model your domain. Not just your data. #Python #Pydantic #Data #Models #Patterns

Your model shouldn't just store data. It should understand it. Most developers use Pydantic for validation. Fewer use it to derive meaning from data. Here's a pattern worth adding to your toolkit, computed fields. No manual calculation. No risk of forgetting to update a field. No inconsistent state. order.total is always correct, because it can't be anything else. This matters more than it looks. Every time you store a derived value separately, you create a sync problem. What happens when quantity changes but total doesn't? Bugs that are challenging to trace and easy to introduce. Computed fields eliminate that class of problem entirely. The model owns the logic. Callers just consume the result. That's what Practical Pydantic is about, designing models that carry business logic, not just data shapes. 👉 leanpub.com/practical-pydant… Stop storing what you can compute. #Python #Pydantic #Data #Computed

Real-world data is messy. Your models shouldn't be. CSV files, external APIs, user input - they all deliver junk like "N/A", "unknown", or empty strings. Technically valid. Logically useless. Instead of scattering cleanup logic across your codebase, normalize once - at the model level. Downstream code stops worrying about edge cases. Business logic gets simpler. That's the real value of structured models: a hard boundary between messy input and reliable internal state. This pattern - and dozens like it - are covered in Practical Pydantic. leanpub.com/practical-pydant… Clean code starts with clean data. #Python #Pydantic #CleanData

If your validation lives outside your models, it will eventually drift. This is one of the most common design issues I see in Python codebases. Validation starts in the API layer. Then some logic gets added in a service. Then a background worker bypasses it. Now you have three different interpretations of what “valid data” means. A cleaner approach is to encode rules directly into your data models. For example, using strict types in Pydantic when correctness matters. Why this matters: - "1" will not silently become 1 - "true" will not quietly convert to True Incorrect data fails immediately. In many systems, silent coercion is more dangerous than a loud failure. Strict validation forces data producers to behave correctly, instead of letting your system “guess” what they meant. More practical examples at: leanpub.com/practical-pydant… Reliable systems are rarely accidental. They’re designed that way. #Python #Pydantic #ValidData #Data #Validations

The difference between a beginner and an advanced Python developer often isn’t syntax. It’s understanding the fundamentals deeply. One of those fundamentals? Variable scope. I’ve reviewed Python code where everything looked correct at first glance, yet the behavior was inconsistent. The root cause was almost always a misunderstanding of how Python handles local, global, and nonlocal variables. Master this concept once, and you’ll: • Debug faster • Write more predictable code • Avoid subtle side effects I wrote a practical, no-fluff guide to help you truly understand how Python variable scope works: 👉 python-variable-scope.develo… #Python #SoftwareDevelopment #LearnPython #DeveloperSkills

Data validation is not input sanitation. It’s system design. In many Python applications, validation is treated as an afterthought: - A few if checks in a route - Some manual casting in a service layer - A regex somewhere for email validation The result? Rules are duplicated. Logic drifts. Edge cases slip through. A better approach is to treat your data models as the single source of truth. For example, cross-field validation should live at the model level, not in controllers or business services. What this achieves: • Validation is centralized • Business rules are explicit • Every consumer of the model gets the same guarantees • Downstream logic becomes simpler This pattern, designing models that actively protect your system, is a core theme in Practical Pydantic: leanpub.com/practical-pydant… #Python #Data #Validation

Business rules don’t belong in if statements scattered across your app. They belong next to the data. Why this matters: - Your rules are enforced everywhere the model is used Invalid data fails early (and loudly) - Your downstream code becomes simpler and safer This is the kind of practical, production-focused pattern that Practical Pydantic focuses on throughout the book, real-world validation. If you’re building APIs, FastAPI services, or data pipelines and want more confidence in your data layer, it’s worth a read. leanpub.com/practical-pydant… Clean data isn’t a “nice to have”. It’s the foundation of reliable software. #Python #Pydantic #CleanData #Validations