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,
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
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
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
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