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 lepaperwan
Recipients asvetlov, lepaperwan, maxifree, yselivanov
Date 2018-12-20.23:08:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1545347339.18.0.788709270274.issue35545@psf.upfronthosting.co.za>
In-reply-to
Content
While the 3.7+ getaddrinfo isn't the best human representation of an IPv6 address, I believe it does make the most sense to keep it that way.
In any case, this is a regression and changing return values of getaddrinfo for 3.7 isn't something that should be considered.

The issue stems from the refactoring of the underlying socketmodule.c handling of IPv4/IPv6 addresses with dedicated make_ipv4_addr and make_ipv6_addr functions which returns proper tuples of:
  str/int for IPv4: https://github.com/python/cpython/blob/master/Modules/socketmodule.c#L1270
  str/int/int/int for IPv6: https://github.com/python/cpython/blob/master/Modules/socketmodule.c#L1325

The actual issue is that _ensure_resolved naively assumes IPv4 and truncates the address to its first 2 members
https://github.com/python/cpython/blob/3.7/Lib/asyncio/base_events.py#L1269
and never redefines them again in the case where they were set.

I'd suggest passing the remaining elements of address in a packed *args or an optional flowinfo=0, scopeid=0 to _ipaddr_info since fundamentally, that's the method stripping valuable information.
History
Date User Action Args
2018-12-20 23:08:59lepaperwansetrecipients: + lepaperwan, asvetlov, yselivanov, maxifree
2018-12-20 23:08:59lepaperwansetmessageid: <1545347339.18.0.788709270274.issue35545@psf.upfronthosting.co.za>
2018-12-20 23:08:59lepaperwanlinkissue35545 messages
2018-12-20 23:08:58lepaperwancreate