asyncio/master DNS resolving is different from Python 3.5.1 asyncio

[1st1]

I think we broke something with PR #302, when we started to bypass the system getaddrinfo for addresses that look like an IP address.

I've just run the uvloop test suite over the latest asyncio code base, and a few tests crashed. Amongst them, tests that test looo.create_server and create a basic aiohttp server, that set port to None or an str.

See also https://github.com/MagicStack/uvloop/blob/master/tests/test_dns.py for a full range of arguments for getaddrinfo.

@ajdavis, would you be able to look into this ASAP?

[ajdavis]

Thanks Yury, I tried uvloop's suite with asyncio's HEAD and got this failure:

======================================================================
ERROR: test_aiohttp_basic_1 (tests.test_aiohttp.Test_AIO_AioHTTP)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/emptysquare/.virtualenvs/uvloop/uvloop/tests/test_aiohttp.py", line 35, in test_aiohttp_basic_1
    srv = self.loop.run_until_complete(f)
  File "/Users/emptysquare/.virtualenvs/asyncio/asyncio/asyncio/base_events.py", line 383, in run_until_complete
    return future.result()
  File "/Users/emptysquare/.virtualenvs/asyncio/asyncio/asyncio/futures.py", line 274, in result
    raise self._exception
  File "/Users/emptysquare/.virtualenvs/asyncio/asyncio/asyncio/tasks.py", line 240, in _step
    result = coro.send(None)
  File "/Users/emptysquare/.virtualenvs/asyncio/asyncio/asyncio/base_events.py", line 959, in create_server
    sock.bind(sa)
TypeError: an integer is required (got type str)

Is this what you're talking about?

[1st1]

I've two tests that crash for me with latest asyncio and latest uvloop tests: Test_AIO_AioHTTP.test_aiohttp_basic_1 and Test_AIO_TCP.test_create_server_3. The former passes port as an str, and the latter passes port as None

[1st1]

To summarize: the behaviour of loop.getaddrinfo should mirror the behaviour of socket.getaddrinfo exactly.

[gvanrossum]

That's poorly specified, since the behavior of socket.getaddrinfo probably implements some caching behavior (or lack thereof) that loop.getaddrinfo intentionally doesn't mirror.

[1st1]

loop.getaddrinfo uses socket.getaddrinfo in a threadpool, so it behaved exactly like the latter. At least our updated code should continue to accept all argument types it accepted in 3.5.1. In this particular case it should be easy to fix the code.

[gvanrossum]

Great. Specifically referring to argument types is a much better way to state the intention than "mirror exactly".

[1st1]

Great. Specifically referring to argument types is a much better way to
state the intention than "mirror exactly".

Right.

[1st1]

Closing this one.