Unable to handle Pydantic BaseModel subclasses with custom init functions #8542
Comments
|
I do not think we can handle this case because |
|
@madkinsz as stated in the related PR: from my point of view you are placing assumptions on BaseModel and data classes for that matter, that do not hold up. I would argue this is the wrong approach to force the user to adopt your assumptions. If you need special handling of BaseModel you should probably use your own subclass and 'quote' all others automatically if they do not conform to your assumptions. I did not really have the time to understand why you need to instantiate a new model in the first place, due to a lack of time. But pydantic technically allows to bypass the init: class MyModel(BaseModel):
id: int
info: str = "Foo"
def __init__(self, id: int = 1, *, bar:str, **data) -> None:
"""My custom init!"""
print(bar)
super().__init__(id=id, **data)
m1 = MyModel(id=10, bar="baz") # prints "baz" because init is used
m2 = MyModel.construct(_fields_set=m1.__fields_set__, **m1.dict()) # skips init
assert m2.id == m1.id
assert m2.info == m1.infoAs a side note, in our case the init method does not allow all fields to be set. But the point is very much the same. |
|
@tharwan we resolve futures in models so you can pass models with deferred computation into downstream tasks and get concurrent execution. This is a large part of our value proposition. I do not think your described use of Pydantic is something I expect many of our users to encounter. Switching from We cannot change our behavior here easily as other users may be depending on it. |
|
@madkinsz From my point the best way then would be to have a custom pydantic Base that models need to be derived from that conforms to your assumptions about pydantic, as they are not true for pydantic models in general. |
|
@tharwan that would be a breaking change |
|
Here is a possible solution for you #8763 |
|
@madkinsz in our case the model is defined external to the prefect project, so this would not help much I think. This is also potentially the biggest drawback of the current state, that there might be objects that are pydantic models that the user does not even knows are pydantic models, because they are just part of some 3rd party package. |
|
Oh I see this a prefect setting not something attached to the model definition. That might help indeed, thanks. |
First check
Bug summary
Attempting to instantiate Pydantic Subclasses with custom init functions within a task or referencing the model within a task results in the following error
model_instance = typ( TypeError: MyModel.__init__() missing 1 required keyword-only argument: 'bar'running the same code in the example below with both tasks as functions completes successfully.Reproduction
Error
Versions
Additional context
No response
The text was updated successfully, but these errors were encountered: