Nathaniel Smith <n...@pobox.com> added the comment:
> 90% of everything people are doing here are in the context of HTTP services. > The problem of, "something.a now creates state that other tasks might see" > is not a real "problem" that is solved by using IO-only explicit context > switching. This is because in a CRUD-style application, "something" is not > going to be a process-local yet thread-global object that had to be created > specifically for the application (there's things like the database connection > pool and some registries that the ORM uses, but those problems are taken care > of and aren't specific to one particular application). Yeah, in classic HTTP CRUD services the concurrency is just a bunch of stateless handlers running simultaneously. This is about the simplest possible kind of concurrency. There are times when async is useful here, but to me the main motivation for async is for building applications with more complex concurrency, that currently just don't get written because of the lack of good frameworks. So that 90% number might be accurate for right now, but I'm not sure it's accurate for the future. > In the realm of Python HTTP/CRUD applications, async is actually very popular > however it is in the form of gevent and sometimes eventlet monkeypatching, > often because people are using async web servers like gunicorn. A critical difference between gevent-style async and newer frameworks like asyncio and trio is that the newer frameworks put cancellation support much more in the foreground. To me cancellation is the strongest argument for 'await' syntax, so I'm not sure experience with gevent is representative. I am a bit struck that you haven't mentioned cancellation handling at all in your replies. I can't emphasize enough how much cancellation requires care and attention throughout the whole ecosystem. > w.r.t the issue of writing everything as async and then using the coroutine > primitives to convert to "sync" as means of maintaining both facades, I don't > think that covers the fact that most DBAPI drivers are sync only I think I either disagree or am missing something :-). Certainly for both edgedb and urllib3, when they're running in sync mode, they end up using synchronous network APIs at the "bottom", and it works fine. The greenlet approach does let you skip adding async/await annotations to your code, so it saves some work that way. IME this isn't particularly difficult (you probably don't need to change any logic at all, just add some extra annotations), and to me the benefits outweigh that, but I can see how you might prefer greenlets either temporarily as a transition hack or even in the long term. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue22239> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
