Missing autocompletion for request.app

[chbndrhnns]

Describe the bug
When I am using the request instance in an endpoint, my IDE does not provide me with autocompletion for request.app.

Is it maybe due to missing type hints? Or because the request instance is from Starlette and cannot be annotated in FastAPI?

To Reproduce
Steps to reproduce the behavior:

1. Create a file with

from fastapi import FastAPI
from starlette.requests import Request

app = FastAPI()

@app.get('/')
def get(request: Request):
    request.app

2. Try to run autocompletion for request.app

Expected behavior
I can use the auto-completion provided by me IDE (e.g. PyCharm)

Screenshots
n/a

Environment:

• OS: macOS

• FastAPI Version: 0.42

• Python version: 3.7.4

Additional context

[prostomarkeloff]

It isn't working because has typehint typing.Any:
https://github.com/encode/starlette/blob/master/starlette/requests.py#L50

[chbndrhnns]

So would it be possible to have this Request object as a subclassed object in FastAPI where we can change the type annotation?

[prostomarkeloff]

I think more correct will create issue in starlette

[chbndrhnns]

@tiangolo @dmontagu Would you be willing to accept a PR where we subclass the Starlette objects so that we can benefit from the type annotations in the FastAPI class?

A straightforward example would be:

from starlette.testclient import TestClient as tc

class TestClient(tc):
    def __init__(self, app: FastAPI):
        super().__init__(app)
        self.app: FastAPI = app

Another candidates apart from TestClient would be Request.

I am asking because this would also involve rewriting a couple of the documentation pages.
And: Am I missing some downsides of doing that?

[dmontagu]

1. I think it would make sense for starlette to add the type hint of Starlette on request.app, that would go a long way toward getting useful autocompletion.

2. I believe it would work if you create your own custom subclass

class FastAPIRequest(Request):
    app: FastAPI

Then use FastAPIRequest in your endpoints -- fastapi should still identify it as a Request and inject the appropriate value (though it will be a vanilla starlette request that gets injected).

If this didn't work you could do something like the following which definitely would work (maybe requiring some minor tweaks to get mypy to like it):

if typing.TYPE_CHECKING:
    class FastAPIRequest(Request):
        app: FastAPI
else:
    FastAPIRequest = Request

3. The above approaches should work for TestClient too.

4. I'm not sure whether it makes sense to add this level of nuanced typing to FastAPI or just to fix it in Starlette as best as possible. It will add a bit of a maintenance burden if/when starlette changes its API. I'd be more in favor if presented with more of a practical problem that better type hints would address (i.e., what completion do you wish you had that you currently don't?). I think in some (many?) cases fixing the annotations in starlette might solve it; if so that's probably preferable.

[chbndrhnns]

I am fine with only making these changes in my own project, @dmontagu. I just have trouble to understand how a better annotation in Starlette would help FastAPI. My assumption is that properties or methods that are only available in FastAPI cannot be made available via type annotations in Starlette (?).

[dmontagu]

That's right, but what properties or methods do you want to use that are only available in FastAPI? If there are important ones to support then I think it would make sense to try to address this. Usually the base Starlette ones are enough though, at least in my experience.

[chbndrhnns]

The ones that are not present in Starlette seem at least these to me:

self.title = title
self.description = description
self.version = version
self.openapi_url = openapi_url
self.openapi_prefix = openapi_prefix.rstrip("/")
self.docs_url = docs_url
self.redoc_url = redoc_url
self.swagger_ui_oauth2_redirect_url = swagger_ui_oauth2_redirect_url
self.swagger_ui_init_oauth = swagger_ui_init_oauth
self.extra = extra
self.dependency_overrides: Dict[Callable, Callable] = {}

self.openapi_version = "3.0.2"

The ones I tried to access were dependency_overrides, docs_url and openapi_url.

[dmontagu]

Is there a reason you couldn't access them on the app directly though? For example, adapting your initial example, let' say you wanted to return the docs_url:

from fastapi import FastAPI
from starlette.requests import Request

app = FastAPI()

@app.get('/')
def get(request: Request):
    return request.app.docs_url

I agree it's annoying you don't get completion, but it seems to me you should just be using the app directly:

from fastapi import FastAPI
from starlette.requests import Request

app = FastAPI()

@app.get('/')
def get(request: Request):
    return app.docs_url

That would give you access to the autocompletion you want.

---

I think it could make sense to make it easier to get autocompletion for request.state, request.app, and request.app.state, and I actually do this in my own codebases now by subclassing (at least in if TYPE_CHECKING: blocks). But all of the approaches I've seen to this so far (including my own) seem pretty opinionated, enough that I'm not sure it makes sense to integrate directly into FastAPI.

[dmontagu]

Also, just to give an example, this is what I mean by subclassing to get autocompletion:

class MyServerState:
    database: Database
    cache: Optional[FanoutCache]
    orm: MyORM
    search: SearchEngine

    def __init__(self, database: Database, cache: FanoutCache = None) -> None:
        self.database = database
        self.cache = cache
        self.orm = MyORM(self.database, self.cache)
        self.search = SearchEngine(self.orm)

class MyServer(FastAPI):
    state: MyServerState  # type: ignore[assignment]

    def setup_state(self, database: Database, cache: FanoutCache = None) -> None:
        self.state = MyServerState(database, cache)

class MyRequest(Request):
    app: MyServer

[chbndrhnns]

I understood the subclassing approach and will also follow it. I thought it might be a good idea to suggest this auto-completion improvement to have it for other users, as well. If that's not the case, feel free to close the issue.

[dmontagu]

I go back and forth; either way I'd be interested in @tiangolo's opinion on this.

[chbndrhnns]

It seems like the starlette people are not changing their implementation cf. Kludex/starlette#688.

[tiangolo]

The first thing would be, why do you want to access the app through the request?

Maybe if we understand the use case better we can find the right solution for it.

I think I can imagine a use case where it would be better to access the app through the request rather than directly as @dmontagu says.

About accessing docs_url and openapi_url, if you need to use that in other parts of your code, maybe it would be a better idea to put them in a Pydantic's BaseSettings that you can use everywhere.

About dependency_overrides, why would you want to access it in a path operation?

About types for the TestClient, I think it's better to wait until the TestClient is based on HTTPX, to not lose that effort. Also, that itself might solve the problem.

[chbndrhnns]

I had two use cases for accessing fields of the app instance in a path operation

1. Redirecting based user agent

if any(browser in user_agent for browser in BROWSERS):
            return RedirectResponse(url=request.app.docs_url)
        return RedirectResponse(url=request.app.openapi_url)

This would be solved by your suggestion to extract these values into a settings object.

2. Include app version into a path endpoint

I guess your same suggestion would apply here.

I am fine with that and I missed the proposed options when creating the issue.

[tiangolo]

Great! Thanks for replying back @chbndrhnns . Then I think we can close this issue, right?

[github-actions[bot]]

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.