Replies: 12 comments 1 reply
-
Is there a desired use case for this? I'm having a hard time imagining a concrete scenario where supporting bounded typevars is more appropriate than just placing the bound itself in the annotation. (Not to say a reasonable application doesn't exist, just that I can't think of one.) The typing API is not especially clean, and as a result I think supporting this feature might have the potential to add serious backwards-compatibility pain over time. As a result, I think it would be better for fastapi to not support this feature unless it enabled a capability that is currently missing or difficult to achieve cleanly. |
Beta Was this translation helpful? Give feedback.
-
No, I would say that there is no strong desire. |
Beta Was this translation helpful? Give feedback.
-
@dmajere if you want domain-specific types, you might try |
Beta Was this translation helpful? Give feedback.
-
@dmontagu |
Beta Was this translation helpful? Give feedback.
-
Glad to hear it! I use Especially for object IDs -- this makes it much easier to prevent silly mistakes where you accidentally call a function expecting an ID of one type of object with an ID of another type. If everything is an integer or a UUID, it can be very painful to debug the problem, but using |
Beta Was this translation helpful? Give feedback.
-
I'm a mypy newb and didn;t get the subtlety of this, care giving a little
snippet @dmontagu ?
…On Wed, Sep 18, 2019 at 6:30 AM dmontagu ***@***.***> wrote:
Glad to hear it! I use typing.NewType extensively in my own projects.
Especially for object IDs -- this makes it much easier to prevent silly
mistakes where you accidentally call a function expecting an ID of one type
of object with an ID of another type. If everything is an integer or a
UUID, it can be very painful to debug the problem, but using
typing.NewType means mypy will catch it for you without any effort.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#533?email_source=notifications&email_token=AAINSPREMWH5JOC7W3P4BZTQKGVFDA5CNFSM4IW4EZSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD66YFQA#issuecomment-532513472>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAINSPT6N2OPP6GITZULKRLQKGVFDANCNFSM4IW4EZSA>
.
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
ok I already told you @dmontagu but that's an amazing way of explaining clearly a feature a lot of people would not even notice it exists, just because you explains very well the problem it solves at first, it doesn't come out of the blue, it's pragmatic. I just read again the mypy docs about NewType and I was debating if I found the git man pages more or less convoluted... edit: that should go to pydantic docs ! |
Beta Was this translation helpful? Give feedback.
-
Thanks for the help here everyone! 👏 🙇 Thanks for reporting back and closing the issue @dmajere 👍 |
Beta Was this translation helpful? Give feedback.
-
One use case where it would be helpful to have support for this is when using class based router views from the With a generic base class for all my routers:
I could quickly inherit all of this CRUD functionality in my actual routes and even override route methods if I wanted to:
Currently, this allows me to use the endpoints, but without any type inference or validation on those input models. |
Beta Was this translation helpful? Give feedback.
-
Assuming the original need was handled, this will be automatically closed now. But feel free to add more comments or create new issues or PRs. |
Beta Was this translation helpful? Give feedback.
-
Another use case for this is to build an "API factory", as a function that returns a from fastapi import Body, FastAPI
from pydantic import BaseModel
T = TypeVar("T", bound=BaseModel)
def factory(schema: T) -> FastAPI:
app = FastAPI()
@app.post("/foo")
def foo(input: Annotated[T, Body()]):
return {"input": input}
return app You can then use this factory with a user provided |
Beta Was this translation helpful? Give feedback.
-
Describe the bug
TypeVar in route handler parameters recognized as strings not their constraint or bound types.
To Reproduce
Expected behavior
When for generics defined with constraints type casting is probably would be impossible, since
we have a list of possible types, for bounded typevars fastapi should type cast to bounded type.
Beta Was this translation helpful? Give feedback.
All reactions