-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
TypeVar in route handler parameters recognized as strings not their constraint or bound types. #533
Comments
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. |
No, I would say that there is no strong desire. |
@dmajere if you want domain-specific types, you might try |
@dmontagu |
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 |
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>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAINSPT6N2OPP6GITZULKRLQKGVFDANCNFSM4IW4EZSA>
.
|
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 ! |
Thanks for the help here everyone! 👏 🙇 Thanks for reporting back and closing the issue @dmajere 👍 |
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. |
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. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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.
The text was updated successfully, but these errors were encountered: