It would be very useful to add an asynchronous lambda syntax, as a shortcut for coroutines. I'm not experienced enough to write a PEP or edit the C source, but I have some ideas for syntax:

import asyncio
foo = async lambda a,b: 5 + await bar(b)

Actually, you wouldn't even need to import asyncio.

The syntax for async lambdas doesn't look nice and I, personally, don't see that many use cases for them to justify adding new syntax.  And this would need a new PEP. 

I suggest to start a discussion on the Python-ideas mailing list if this is something you want to see in Python.

The only thing special about functions defined with lambda expressions rather than def statements is the generic name attribute '<lambda>' instead of a specific name.  PEP8 intentionally and properly discourages 'name = lambda ...' as inferior to 'def name(...'.

For your example, 

async def foo(a, b): return 5 + await bar(b)

For inline function expressions, as in function calls, the obvious proposals would be to reuse 'async' in f(async lambda a, b: ...) or a new keyword, such as 'alambda' or 'asynclambda' or ... . Either would need multiple use cases to justify not just using async def first.

Just wanted to add another use-case. In a project I'm working on, we are building a lot of graphs using code like this:

```
nodes = [
    Node('node-name1',
         children=[...],
         classifier=has_foo),
    Node('node-name2',
         children=[...],
         classifier=has_bar),
    ...
]
```
where `has_foo` and `has_bar` are async functions.
Sometimes it would be useful to combine two functions with
```
    Node('node-name',
         children=[...],
         classifier=async lambda: x: await has_bar(x) or await has_foo(x))
```
If this function was to be an `async def`, rather than `async lambda`, it would have to be defined far away from where it is used. This doesn't always make sense semantically.

I don't think this example on its own is enough to warrant new syntax in the language, but if somebody is collecting "multiple use cases to justify not just using async def first", perhaps it's worth including.

components: + Interpreter Core, - asyncio
resolution: postponed
stage: resolved