Revisiting PEP 505

This usage described by @guido looks very much common in “modern” web development, or scripting against services that expose an API (e.g. software integrations/automations).

It has been natural for the applications I’ve worked on themselves to develop a domain model that is more complex. Objects tend to have optional fields to handle all sorts of cases or usages, and they tend to layer into aggregates. You end up with deeply nested structures with optionality at any possible level. Because it represents the complexity of the domain.

That may not be the case in scientific computing, training a machine learning model, or writing a micro service to get the result of an algorithm. But working with web applications, sure is.

Given that it is in the model, it is not about parsing/validating. Not all fields will be present. This is how many major APIs models work, and we’re not going to change that. So it’s beyond whether to use pydantic or not.

I know no package that provide None-awareness like proposed and static type validation at the same time. If b is not an attribute of A, then I should get a static type error for A()?.b. If such a package exists, I could use it.

I could “just use typescript”. Unfortunately, some thing do work better with Python (notably ML), so I am stuck with it, and have to suck it up. For now?

5 Likes