On Thu, Mar 27, 2014 at 10:29 AM, Saúl Ibarra Corretgé <[email protected]>wrote:
> > I don't think that exec is going to help you here. It cannot cause > > the current frame to yield, since it executes in its own frame > > (only the locals/globals dicts are shared with the calling frame). > > Your best if you want single-source is to avoid yield altogether > > and use callbacks instead. The alternative (which Trollius more or > > less expects you to do) is a mechanical source-to-source > > translation. In particular, change "yield From(x)" --> "yield from > > x" and change "raise Return(x)" --> "raise x". > > > > I was thinking about using exec to basically create this function: > > def yield_from(f): > return (yielf from f) > > The trollius equivalent would be > > def yield_from(f): > x = yield From(f) > raise Return(x) > > Not sure if it would work though. > It won't -- because it contains a yield it must itself be declared as a @coroutine and called using yield [fF]rom... > > Now, after thinking about it, in this particular case I think it's > much better to avoid defining query() as a coroutine and just return > the future. Then the caller can yield from, yielf From, > add_done_callback or whatever on it. > Right, that's what I was trying to say. :-) > > > > > Maybe it can indeed be emulated indeed, I haven't looked into that > > yet. > > > > > > This looks like the obvious approach to emulating getaddrinfo with > > asyncio. But I have one niggling question: why make two separate > > queries to the DNS server? All descriptions I've found of the DNS > > protocol (and even the Twisted source code) suggest that you can > > send multiple queries in a single request. Is that not supported in > > real life for some reason I fail to see? > > > > AFAIK c-ares doesn't support it. Not sure about other libraries, I'm > only familiar with c-ares... > OK that would do it. :) > > > > > > A happy eyeballs implementation would be much appreciated -- > > perhaps more than a custom DNS implementation[1]. It should > > probably start two concurrent tasks, one responsible for IP, the > > other for IPv6, and each doing its own getaddrinfo() call limited > > to that address family. When one succeeds the other should be > > cancelled (and each task should be careful to clean up when > > cancelled -- this is where knowing that cancellation can only raise > > at a yield is hugely helpful, so it would require only a few > > try/finally blocks). > > > > [1] The reason I'm not excited about a custom DNS implementation is > > that in my experience getaddrinfo() does a lot more than talk DNS. > > It usually has some kind of cache, and I suspect the cache may be > > shared between different processes on the same machine. But there's > > already discussion of this in issue 160. > > > > Yeah, it would be nice indeed. Unfortunately I won't be able to give > it a shot anytime soon :-/ I had already integrated pycares with other > async libraries, so doing aiodns took me very little. Also, my main > area of work is VoIP, where we use NAPTR and SRV all the time, and > getaddrinfo doesn't help there ;-) > Fair enough. But I wasn't talking just to you. :-) -- --Guido van Rossum (python.org/~guido)
