I'm not sure how this would work with decorators - the app is not available at the time a decision needs to be made e.g. when decorating blueprint handlers.

I don't think blueprint decorators have a problem, as they defer registration until the app is available. But I can see how your point would apply to extension decorators, although I can't think of an example right now.

For clarity I was thinking about,

@blueprint.get("/")
@extension
async def route():
 ...

I don't see why @ensure_async before @extension_decorator is needed. Some extensions are already attempting to support both def and async def by calling ensure_sync inside the wrapper, for example Flask-Login's @login_required does this. In a theoretical extension that supports both, wouldn't the following be ok?

def login_required(f):
 if iscouroutinefunction(f):
 return async_login_required(f)
 else:
 return sync_login_required(f)

I think this might solve the decorator issue with my idea too. Since we're going to support both sync and async user defined functions, we can switch on what the user defined.

So basically, a view decorator that wants to support async and sync has to return async or sync, it shouldn't change the color of the function. Then it works exactly as it does now, where app.add_url_rule (and other app methods) is what decides to call ensure_sync or not.

This works for type 2 extensions, of which Flask-Login is. It doesn't work for type 3 extensions. For example consider an extension that needs to do something with the request JSON, which as a pure Quart extension would be,

def extension(func):
 async def wrapper(*args, **kwargs):
 data = await request.get_json()
 ...
 return await ensure_async(func)(*args, **kwargs)
 return wrapper

To make this extension support Flask and Quart, we need to know somehow if the request.get_json needs to be awaited at import time as the wrapper must be either sync or async depending on it. By enforcing the ensure_(a)sync we can use the func to figure it out, i.e.

def extension(func):
 if iscoroutinefunc(func):
 async def wrapper(*args, **kwargs):
 data = await request.get_json()
 ...
 return await func(*args, **kwargs)
 else:
 def wrapper(*args, **kwargs):
 data = request.get_json()
 ...
 return func(*args, **kwargs)
 return wrapper

As with the enforced usage of ensure_(a)sync all Quart functions will be coroutine functions and all Flask sync-functions.

Hmm, I think I see what you're getting at. We know whether the user's function is sync or async, but we don't know whether the app they'll register it with is sync or async so we don't know if it's safe to await app.get_json().

At the expense of a bit more complexity in these types of decorators, we could combine this with my app.prefers_async idea to do this:

if iscoroutinefunction(f):
 async def wrapper(...):
 if current_app.prefers_async:
 data = await request.get_json()
 else:
 data = request.get_json()
 
 return await f(...)

This works for the async case, but it can't work for the sync case i.e. I don't know how this can work,

if not iscoroutinefunction(f):
 def wrapper(...):
 if current_app.prefers_async:
 data = await request.get_json() # Issues
 else:
 data = request.get_json()
 
 return f(...)

The idea of extensions supporting both Flask and Quart is excellent!

It seems like there are four combinations (Sync/Async Function, Flask/Quart App) that need to be handled with the Type 3 (The extension uses Flask/Quart inbuilt IO) situation:

from quart.utils import run_sync
def extension(func):
 if iscoroutinefunction(f): # Async Function
 async def wrapper(...):
 if current_app.prefers_async: # Quart
 data = await request.get_json()
 else: # Flask
 data = request.get_json()
 return await f(...)
 else: # Sync Function
 def wrapper(...):
 if current_app.prefers_async: # Quart
 data = ensure_sync(request.get_json())
 else:
 data = request.get_json(). # Flask
 return f(...)

Is ensure_sync(request.get_json()) valid in Quart to run data = await request.get_json() in a synchronous environment?

Since the prefers_async/prefers_sync flags will be new, it will be getattr(current_app, 'prefers_async', False) for extensions that support older versions of Flask. This will get tedious (and slow with a full MRO search), so it should be done once per function entry.

There is an additional question of whether to use isinstance(request, QuartRequest) or current_app.prefers_async and what request itself points at (no guarantee only Quart or Flask is installed). Maybe,

try:
 from flask import request as flask_request 
except ImportError:
 flask_request = None
try:
 from quart import request as quart_request 
except ImportError:
 quart_request = None
...
if current_app.IS_QUART:
 data = await quart_request.get_json()
else:
 data = flask_request.get_json()