This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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

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.
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: <>
2019-01-04 08:20:32twisteroid ambassadorlinkissue35545 messages
2019-01-04 08:20:31twisteroid ambassadorcreate