Replace asyncio with AnyIO

[davidbrochart]

See sqlalchemy/sqlalchemy#6318 (reply in thread).

[CaselIT]

Personally I would rather not merge this.

Trio does not seems to be very used, we had basically no request for it between 2021 an this week, also I don't think it's a positive thing how they require each client library to make changes to support it.

overall the maintenance burden of supporting something that's not asyncio when users will inevitably have issues with it does not seem worth it.

It seems that no async library I checked seems to support it (asyncpg, psycopg3, oracledb, asyncmy, aiomysql), so I question why should we take on the additional complexity for limited to no benefit?
I quite agree with the conclusion of daniele here psycopg/psycopg#29 (comment)

these are just my two cents.

[zzzeek]

OK it looks like awaitlet itself doesnt have much happening, the asyncio.Lock and stuff like that is still local to the SQLAlchemy side.

Overall I'm not ready for anyio to be a required dependency anywhere. I had the notion it could be some kind of optional dependency for awaitlet, but looking here again I see most of the more asyncio-specific code is still on the SQLAlchemy side anyway, and we aren't switching that over to anyio.

I took a look at our discussion tracker as I have vague recollections of people having problems specific to anyio and I see stack traces like this one: sqlalchemy/sqlalchemy#10253 (reply in thread) so..... people are using SQLAlchemy under anyio already, where anyio calls into the use of asyncio within SQLAlchemy, I guess however this only means anyio can't use the "trio" event loop for such code? not really sure.

I also generally agree with the sentiment mentioned in the psycopg thread that Python has a native asyncio platform, and that's what libraries should be coding towards. if there is such a deficiency in asyncio that trio is necessary, I dont understand why there isn't a push towards new peps for Python to repair these deficiencies.

[davidbrochart]

If not using AnyIO, then we could either use sniffio to detect the running event-loop, and if that's still not acceptable, have a setting to specify which event-loop we want to run in (asyncio by default). Then it would really be optional, what do you think?

people are using SQLAlchemy under anyio already, where anyio calls into the use of asyncio within SQLAlchemy, I guess however this only means anyio can't use the "trio" event loop for such code? not really sure.

Yes, AnyIO is not an event-loop per say, it just uses asyncio or Trio under the hood, so if the current event-loop is asyncio then any asyncio code will work. So what we're trying to do here is just allow SQLAlchemy to run on the Trio event-loop.

if there is such a deficiency in asyncio that trio is necessary, I dont understand why there isn't a push towards new peps for Python to repair these deficiencies.

What is lacking in asyncio is structured concurrency, but rather than creating PEPs it seems that asyncio gradually integrates ideas from structured concurrency, task groups being one of them.

[zzzeek]

but there are no async database drivers, quasi-DBAPI or not, that run under trio currently. is that accurate?

[davidbrochart]

True but that's a chicken and egg problem, and I want to write one.