
Hi Erik, sorry for the late reply, somehow the task of replying to your email drifted into the unsorted set of background tasks I need to do someday, and only bubbled to the top by chance.
Since the parameters don’t need to be provided when creating a `Settings` object, aren’t these fields *not* required? I saw a comment on the issue suggesting adding default values as a workaround. [1] Why doesn’t that work? I didn’t see any responses to that idea.
Providing a default value wouldn't solve the problem - when creating the Settings class you want to enforce that the value IS required albeit via an environment variable or an argument when initialising the class .e.g. with a class ```python class Settings(BaseSettings): db_password: str ``` You could either create your settings instance via ```python settings = Settings(db_password='foobar') ``` or via, ```bash export DB_PASSWORD=foobar ``` ```python settings = Settings() ``` But either way, the point is that the field is "required", just that it's not necessarily required as an argument. I don't expect detaclass transforms to understand this, just to provide an escape hatch so I can stop using them when the behaviour is too complex/easotetic to remotely match dataclass behaviour. Alternatively, could you refactor your class hierarchy and relocate the
`dataclass_transform` decorator so `BaseSettings` and `BaseModel` still share code, but BaseSettings’s branch of the hierarchy was not decorated with `dataclass_transform`?
I think that's what we'll end up doing in a future major release. But it'll be ugly, and probably involve duplicated code. I still think there's a real need for a way to disable dataclass transforms on some subclasses, both in pydantic and many other usage scenarios. Thanks, Samuel -- Samuel Colvin On Wed, 6 Apr 2022 at 16:46, Erik De Bonte <Erik.DeBonte@microsoft.com> wrote:
Hi Samuel,
Because of this you can legitimately use "settings = Settings()" even when your Settings class has required fields - because they're filled from env variables.
Since the parameters don’t need to be provided when creating a `Settings` object, aren’t these fields **not** required? I saw a comment on the issue suggesting adding default values as a workaround. [1] Why doesn’t that work? I didn’t see any responses to that idea.
Alternatively, could you refactor your class hierarchy and relocate the `dataclass_transform` decorator so `BaseSettings` and `BaseModel` still share code, but BaseSettings’s branch of the hierarchy was not decorated with `dataclass_transform`?
-Erik
[1] https://github.com/samuelcolvin/pydantic/issues/3753#issuecomment-1060850457