This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author yselivanov
Recipients Rokas K. (rku), crusaderky, djarb, jcea, martin.panter, yselivanov, zzzeek
Date 2020-07-06.22:13:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1594073607.51.0.640576607567.issue22239@roundup.psfhosted.org>
In-reply-to
Content
> I think this is a really critical technique to have so that libraries that mediate between a user-facing facade and TCP based backends no longer have to make a hard choice about if they are to support sync vs. async (or async with an optional sync facade around it).

If this works for such a big and elaborate framework as SQLA, we can definitely highlight this as a valid approach and even add a link to a blog post from the docs. We'll need to add an asyncio specific FAQ page for that or something similar.

Another approach, which would probably be a nonstarter for SQLA, is to use async/await for literally everything internally, and provide a tiny synchronous facade on top.  Funny thing you don't even need an event loop for that, just the basic understanding of how coroutines work internally.  I used this to create the edgedb-python package which has both sync and async first-class support with one code base.  Sync is even faster there in simple throughput benchmarks (as expected).
History
Date User Action Args
2020-07-06 22:13:27yselivanovsetrecipients: + yselivanov, jcea, djarb, zzzeek, martin.panter, Rokas K. (rku), crusaderky
2020-07-06 22:13:27yselivanovsetmessageid: <1594073607.51.0.640576607567.issue22239@roundup.psfhosted.org>
2020-07-06 22:13:27yselivanovlinkissue22239 messages
2020-07-06 22:13:27yselivanovcreate