Author twisteroid ambassador
Recipients asvetlov, eamanu, lepaperwan, maxifree, twisteroid ambassador, yselivanov
Date 2019-01-04.08:20:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1546590032.08.0.0937578832795.issue35545@roundup.psfhosted.org>
In-reply-to
Content
Oh wait, there's also this in asyncio docs for loop.sock_connect:

Changed in version 3.5.2: address no longer needs to be resolved. sock_connect will try to check if the address is already resolved by calling socket.inet_pton(). If not, loop.getaddrinfo() will be used to resolve the address.

https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.sock_connect

So this is where the current bug comes from! My PR 11403 basically undid this change.

My proposal, as is probably obvious, is to undo this change and insist on passing only resolved address tuples to loop.sock_connect(). My argument is that this feature never worked properly: 

* As mentioned in the previous message, this does not work on ProactorEventLoop.
* On SelectorEventLoop, the resolution done by loop.sock_connect() is pretty weak anyways: it only takes the first resolved address, unlike loop.create_connection() that actually tries all the resolved addresses until one of them successfully connects.

Users should use create_connection() or open_connection() if they want to avoid the complexities of address resolution. If they are reaching for low_level APIs like loop.sock_connect(), they should also handle loop.getaddrinfo() themselves.
History
Date User Action Args
2019-01-04 08:20:33twisteroid ambassadorsetrecipients: + twisteroid ambassador, asvetlov, yselivanov, lepaperwan, eamanu, maxifree
2019-01-04 08:20:32twisteroid ambassadorsetmessageid: <1546590032.08.0.0937578832795.issue35545@roundup.psfhosted.org>
2019-01-04 08:20:32twisteroid ambassadorlinkissue35545 messages
2019-01-04 08:20:31twisteroid ambassadorcreate