I think the first thing is to add async "modes" to compile: in particular "async-exec" and "async-single". These would be like the current "exec" and "single" modes respectively, except that they act like the code is inside an "async def", so "await" is allowed, and executing the resulting code object produces a coroutine object that has to be iterated to actually run the code.

I guess we might want "async-eval" too just for completeness, though I'm not currently aware of any use cases for that.

A utility to check whether an AST requires async mode should be fairly straightforward. So if you want to choose on the fly, you would do:

1. ast = compile(source, filename, "async-exec", ast.PyCF_ONLY_AST)
2. use a utility check whether 'ast' contains any top-level 'await'/'async with'/'async for'
3. if so, create bytecode with compile(ast, filename, "async-exec"). If not, create bytecode with compile(ast, filename, "exec").

Once you have a code object, I think it's too late: if you use "async-exec" mode to compile a code object that doesn't actually use 'await', then it should still return a coroutine object that needs iterating, etc., just like an 'async def' that has no 'await' in it. So if you want to do this check, the AST phase is the time to do it. Maybe ast.is_ast_async(ast_obj)?

> Have distinction in this `async exec`/`compile` between "I am compiling a module", currently `exec` mode for both exec and compile, and a "I'm compiling a _multiline_ interactive statement".


This seems like a separate problem from the async stuff... I'm curious to hear how what distinction you want to make between 'exec' and a new 'multi-single' (?) mode, but maybe that should be a new issue?