Originally posted by slafs July 29, 2023
This is a continuation of a topic introduced in #9709 (comment) as requested by @Kludex. I've chosen the "Show and tell" category as the (lack of) template seems better for this discussion.
In the original thread I've asked if there's a way to work with pydantic v1 while having v2 installed:
Pydantic v2 ships the latest version of v1 for easier migration, so the pattern is to work with v1 via things like from pydantic.v1 import BaseModel etc. while having v2 installed.
Currently, this approach doesn't seem to work with FastAPI 0.100.0 and the following snippet:
from fastapi import FastAPI
from pydantic.v1 import BaseModel
class Model(BaseModel):
foo: str = "foo"
bar: int = 2
app = FastAPI()
@app.get("/")
def root(model: Model) -> Model:
return model
produces the following error:
Traceback (most recent call last):
File ".../fiddles/fastapi_pydantic_v1_on_v2.py", line 15, in <module>
def root(model: Model) -> Model:
File ".../lib/python3.10/site-packages/fastapi/routing.py", line 706, in decorator
self.add_api_route(
File ".../lib/python3.10/site-packages/fastapi/routing.py", line 645, in add_api_route
route = route_class(
File ".../lib/python3.10/site-packages/fastapi/routing.py", line 448, in __init__
self.response_field = create_response_field(
File ".../lib/python3.10/site-packages/fastapi/utils.py", line 101, in create_response_field
raise fastapi.exceptions.FastAPIError(
fastapi.exceptions.FastAPIError: Invalid args for response field! Hint: check that <class '__main__.Model'> is a valid Pydantic field type. If you are using a return type annotation that is not a valid Pydantic field (e.g. Union[Response, dict, None]) you can disable generating the response model from the type annotation with the path operation decorator parameter response_model=None. Read more: https://fastapi.tiangolo.com/tutorial/response-model/
Switching from pydantic.v1 to just pydantic (v2) obviously works.
I'm seeing there's fastapi._compat module and PYDANTIC_V2 var, but I'm not sure if that's the right direction.
For reference, installed versions:
fastapi==0.100.0
pydantic==2.0.3
pydantic_core==2.3.0
Now... that being said, I'm not even sure if this would be helpful to anyone even if FastAPI did support it. My initial thought was that this would ease the migration, but the reality seems more complicated. E.g. models are used by other models and even Pydantic itself doesn't support mixing v1 and v2 together. So given that the cost of figuring out the plan for the gradual migration seems comparable with doing the whole migration at once (at least for us).
Maybe it would be useful if people commented on their intended use case and see if that's actually a feature that's needed/wanted.
fritzdj, AdrianB-sovo, dogukancagatay, Joymeuwu, yuriyward and 13 more
You can’t perform that action at this time.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4