> With greenlets OTOH, it becomes possible for another task to observe someobj.a == 1 without someobj.b == 2, in case someobj.__setattr__ internally invoked an await_().

let me try this one more time.    Basically if someone wrote this:

async def do_thing():
   someobj.a =1
   await do_io_setattr(someobj, "b", 2)

then in the async approach, you can again say, assuming "someobj" is global, that another task can observe "someobj.a == 1" without "someobj.b == 2".    I suppose you are making the argument that because there's an "await" keyword there, now everything is OK because the reader of the code knows there's a context switch.

Whether or not one buys that, the point of my approach is that SQLAlchemy itself *will* publish async methods.  End user code *will not* ever context switch to another task without them explicitly calling using an await.  That SQLAlchemy internally is not using this coding style, whether or not that leads to new kinds of bugs, there are new kinds of bugs no matter what kind of code a library uses, I don't think this hurts the user community.  The community is hurting *A LOT* right now because asyncio is intentionally non-compatible with the traditional blocking approach that is not only still prevalent it's one that a lot of us think is *easier* to work with.