samuelcolvin / pydantic Public
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exclude with nested "__all__" does not work as expected #1579
Comments
|
your naming is very confusing But I think you're right. |
|
@samuelcolvin you are right. Here is a more non-confusing example I hope :D from typing import List
from pydantic import BaseModel
class Alpha(BaseModel):
id: int = 1
name: str = "Alpha"
class Beta(BaseModel):
alphas: List[Alpha]
class Model(BaseModel):
betas: List[Beta]
def test():
model = Model(
betas=[Beta(alphas=[Alpha(), Alpha(id=2)]), Beta(alphas=[Alpha(id=3)])]
)
assert model.dict() == {
"betas": [
{
"alphas": [
{"id": 1, "name": "Alpha"},
{"id": 2, "name": "Alpha"},
]
},
{"alphas": [{"id": 3, "name": "Alpha"}]},
]
}
assert model.dict(
exclude={
"betas": {
0: {"alphas": {"__all__": {"name"}}},
1: {"alphas": {"__all__": {"name"}}},
}
}
) == {
"betas": [{"alphas": [{"id": 1}, {"id": 2}]}, {"alphas": [{"id": 3}]}]
}
assert model.dict(
exclude={"betas": {"__all__": {"alphas": {"__all__": {"name"}}}}}
) == {
"betas": [{"alphas": [{"id": 1}, {"id": 2}]}, {"alphas": [{"id": 3}]}]
}Output using As I mentioned, the problem seems to occur when using |
above is working as expected but excludes entire option key for each entry in questions instead of excluding only correctAnswer key from each option |
Bug
Output of
python -c "import pydantic.utils; print(pydantic.utils.version_info())":As I was experimenting with
FastAPIandpydantic, I thought that it would be nice to useexcludein order to avoid some Schema duplication (or complex inheritances). Ultimately, I came across a weird bug when trying to use exclude on nested sequences. Below is a minimal example for reproducing the bug.Running the above function with
pytestthe output is:I inspected the codebase a little bit, and found out that the bug is produced because of how _normalize_indexes, as it assumes that when the
itemsis adictcontaining the__all__key, then the value is considered by default to be aset. So calling theupdate, information may be missed.I am not certain if my usage violates how the
__all__key should be used, but if this should have been correct, I can create a PR with a solution.The text was updated successfully, but these errors were encountered: