1 |
On 08/22/2016 03:18 AM, Alexander Berntsen wrote: |
2 |
> On 21/08/16 00:18, Zac Medico wrote: |
3 |
>> This emulates the |
4 |
>> asyncio.AbstractEventLoop.run_until_complete(future) interface |
5 |
> What's that, and why are we emulating it instead of just using it? |
6 |
|
7 |
We will be able to use it with python 3.4 and later, but not with older |
8 |
versions of python. Also, we have some more work to do first: |
9 |
|
10 |
* Migrate all internal use of the EventLoop.iteration method to the new |
11 |
run_until_complete(future) method, and remove the EventLoop.iteration |
12 |
method (or make it private as long as it's needed to implement |
13 |
run_until_complete for older python versions). |
14 |
|
15 |
* Implement all EventLoop methods using asyncio.AbstractEventLoop |
16 |
methods (but keep existing implementations for use with older python). |
17 |
|
18 |
>> which will make it possible to reduce latency in situations where it |
19 |
>> is desirable for a loop to exit at the earliest opportunity. |
20 |
> It makes it possible -- okay. But does it? I'm reluctant to change |
21 |
> things willy nilly, and add SLOCs, without a tangible benefit. |
22 |
|
23 |
Having a migration path to asyncio is the most tangible benefit, since |
24 |
it allows us to rely on a standard library instead of our own internal |
25 |
event loop implementation. I mention latency since it's a clear |
26 |
advantage of the run_until_complete API (at least in theory). |
27 |
-- |
28 |
Thanks, |
29 |
Zac |