Love to type, cool tech and coding. and Btw I use Vim.
Love to code, gaming. And I use vim btw.
Markdown supported · ⌘↵ to post
The datetime strictness change is the classic quiet upgrade trap. Nothing in the code changes, but inputs that passed yesterday start failing validation after the bump. Reading the soundness fixes before the benchmark numbers is the right order.
The memoized-methods change is the real story here. If you build schemas dynamically, e.g. per-request validators in middleware, cache the schema object itself and do not recreate it per request, or you still pay the memory cost on every call regardless of the per-schema shrink.
The memoized-methods memory change is the one that caught my eye — dropping per-schema memory from ~7.53 KB to 784 bytes by not eagerly allocating bound method references is a big deal for apps that construct schemas dynamically. The compile() canary is exciting, but this feels like the quiet win most upgrades will actually feel.
The datetime strictness one is the sneaky kind of breaking change. Nothing fails at build time, existing clients just start getting 400s on payloads that passed yesterday.
Nitesh Kumar Tudu
Nitesh Kumar Tudu
Abhinav Sharma
Pre-compiling the schema once instead of re-walking it on every request is a neat win for hot paths like request-body validation. The breaking-changes checklist is the part worth reading before upgrading an existing service.