I generally agree with this. Particularly since, while having the view run within an open thread doesn’t improve concurrency across views, it does allow users to take advantage of async within the view (cache, ORM, templates, etc)
When adapting third-party sync middlewares, we could also raise a warning and point to the documentation on how to port them to incentivize users to rewrite them.
I would suggest adding configuration to specify the behaviour of the middleware processing. An example:
MIDDLWARE_BEHAVIOUR='async'(default). All middlwares must be async, raise an error if they aren’tMIDDLWARE_BEHAVIOUR='adapt'. Automatically adapt the middlewares, raise a warning as described above and explain the consequences for concurrencyMIDDLWARE_BEHAVIOUR='suspend_sync'. Whatever the sync suspension magic does.
I’m not sure if there are other behaviours that would make sense here.
As for pausing the sync middleware, this can probably be achieved via AST manipulations, but if __init_subclass__ was considered ugly monkeypatching, then this is way off the mark.