Having something like this would sound very exciting for libraries like Django. Django could use this to support async and sync APIs (using virtual threads under the hood to support a “clean”-ish single implementation, while still maintaining some performance guarantees in both spaces).
Without a way to have single implementations of async and sync APIs, various libraries have landed on using codegen to support both sides. we are asking all libraries to basically do codegen to support both APIs. What is going to happen in the end? Libraries are going to go more and more into async-only API territory for ease of maintenance. The future of sync Python depends on libraries being able to support sync and async variants cleanly.
More libs being async only there will be even more pressure to improve the (IMO) lackluster debugging support for async code (breakpoint() into an async method call and try to get any other async value).
We want good things and better suppoort in this space! But do we want libraries across the board to be doing codegen to do the good thing?
And the subtler thing: users of these libraries end up wanting codegen themselves to preserve sync and async API layering.
So my short version is that I think if you support structured concurrency through async/await, you should consider supporting this idea, because it will allow for libraries to offer good ergnomics in the space.
Libraries like Django could rely on continuations deep in the database code to have a single, “clean” implementation that yields only when the user is expecting an async variant of an API.
I had previously written a very silly idea to basically turn async “on or off”. But this would provide a pretty principled way to sidestep this problem entirely, while still giving me dual sync/async variant API support.