Message373241
| Author |
yselivanov |
| Recipients |
Rokas K. (rku), crusaderky, djarb, jab, jcea, martin.panter, njs, yselivanov, zzzeek |
| Date |
2020年07月07日.19:37:37 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1594150657.56.0.468253289426.issue22239@roundup.psfhosted.org> |
| In-reply-to |
| Content |
> Yeah, writing a trivial "event loop" to drive actually-synchronous code is easy. Try it out:
This is exactly the approach I used in edgedb-python.
> I guess there's technically some overhead, but it's tiny.
Correct, the overhead isn't even detectable in microbenchmarks. In most async programs regular function calls dominate awaits by a few factors of magnitude.
> I think dropping 'await' syntax has two major downsides:
For the extra context, in the case of using this approach for something like edgedb-python these downsides don't really apply, because we're adapting async/await implementation to be sync. The async/await code can handle cancellation etc. whereas the sync code only needs to support the general protocol parsing flow. FWIW I don't think it would be possible to apply my approach to SQLA without a very invasive rewrite, which isn't probably worth it.
> tl;dr: I think switching from async/await -> greenlets would make it much easier to write programs that are 90% correct, and much harder to write programs that are 100% correct. That might be a good tradeoff in some situations, but it's a lot more complicated than it seems.
Yeah, this sums up my opinion on this topic.
Also, having spent a couple of years writing and debugging big and small greenlet-heavy code bases I wouldn't want to touch them ever again. Your mileage may vary, Mike. |
|