It would probably be hard for people to find at this point all the
places they might be relying on this behavior (if anywhere), but isn't
this a basic documented property of coroutines?
From the introduction section on coroutines [1]:
> Calling a coroutine does not start its code running – the
Depending on the coroutine*not* running sounds like asking for trouble.
On Thu, May 3, 2018, 09:38 Andrew Svetlov wrote:
> What real problem do you want to solve?
> Correct code should always use `await loop.sock_connect(sock, addr)`, it
> this case the behavior
Hi,
tl;dr: coroutine functions and regular functions returning Futures
behave differently: the latter may start running immediately without
being scheduled on a loop, or even with no loop running. This might be
bad since the two are sometimes advertised to be interchangeable.
I find that
The real problem I'm playing with is implementing "happy eyeballs",
where I may have several sockets attempting to connect simultaneously,
and the first one to successfully connect gets used. I had the idea of
preparing all of the loop.sock_connect() coroutine objects in advance,
and scheduling
Then, perhaps it's safest to treat the same way as , i.e.
callbacks, and pass them around the old way, using partials, lambdas,
separate arguments for coroutine function and arguments, etc. Aww,
suddenly coroutines don't feel as sexy as before. (j/k)
On Fri, May 4, 2018 at 4:24 AM, Guido van
My 2c: don't use py3.4; in fact don't use 3.5 either :)
If you decide to support older Python versions, it's only fair that
separate implementation may be needed.
Re: overall problem, why not try the following:
wrap your individual tasks in async def, where each staggers, connects and
resolves
On Thu, May 3, 2018 at 8:52 PM, Dima Tisnek wrote:
> My 2c: don't use py3.4; in fact don't use 3.5 either :)
> If you decide to support older Python versions, it's only fair that
> separate implementation may be needed.
>
I'd agree - focus Python 3.6+
>
> Re: overall problem,