Sasan Jacob Rasti

I agree. Splitting the flags would improve usability a lot. However, since nans can not ever conform to numerical constraints they don't matter when defining them: Either I expect missing/false...

I don't understand the problem for `pydantic` support. Can't we just assume that every class that has `pydantic.BaseModel` as a base class needs to have the types of their class...

nvm, my brain left me there for a bit. > Does that make sense @sasanjac? ~~No, because `Foo.mro()` still contains `BaseModel`.~~

> nvm, my brain left me there for a bit. > > > Does that make sense @sasanjac? > > ~No, because `Foo.mro()` still contains `BaseModel`.~ But can't we then...

Yeah I totally forgot about that. But why don't leave it up to the user to specify all `pydantic` base classes in the config file? I mean with the default...

Because with the default config they will move all typing imports into the `TYPE_CHECKING` block. For me it just seems the most straightforward way to have something like `type-checking-pydantic-enabled-baseclasses` instead...

Ok, now I only have to learn rust 🙈

After the removal of `unique_items` in v2 and [this issue](https://github.com/pydantic/pydantic/issues/1090) there is no way in v2 to specify a unique array when serializing the model.

The instance that generates and verifies the lp files should round the values before saving. The tests can then check against these rounded values.