{"title":"Exercise: Type Hints and Pydantic","description":null,"content":"# Exercise 1: Validate an LLM Config with Pydantic\n\nDefine a Pydantic model that validates the configuration for an LLM request, then confirm it accepts valid input and rejects invalid input with a clear error.\n\nGeneration parameters come from config files, environment variables, and user input, all of which can be wrong. A model with `temperature = 5.0` or `max_tokens = -10` fails at the API, often after you have already spent time and tokens building the request. Validating the config up front turns a late, confusing API error into an early, specific one.\n\n### Requirements\n\n- Define an `LLMConfig` model with these fields and rules:\n - `model`: a non-empty string.\n - `temperature`: a float between `0.0` and `2.0` inclusive, default `0.7`.\n - `max_tokens`: an integer between `1` and `128000` inclusive, default `1024`.\n- Construct a valid config and print it.\n- Attempt to construct a config with `temperature = 5.0`, catch the validation error, and print it.\n\n\n**main.py**\n\n```python\nfrom pydantic import BaseModel, Field\n\nclass LLMConfig(BaseModel):\n # TODO: declare model, temperature, and max_tokens with their constraints\n pass\n\n# TODO: construct a valid config and print it\n\n# TODO: construct an invalid config (temperature = 5.0),\n# catch the error, and print it\n```\n\n\n### Expected Output\n\nThe valid config prints its fields. The invalid one raises a validation error that names the offending field and the rule it broke.\n\n\n```plaintext\nmodel='openai/gpt-5.4-mini' temperature=0.7 max_tokens=1024\n1 validation error for LLMConfig\ntemperature\n Input should be less than or equal to 2 ...\n```\n\n\n### Solution\n\n\n**main.py**\n\n```python\nfrom pydantic import BaseModel, Field\n\nclass LLMConfig(BaseModel):\n model: str = Field(min_length=1, description=\"The model identifier.\")\n temperature: float = Field(default=0.7, ge=0.0, le=2.0)\n max_tokens: int = Field(default=1024, ge=1, le=128000)\n\n# Valid config: omitted fields fall back to their defaults\nconfig = LLMConfig(model=\"openai/gpt-5.4-mini\")\nprint(config)\n\n# Invalid config: temperature is above the allowed maximum\ntry:\n LLMConfig(model=\"openai/gpt-5.4-mini\", temperature=5.0)\nexcept Exception as error:\n print(error)\n```\n\n\n`Field` carries the constraints declaratively: `ge` and `le` set inclusive bounds, `min_length` rejects an empty model name, and `default` makes a field optional. Pydantic checks every rule when the model is constructed and raises a single error listing each field that failed, which is why the bad `temperature` is caught before the request is ever assembled.\n\n---\n\n# Exercise 2: Validate a Nested Chat Request\n\nReal request payloads are nested: a chat request holds a list of message objects, each with its own fields. Build a `ChatRequest` model that contains a list of `Message` models, and add a validator that rejects an empty message list or any message with blank content.\n\nNested models plus a field validator are how you enforce structure that a flat schema cannot, like \"the list must be non-empty and every item well-formed.\" Catching this before the request leaves your service turns a confusing downstream API error into a clear local one.\n\n### Requirements\n\n- Define a `Message` model (`role`, `content`) and a `ChatRequest` model holding `model` and `messages: list[Message]`.\n- Add a `field_validator` on `messages` that rejects an empty list and any message whose content is blank after stripping.\n- Build a valid request and print it, then build an invalid one and print the validation error.\n\n\n**main.py**\n\n```python\nfrom pydantic import BaseModel, field_validator\n\nclass Message(BaseModel):\n role: str\n content: str\n\nclass ChatRequest(BaseModel):\n model: str\n messages: list[Message]\n\n # TODO: add a field_validator on \"messages\" that rejects an empty list\n # and any message whose content is blank\n\n# TODO: build a valid ChatRequest from a list of message dicts and print it\n# TODO: build an invalid one (a message with empty content), catch the error, and print it\n```\n\n\n### Expected Output\n\nThe valid request prints its nested messages; the invalid one is rejected with a clear reason.\n\n\n```plaintext\nmodel='openai/gpt-5.4-mini' messages=[Message(role='system', content='Be concise.'), Message(role='user', content='Hi')]\n1 validation error for ChatRequest\nmessages\n Value error, message content must not be blank ...\n```\n\n\n### Solution\n\n\n**main.py**\n\n```python\nfrom pydantic import BaseModel, field_validator\n\nclass Message(BaseModel):\n role: str\n content: str\n\nclass ChatRequest(BaseModel):\n model: str\n messages: list[Message]\n\n @field_validator(\"messages\")\n @classmethod\n def messages_must_be_valid(cls, value):\n if not value:\n raise ValueError(\"messages must not be empty\")\n if any(not m.content.strip() for m in value):\n raise ValueError(\"message content must not be blank\")\n return value\n\nrequest = ChatRequest(\n model=\"openai/gpt-5.4-mini\",\n messages=[{\"role\": \"system\", \"content\": \"Be concise.\"}, {\"role\": \"user\", \"content\": \"Hi\"}],\n)\nprint(request)\n\ntry:\n ChatRequest(model=\"openai/gpt-5.4-mini\", messages=[{\"role\": \"user\", \"content\": \" \"}])\nexcept Exception as error:\n print(error)\n```\n\n\nDeclaring `messages: list[Message]` makes Pydantic validate and construct each item as a `Message`, so the nested structure is checked automatically. The `field_validator` adds the cross-item rules a type alone cannot express: non-empty list and no blank content. Together they guarantee that any `ChatRequest` your code builds is already well-formed, which is exactly the contract you want before serializing it to the API.","pageType":"ai-engineering"}

Get Premium