Le 04/04/2018 à 09:27, Steven D'Aprano a écrit :
Yes, this exactly. And if you're writing a web app, or certain kinds of
desktop apps, these seems sensible. I don't want my browser to come to a
complete halt just because some resource is taking a few seconds to
respond.
But honestly, from everything I've seen, outside of browser apps (and I'm
not even sure about them), async processing looks to me like the wrong
solution to, well, everything.
For what it's worth, I can give you an example that I have been playing
with lately, and it has nothing to do with browser app.
I have been doing scientific image acquisition with Python for some
time, and was quite happy with my program.
But then, I suddently needed to fetch from several cameras at once, and
also query another device at another interval.
Of course, it is possible to do that in a simple loop without asyncio,
but I thought I would give asyncio a try, and I was amazed at how easy
it makes this kind of task. And then it is simple to remove/add a
camera, etc.
My only concern is that I tend to have code duplication between the
async version of the program and the sync version of the program.
In this case, the script spends most of its time waiting for a frame to
be available on the cameras, and the time interval to query the other
device. The fetching and processing of the frames take negligible time.
The library that I use is not asynchronous, but it was very easy to
run_in_executor the C function that blocks until a frame is available on
a given camera.
Compared to a non-async version where I would have had to use that C
function with some short timeout and iterate over all cameras, I think
the async version is more efficient. The await will just be as long as
it takes for the WaitFrame C function to run... When the C function
ends, the asynchronous task resumes... There is no need to adjust some
timeout by hand.
Bests,
Julien
--
https://mail.python.org/mailman/listinfo/python-list
