-
-
Notifications
You must be signed in to change notification settings - Fork 947
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
Type Hints: Add type hints to tutorials, snippets and examples #1820
Comments
Hi 👋, Thanks for using Falcon. The large amount of time and effort needed to Please consider helping us secure the future of the Falcon framework with a Thank you for your support! |
See also #1350, which strives after full typing support for the whole codebase. |
@vytas7 I can start working on this |
@bibekjoshi54 Awesome sauce! Go ahead. |
That would be great! |
Just to throw it out there: I think a Protocol would be a great fit for falcon/falcon/routing/compiled.py Line 150 in 4910dd7
Something like: from typing import Protocol
from falcon.request import Request
from falcon.response import Response
class Resource(Protocol):
def on_get(self, request: Request, resp: Response)) -> None:
...
def on_post(self, request: Request, resp: Response)) -> None:
...
# and so on ... Then the signature would become: def add_route(self, uri_template: str, resource: Resource, suffix: str | None = None, compile: bool = False) The only caveat is that implementor would have to provide all the methods ... at least until optional protocol members are supported, something I've also raised here 🤞🏻 |
That's an option, but I'm not sure it would provide much in terms of help for a user, since once the Maybe it could be used a "TypingResource" that may be used by user as superclass, where each method is defined in a type_checking block (to avoid it being picked up by the router). This could be useful since ide can autocomplete the signature of methods when overloading one. Something like class TypeCheckResource:
"""Superclass of a Resource for typing purposes"""
if TYPE_CHECKING:
def on_get(self, req: Request, resp: Response, **path_args: Any) -> None:
"""Handles the GET method"""
... |
True, but in the current implementation if that class had say: class MyResource:
def on_get(self, req: str, bad: int)
app.add_route(uri_template, MyResource()) Then it would still type check okay (and the IDE wouldn't complain), because there is currently no typing for falcon/falcon/routing/compiled.py Line 150 in 4910dd7
A super class (or even better an ABC) would work, * assuming the goal would be to change the signature of def add_route(self, uri_template: str, resource: TypeCheckResource,... The nice thing about protocols is that we could add the
Put another way: it would allow graceful adoption of typing, without forcing everyone to do it. * incidentally protocols do also allow for explicitly declaring an implementation if someone wanted to verify the types of a resource class before they tried to use it in ... but that's all academic until/unless python/typing#601 happens 😑 |
I'll try to help with it :) |
I can work on this issue |
@zodecky that sounds great! |
Here's all the stubs I've collected, if it helps: |
Thanks for sharing @davetapley 👍 On that note, could you test Falcon |
@vytas7 amazing, looks good, a few issues incoming, but regardless thanks for all the hard work 🙏🏻 |
To improve code readability and be friendlier to PEP 484, we should start adding type annotations to our code, probably starting from snippets, tutorials and examples.
Originally discussed here #1737 (comment)
The text was updated successfully, but these errors were encountered: