You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The SettingsBaseModel, by default, only performs validation of fields directly fed to the constructor (see the configuration option, validate_all, in the link below). When model fields are not present, they are given a default value defined by the settings author. If the author fails to provide a default with the correct type, it will not be corrected, which can lead to inconsistencies downstream.
For example, if a GufeTokenizable has a field with a Settings object that doesn't adhere to its own schema, then the GufeKey reflects this inconsistency. Consider a scenario where a field's validator enforces a float, but an int was provided instead. If that GufeTokenizable is then translated to an intermediate format, such as a KeyedChain, the incorrectly typed integer value will also be translated. When converting the KeyedChain back into a GufeTokenizable, all models will be validated. The system will find an int for that field and cast it as a float. Although the recovered GufeTokenizable is now correctly validated, the GufeKey has changed between the original object and the new one, even though they functionally represent the same data.
Does it make sense to enforce this at the gufe level, or is watching out for this behavior the responsibility of the settings author?
Knowing that we will be moving to pydantic 2 (someday?) do you know if the behavior changes at all? I think validate_all=True seems right for our use case.
The
SettingsBaseModel
, by default, only performs validation of fields directly fed to the constructor (see the configuration option,validate_all
, in the link below). When model fields are not present, they are given a default value defined by the settings author. If the author fails to provide a default with the correct type, it will not be corrected, which can lead to inconsistencies downstream.For example, if a
GufeTokenizable
has a field with aSettings
object that doesn't adhere to its own schema, then theGufeKey
reflects this inconsistency. Consider a scenario where a field's validator enforces a float, but an int was provided instead. If thatGufeTokenizable
is then translated to an intermediate format, such as aKeyedChain
, the incorrectly typed integer value will also be translated. When converting theKeyedChain
back into aGufeTokenizable
, all models will be validated. The system will find an int for that field and cast it as a float. Although the recoveredGufeTokenizable
is now correctly validated, theGufeKey
has changed between the original object and the new one, even though they functionally represent the same data.Does it make sense to enforce this at the
gufe
level, or is watching out for this behavior the responsibility of the settings author?https://docs.pydantic.dev/1.10/usage/model_config/
The text was updated successfully, but these errors were encountered: