BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//programme.europython.eu//europython-2026//talk//7VKQQM
BEGIN:VTIMEZONE
TZID:CET
BEGIN:STANDARD
DTSTART:20001029T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000326T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-europython-2026-7VKQQM@programme.europython.eu
DTSTART;TZID=CET:20260715T143000
DTEND;TZID=CET:20260715T150000
DESCRIPTION:Have you ever merged a config file\, applied an input that says
  "update only these fields"\, or handled an API payload\, only to overwrit
 e data because "missing"\, `None`\, and "unset" were treated as the same t
 hing?\n\nIn real-world projects\, "no value" has at least three meanings:\
 n\n- a missing key (the field is absent)\,\n- an explicit `None` (the valu
 e is present and intentionally null)\,\n- an unset input (the caller didn'
 t specify the field\, so you must not touch it).\n\nWhen we collapse these
  into `T | None` (a nullable type) or fall back to `dict[str\, Any]`\, typ
 e checking becomes noisy\, branching becomes fragile\, and refactors get r
 isky. Every field nullable\, every check defensive\, every change scary.\n
 \nThis is a practical talk about using typing to model and safely consume 
 real-world data with `TypedDict` and `dataclasses`\, not a typing tutorial
  or a framework pitch. We'll walk through one end-to-end example (payload 
 -> normalization -> domain model -> safe updates) with before/after code a
 nd focus on patterns you can apply immediately:\n\n- Use `Required` / `Not
 Required` to model missing keys instead of abusing `T | None`.\n- Use `T |
  None` only when `None` is a meaningful value.\n- Represent unset inputs w
 ith a sentinel pattern (starting from `UNSET = object()` and optionally ev
 olving to `typing_extensions.Sentinel`) so partial updates don't silently 
 overwrite data and the type checker can distinguish unset from `None`.\n- 
 Keep extraction code honest with type aliases\, `TypeIs`\, and (optionally
 ) small `match` cases for readability.\n\nAfter this session\, you'll be a
 ble to define stricter data models\, write safer extraction code\, and mak
 e schema changes less painful\, because your types will reflect what your 
 data actually means. This talk is for intermediate Python developers who a
 lready use type hints in production.
DTSTAMP:20260524T131129Z
LOCATION:Conference Hall Complex (S4)
SUMMARY:Beyond `Optional` in Real-World Projects: Missing\, `None`\, and Un
 set - Koudai Aono
URL:https://programme.europython.eu/europython-2026/talk/7VKQQM/
END:VEVENT
END:VCALENDAR
