| > Even on that aspect, I'd be interested in knowing how you'd achieve bidirectional communication async generators. How would the ASGI server call into the application and handle messages coming both ways? Surely, it can't just `async for message in agen: ...`, as that would only replicate the `send()` ASGI callback — what about `receive()`? Yield is two-way. ``result = await agen.asend(next_message)` ` et al. > Having worked and developed with it extensively for over a year now, ASGI is one of the most elegant and well-designed interfaces I've seen. Having worked with Python async for 3 years, anything that asyncio touches is completely poisoned. ASGI is another in the line of terribleness of the modern async ecosystem. > Besides, how would middleware look? A second async generator. > And you probably wouldn't be able to support all the possible syntactical implementations allowed by the notion of a Python callable Require an async generator. Done! > Also, I wholeheartedly congratulate the Django team for pushing the standard out there and driving the Python async web ecosystem forward. You rock! Much like asyncio, something isn't good just because it's being pushed. |
It's still limited. To get a result you need to send something. Using it for something that's not strictly request-response can get complex.
> Having worked with Python async for 3 years, anything that asyncio touches is completely poisoned. ASGI is another in the line of terribleness of the modern async ecosystem.
That's your own bias. I also used asyncio from the beginning and got a different opinion. The asyncio package that comes with python is low level and is meant for building frameworks. If you used aiohttp, asyncpg and other packages packages build on top of asyncio it's actually quite enjoyable.