Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

articles/2024/09/23/async-to-sync/ #41

Open
utterances-bot opened this issue Dec 7, 2024 · 1 comment
Open

articles/2024/09/23/async-to-sync/ #41

utterances-bot opened this issue Dec 7, 2024 · 1 comment

Comments

@utterances-bot
Copy link

Automatic async to sync code conversion — Psycopg

Python adapter for PostgreSQL

https://www.psycopg.org/articles/2024/09/23/async-to-sync/

Copy link

I found this post because I don't get the appeal of async-await, but definitely have some issues with database io via Django for which i'm trying to find a solution, and async - other than breaking everything - would be one route to a fix.

What is it about async code that couldn't be accomplished better by a Python runtime mode/flag that handles the boundaries where blocking calls occur in an async "style" that jumps to other unblocked code inside an internally-managed event-loop? (and then extend that mechanism so C-level python extensions can handle async dispatch too.)

This AST parsing to solve the maintenance burden of double async+sync functions is the logical endpoint for the situation we have found ourselves in. But - and I ask in this odd forum because you are the person who wrote exactly this kind of code - why are we here? Legit: what am I missing about async/await that means we actually needed to bifurcate so much code?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants