Any reason call_next definition has been moved inside of __call__ in BaseHTTPMiddleware?

[leaprovenzano]

Before anyio integration update call_next was a method on BaseHTTPMiddleware:
see in 0.14.2:

starlette/starlette/middleware/base.py

Line 28 in ea19904

async def call_next(self, request: Request) -> Response:

we had some use-cases for this as it made it straigtforward to customize the request type a little bit by simply overriding the __call__ ... a little non-standard i suppose but it was a public method. So you could do something along the lines of :

class CustomBaseHTTPMiddleware:
    def __init__(self, app: ASGIApp, dispatch: DispatchFunction = None) -> None:
        self.app = app
        self.dispatch_func = self.dispatch if dispatch is None else dispatch

    async def __call__(self, scope: Scope, receive: Receive, send: Send) -> None:
        if scope["type"] != "http":
            await self.app(scope, receive, send)
            return

        request = CustomRequest(scope, receive=receive)
        response = await self.dispatch_func(request, self.call_next)
        await response(scope, receive, send)

since the anyio stuff call_next has been moved internal to the __call__ , which obv breaks code like this....

starlette/starlette/middleware/base.py

Line 25 in 813aa8d

async def call_next(request: Request) -> Response:

Is there any particular reason for this change? I couldn't see it discussed anywhere in the pr for the anyio changes...

[Kludex]

I guess it is because we needed this line:

starlette/starlette/middleware/base.py

Line 38 in 813aa8d

task_group.start_soon(coro)

[leaprovenzano]

hmm yeah this initially baffled me a bit as its relying on the task_group opened in the with statement in the outer function below so it's kinda confusing on first look....

There has been some discussion on allowing users to provide some sort of custom request type:

#875
#930

but barring that i suppose i will look to implementing asgi middleware directly if possible. Will be a little bit of a learning curve for me looking at BaseHttpMiddleware.__call__...I know asyncio well but will need to get my head around anyio.

We will probably need to carry out pretty extensive performance testing before moving on to >=0.15.0 in any case before we feel comfortable using anyio integration.

[tomchristie]

Related: #1519 (comment)

As identified in #1029, nudge folks away from BaseHTTPMiddleware. It was a neat idea, but there's actually a bunch of different issues with the approach.