The usual advice is to lean into Python’s dynamic nature. That flexibility is also what takes projects down in production. I have lost whole days to data pipelines where a stray string broke an arithmetic operation three layers deep, because one function got handed something it never expected.
Python type annotations are a contract, not decoration for your IDE. In a machine learning model or any involved data workflow, the annotation is a promise about which values an object can hold. On a long-running pipeline, catching a mismatch while you write the code, instead of four hours into a run, decides whether the job ships at all.
Why dynamic typing is a liability in data science
By default Python checks no types at all. That suits prototyping in a notebook and hurts in production. A mismatched argument tends to surface as an exception far downstream, or it produces plausible nonsense that quietly corrupts the dataset. PEP 484, in Python 3.5, exists to close that gap.
A data scaling function makes it obvious:
def bbioon_scale_data(x):
# This works if x is a float, but returns junk if x is a string
return x * 2
print(bbioon_scale_data("123")) # Output: "123123" - No error, just wrong data.The same function with Python type annotations, checked by mypy or pyright:
def bbioon_scale_data(x: float) -> float:
return x * 2
# A static checker now flags this immediately:
# bbioon_scale_data("123") # Error: Expected float, got strBuilding structure with TypedDict and Literals
Dictionaries do most of the work in a data project, and a raw dict carries no schema, which is where the risk sits. TypedDict (PEP 589) lets you declare that schema without paying for a full class. It earns its keep on JSON API responses and CSV rows.
Literal types pin a value to a fixed set of categories, so a typo in an aggregation method or a model name fails at check time rather than silently. Wiring these into your Python development workflow saves days of refactoring later on.
from typing import TypedDict, Literal
class SensorData(TypedDict):
timestamp: float
reading: float
unit: Literal["celsius", "fahrenheit"]
def process_sensor(data: SensorData) -> float:
return data["reading"] * 1.8 + 32Handling uncertainty with union types
Real data is messy. Sensors fail and APIs return None. From Python 3.10 on, Python type annotations express that with the pipe syntax (|), and the type checker then refuses to let you operate on the value until you have handled the None branch. That is how you keep TypeError: unsupported operand type out of production.
If this kind of Python work is eating your dev hours, I can take it on. I have been doing WordPress, PHP and Python integrations since the early days, and I build typed systems that hold up overnight without paging anyone.
Where to start
You do not have to annotate the whole codebase at once. Start with the functions that touch external data, since that is where the bad values come from. Reach for Protocol when you need structural typing and some flexibility, and TypeVar when a generic has to preserve the shape it was given. The habit takes a while to build, and it mostly comes down to declaring what a variable is instead of working it out from a stack trace later.
