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
When a Union with only a single variant it tagged with a field as a discriminated union, a type error is thrown on defining the class. The below is a minimally reproducible example:
$ python repro.py
Traceback (most recent call last):
File "repro.py", line 10, in<module>
class RequestModel(BaseModel):
File "/home/tom/r/env/lib/python3.8/site-packages/pydantic/main.py", line 204, in __new__
fields[ann_name] = ModelField.infer(
File "/home/tom/r/env/lib/python3.8/site-packages/pydantic/fields.py", line 488, in infer
return cls(
File "/home/tom/r/env/lib/python3.8/site-packages/pydantic/fields.py", line 419, in __init__
self.prepare()
File "/home/tom/r/env/lib/python3.8/site-packages/pydantic/fields.py", line 534, in prepare
self._type_analysis()
File "/home/tom/r/env/lib/python3.8/site-packages/pydantic/fields.py", line 605, in _type_analysis
raise TypeError('`discriminator` can only be used with `Union` type')
TypeError: `discriminator` can only be used with `Union`type
The following code snippet works as intended. The only difference is I have introduced a second type in the discriminated union field. Note that simply repeating the existing type (such as Union[DataAModel, DataAModel]) still fails:
After some poking, it looks like within _type_analysis, self.discriminator_key is set on the model DataAModel, rather than the parent field, Union[DataAModel]. I'm guessing there is a simplification step somewhere where singleton unions are simplified to their child type, which is no longer accurate?
Happy to submit a PR if you can point me further in the right approach.
The text was updated successfully, but these errors were encountered:
Ah, that makes sense. I was about to start poking to see if the simplification was internal to pydantic or not, but if it's at a higher layer I'll give it up as a lost cause.
Would you accept a PR noting this as an edge case in the documentation/error message?
I suppose the workaround is to add a dummy second type into the union, or just to remove the discriminator until it is required.
For documentation forward compatibility, we were using openapi-schema-pydantic, which now collides with the discriminator Field property nicely. But that's not your problem! I'll file a bug over there now.
Checks
Bug
Output of
python -c "import pydantic.utils; print(pydantic.utils.version_info())"
:When a
Union
with only a single variant it tagged with a field as a discriminated union, a type error is thrown on defining the class. The below is a minimally reproducible example:produces
The following code snippet works as intended. The only difference is I have introduced a second type in the discriminated union field. Note that simply repeating the existing type (such as
Union[DataAModel, DataAModel]
) still fails:After some poking, it looks like within
_type_analysis
,self.discriminator_key
is set on the modelDataAModel
, rather than the parent field,Union[DataAModel]
. I'm guessing there is a simplification step somewhere where singleton unions are simplified to their child type, which is no longer accurate?Happy to submit a PR if you can point me further in the right approach.
The text was updated successfully, but these errors were encountered: